[SERVER-29982] Redefinition of _FORTIFY_SOURCE causes build failure with misleading error message Created: 05/Jul/17  Updated: 07/Sep/17  Resolved: 17/Aug/17

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Bernie Hackett Assignee: Andrew Morrow (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File config.log    
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

Apparently gcc provided by certain Linux vendors automatically defines _FORTIFY_SOURCE internally. This leads to build failure when not using --disable-warnings-as-errors. The error message leads you to believe your compiler can't be used to build MongoDB:

Checking for glibc with non-broken _FORTIFY_SOURCE...yes
Checking if C compiler supports -fno-builtin-memcmp... no
Checking for storage class thread_local no
Checking for storage class __thread no
Checking for storage class __declspec(thread) no
Compiler must support a thread local storage class for trivially constructible types
See /home/behackett/work/mongo/build/scons/config.log for details

This is with gcc 6.3 on Gentoo Linux. I'm attaching the scons config.log for details.

$ gcc --version
gcc (Gentoo 6.3.0 p1.0) 6.3.0

We should probably fix the redefinition problem, or at least provide a more accurate error message. Building with --disable-warnings-as-errors works around the problem, but scons spews warnings about _FORTIFY_SOURCE non-stop throughout the build.

<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined
<built-in>: note: this is the location of the previous definition
<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined
<built-in>: note: this is the location of the previous definition
....



 Comments   
Comment by Andrew Morrow (Inactive) [ 17/Aug/17 ]

As this is not an issue with GCC, but with Gentoo's local modifications to GCC, I'm closing this as 'Wont Fix'. Our build process is entitled to set _FORTIFY_SOURCE as we see fit without addressing unusual local configurations. While I can appreciate that Gentoo has taken the step of force enabling _FORTIFY_SOURCE in an effort to enhance the security of packages built from source, the current mechanism by which they are doing it is flawed, since it renders correct builds invalid. As there is also a workaround --disable-warnings-as-errors, this does not seem like a worthwhile use of time. Additionally, Gentoo is free write their own patches to the MongoDB sources to address this issue on their side.

Comment by Andrew Morrow (Inactive) [ 21/Jul/17 ]

Thanks greenius - Lets see if your ping on that ticket helps to elicit a response, I appreciate your doing that and linking back to the PR/ticket. I think your qualification that we 'rejected' the change is a bit strong. I'd still consider pulling it if the maintainers are vehemently opposed to fixing on their side, since clearly we want it to be possible to build without --disable-warnings-as-errors. But I think we should try that angle first, and fall back to the -U workaround only if needed.

Comment by Steven Green [ 21/Jul/17 ]

I have investigated a bit more and found that Gentoo linux applies some patches to the gcc source code, including 10_all_default-fortify-source.patch:

Enable -D_FORTIFY_SOURCE=2 by default.

— a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -951,6 +951,9 @@ c_cpp_builtins (cpp_reader *pfile)
builtin_define_with_value ("_REGISTER_PREFIX_", REGISTER_PREFIX, 0);
builtin_define_with_value ("_USER_LABEL_PREFIX_", user_label_prefix, 0);

+ /* Fortify Source enabled by default w/optimization. */
+ cpp_define (pfile, "FORTIFY_SOURCE=((defined __OPTIMIZE_ && _OPTIMIZE_ > 0) ? 2 : 0)");
+
/* Misc. */
if (flag_gnu89_inline)
cpp_define (pfile, "_GNUC_GNU_INLINE_");

There is bug report at https://bugs.gentoo.org/show_bug.cgi?id=621036 relating to this which includes a patch to the patch which undefines it if already defined, but it has not had any response from the toolkit maintainers since it was added 6 weeks ago.

Comment by Andrew Morrow (Inactive) [ 21/Jul/17 ]

behackett - I think this a different issue, and I'm not convinced that we should be the ones to fix it. I have no problem with the system toolchain packagers deciding that _FORTIFY_SOURCE=1 should be defaulted by the compiler, but I disagree that it should cause a compilation error if I then chose to define _FORTIFY_SOURCE myself. Instead, it should honor my selection instead of using the default. I'd suggest raising this issue with the arch and gentoo toolchain maintainers. While I could be convinced to take a workaround for this issue, I'd find it distasteful. I think the distro toolchain packagers have made a serious mistake and should fix this on their side.

Comment by Bernie Hackett [ 05/Jul/17 ]

This seems to be the same problem reported in SERVER-24566, but was only fixed for debug builds.

Generated at Thu Feb 08 04:22:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.