x86_64-pc-linux-gnu-g++ -o build/linux2/cc_x86_64-pc-linux-gnu-gcc/cxx_x86_64-pc-linux-gnu-g++/ssl/use-system-boost/use-system-pcre/use-system-snappy/use-system-tcmalloc/usesm/mongo/shell/linenoise.o -c -march=k8-sse3 -mno-cx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8 -O2 -g -Wall -fstack-protector -fPIC -fno-strict-aliasing -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -fno-builtin-memcmp -O3 -D_SCONS ...
I think this is related with a segfault I'm getting: mongo MongoDB shell version: 2.6.8 connecting to: test 2015-02-28T11:49:57.456-0300 mongo got signal 11 (Segmentation fault), stack trace: 2015-02-28T11:49:57.458-0300 0x7d36b9 0x5e4ed9 0x7f653593aad0 0x9c2c42 0xa335f8 0xa33634 0xa389de 0x9d126b 0x9dc688 0x9dcaa5 0x87a1f0 0x99cec8 0x9398dd 0x39e6fda06362 mongo(_ZN5mongo15printStackTraceERSo+0x39) [0x7d36b9] mongo(_Z12quitAbruptlyi+0x119) [0x5e4ed9] /lib64/libc.so.6(+0x33ad0) [0x7f653593aad0] mongo(_ZN2v88internal6String11WriteToFlatItEEvPS1_PT_ii+0x692) [0x9c2c42] mongo(_ZN2v88internal33GenericStringUtf16CharacterStream10FillBufferEjj+0x38) [0xa335f8] mongo(_ZN2v88internal28BufferedUtf16CharacterStream9ReadBlockEv+0x34) [0xa33634] mongo(_ZN2v88internal7Scanner10InitializeEPNS0_20Utf16CharacterStreamE+0x5e) [0xa389de] mongo(_ZN2v88internal6Parser9ParseLazyEPNS0_20Utf16CharacterStreamEPNS0_9ZoneScopeE+0x3b) [0x9d126b] mongo(_ZN2v88internal6Parser9ParseLazyEv+0x158) [0x9dc688] mongo(_ZN2v88internal9ParserApi5ParseEPNS0_15CompilationInfoEi+0x205) [0x9dcaa5] mongo(_ZN2v88internal8Compiler11CompileLazyEPNS0_15CompilationInfoE+0xf0) [0x87a1f0] mongo(_ZN2v88internal10JSFunction11CompileLazyENS0_6HandleIS1_EENS0_18ClearExceptionFlagE+0x1a8) [0x99cec8] mongo(_ZN2v88internal11CallIC_MissENS0_9ArgumentsEPNS0_7IsolateE+0x27d) [0x9398dd] [0x39e6fda06362] It seems to be a bug with gcc 4.9.x and -O3: https://jira.mongodb.org/browse/SERVER-13824 And they have already a patch to fix it: https://github.com/mongodb/mongo/commit/0028a339876b352575758910a158973852ce4cfe Maybe we should put it on tree?
(In reply to Jeroen Roovers from comment #0) > x86_64-pc-linux-gnu-g++ -o > build/linux2/cc_x86_64-pc-linux-gnu-gcc/cxx_x86_64-pc-linux-gnu-g++/ssl/use- > system-boost/use-system-pcre/use-system-snappy/use-system-tcmalloc/usesm/ > mongo/shell/linenoise.o -c -march=k8-sse3 -mno-cx16 -msahf -mno-movbe > -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 > -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param > l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 > -mtune=k8 -O2 -g -Wall -fstack-protector -fPIC -fno-strict-aliasing -pthread > -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -fno-builtin-memcmp > -O3 -D_SCONS ... AFAIR upstream *strongly* advise to respect this flag, that's why we have always kept it that way. Source code of 2.6.8 shows if optBuild: env.Append( CCFLAGS=["-O3"] ) else: env.Append( CCFLAGS=["-O0"] ) I remember a previous patch that set this to CXXFLAGS instead but I guess there's no real difference in this. Maybe a comment in the ebuild is okay ? I could also filter out user's -O? with flag-o-matic to make it more clear, would you think it acceptable ?
(In reply to Michel Boaventura from comment #1) > I think this is related with a segfault I'm getting: > > mongo > MongoDB shell version: 2.6.8 > connecting to: test > 2015-02-28T11:49:57.456-0300 mongo got signal 11 (Segmentation fault), stack > trace: > 2015-02-28T11:49:57.458-0300 0x7d36b9 0x5e4ed9 0x7f653593aad0 0x9c2c42 > 0xa335f8 0xa33634 0xa389de 0x9d126b 0x9dc688 0x9dcaa5 0x87a1f0 0x99cec8 > 0x9398dd 0x39e6fda06362 > mongo(_ZN5mongo15printStackTraceERSo+0x39) [0x7d36b9] > mongo(_Z12quitAbruptlyi+0x119) [0x5e4ed9] > /lib64/libc.so.6(+0x33ad0) [0x7f653593aad0] > mongo(_ZN2v88internal6String11WriteToFlatItEEvPS1_PT_ii+0x692) [0x9c2c42] > mongo(_ZN2v88internal33GenericStringUtf16CharacterStream10FillBufferEjj+0x38 > ) [0xa335f8] > mongo(_ZN2v88internal28BufferedUtf16CharacterStream9ReadBlockEv+0x34) > [0xa33634] > mongo(_ZN2v88internal7Scanner10InitializeEPNS0_20Utf16CharacterStreamE+0x5e) > [0xa389de] > mongo(_ZN2v88internal6Parser9ParseLazyEPNS0_20Utf16CharacterStreamEPNS0_9Zon > eScopeE+0x3b) [0x9d126b] > mongo(_ZN2v88internal6Parser9ParseLazyEv+0x158) [0x9dc688] > mongo(_ZN2v88internal9ParserApi5ParseEPNS0_15CompilationInfoEi+0x205) > [0x9dcaa5] > mongo(_ZN2v88internal8Compiler11CompileLazyEPNS0_15CompilationInfoE+0xf0) > [0x87a1f0] > mongo(_ZN2v88internal10JSFunction11CompileLazyENS0_6HandleIS1_EENS0_18ClearE > xceptionFlagE+0x1a8) [0x99cec8] > mongo(_ZN2v88internal11CallIC_MissENS0_9ArgumentsEPNS0_7IsolateE+0x27d) > [0x9398dd] > [0x39e6fda06362] > > It seems to be a bug with gcc 4.9.x and -O3: > https://jira.mongodb.org/browse/SERVER-13824 > > And they have already a patch to fix it: > https://github.com/mongodb/mongo/commit/ > 0028a339876b352575758910a158973852ce4cfe > > Maybe we should put it on tree? Seeing the comment of Andrew, I'm not sure this should be in tree tbh : https://jira.mongodb.org/browse/SERVER-16985?focusedCommentId=812066&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-812066 Instead, I would add a detection and failure about this on the ebuild since it's not a good idea to go 2.6.x with gcc-4.9 in production env. Looks like that adding a constraint on the boost version would be wise as well.
(In reply to Ultrabug from comment #2) > (In reply to Jeroen Roovers from comment #0) > > x86_64-pc-linux-gnu-g++ -o > > build/linux2/cc_x86_64-pc-linux-gnu-gcc/cxx_x86_64-pc-linux-gnu-g++/ssl/use- > > system-boost/use-system-pcre/use-system-snappy/use-system-tcmalloc/usesm/ > > mongo/shell/linenoise.o -c -march=k8-sse3 -mno-cx16 -msahf -mno-movbe > > -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 > > -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param > > l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 > > -mtune=k8 -O2 -g -Wall -fstack-protector -fPIC -fno-strict-aliasing -pthread > > -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -fno-builtin-memcmp > > -O3 -D_SCONS ... > > AFAIR upstream *strongly* advise to respect this flag, that's why we have > always kept it that way. > > Source code of 2.6.8 shows > > if optBuild: > env.Append( CCFLAGS=["-O3"] ) > else: > env.Append( CCFLAGS=["-O0"] ) > > I remember a previous patch that set this to CXXFLAGS instead but I guess > there's no real difference in this. > > Maybe a comment in the ebuild is okay ? I could also filter out user's -O? > with flag-o-matic to make it more clear, would you think it acceptable ? Ultra, I compiled (2.6.8) with "-O3 -pipe" (just today) and GCC 4.9.2 and I'm not getting this segfault. But you know that if -march is used the result is a segfault like this. So imho... if USE=debug CCFLAGS~="-O0" if USE=-debug CCFLAGS~="-O3" and print a notice "This is an optimized build (debug USE flag is not set). Your -O optimization setting is ignored and the recommended -O3 is used to build the package" or "Building debug build, setting -O0 (debug USE flag is set)" and filter any "^-m+" in *FLAGS and if we find more CXXFLAG contents cause more problems filter them too. my2c
Okay, I have bumped the ebuild on my overlay now. I included the modification we spoke about on bug #526114 # respect mongoDB upstream's basic recommendations # see bug #536688 and #526114 if ! use debug; then filter-flags '-m*' filter-flags '-O?' fi So this should be safe to build on newer GCC unless you specify the debug flag. Can you try and report back if all is good for you ?
As explained here [1] I've done this in mongodb-3.0.1 release [1] http://www.ultrabug.fr/mongodb-3-0-1/
