This seems to me a compiler problem. The error is attached. ----- ../boost/spirit/core/composite/actions.hpp:106: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /tmp/cctwc2Fu.out file, please attach this to your bugreport. make: *** [packages/execution/ProgramGraphParser.o] Error 1 ----- Reproducible: Always Steps to Reproduce: 1. Compile with g++ -D_REENTRANT -Wall -O2 -DNDEBUG -fPIC -march=pentium -O2 -c preprocessed_output.cpp 2. 3. Actual Results: Error as described in description Expected Results: Compiled without error as on my AMD64 You can find preprocessed output at the attached url. Compiler version I use: ---- Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.1 (Gentoo 4.1.1-r3) ----
Not portage;
Created attachment 112378 [details] Compiler error
Created attachment 112379 [details] Preprocessed output
What's orocos??? No such thing in the tree. Is the problem reproducible? Additionally, emerge --info missing, plus attach anything relevant here instead of referring to third-party links.
> What's orocos??? No such thing in the tree. Is the problem reproducible? > Additionally, emerge --info missing, plus attach anything relevant here instead > of referring to third-party links. orocos is a robot control framework. It's not in portage, but makes the compiler segfault. The library uses boost::spirit. Everything is attached to the bug. Preprocessed output and precise error-output. Try it yourself. untar/unbzip the thing and try for your self to see if the compiler complains. It's not an issue on my AMD64, but on my pentium m laptop (x86).
Please post emerge --info. Are you building using the Gentoo-packaged boost, or a duplicate copy inside orocos? It looks like the latter to me, in which case you could try configuring orocos to use the installed boost library (dev-libs/boost).
(In reply to comment #6) > Please post emerge --info. > > Are you building using the Gentoo-packaged boost, or a duplicate copy inside > orocos? It looks like the latter to me, in which case you could try > configuring orocos to use the installed boost library (dev-libs/boost). I am using the "not-installed" version of boost. I'll try using the internal version now.
Just to note - that preprocessed file doesn't segfault for me, neither with 4.1.2 nor 4.1.1-r3: $ g++ -Wall -O2 -fPIC -march=pentium -c preprocessed_output.cpp $ i686-pc-linux-gnu-g++-4.1.1 -Wall -O2 -fPIC -march=pentium \ -c preprocessed_output.cpp
(In reply to comment #8) > Just to note - that preprocessed file doesn't segfault for me, neither with > 4.1.2 nor 4.1.1-r3: > > $ g++ -Wall -O2 -fPIC -march=pentium -c preprocessed_output.cpp > $ i686-pc-linux-gnu-g++-4.1.1 -Wall -O2 -fPIC -march=pentium \ > -c preprocessed_output.cpp > The internal version of boost doesn't seem to be "good enough" for orocos - scanner_fwd.hpp is missing and required by orocos. Don't know what the file actually does. So if you run x86 technology - how did you compile your gcc? I've been using these flags (part of make.conf): ---- USE="aac aalib acl acpi beagle bluetooth dga \ directfb dvd evo exif flash gimp gimpprint lcms irmc mmx \ mono mysql pdf php ppds samba sse sse2 svg tetex tiff \ unicode usb userlocales win32codecs wma wmf xprint xvid \ nptl nptlonly bash-completion foomaticdb" CFLAGS="-O2 -march=pentium-m -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CXXFLAGS="${CFLAGS}" ---- could anyone else (who use pentium-m and optimize with -march=pentium-m) try this out?
You still haven't posted the output of 'emerge --info' - it's surprising how often that helps. Often a fault is not where it might immediately appear to be. You could try re-emerging gcc; perhaps a patch has gone in since you merged gcc-4.1.1-r3 (shouldn't be the case if you only merge gcc when it's stable). The compilation log segment you posted showed '-march=pentium' rather than '-march=pentium-m', for what it's worth.
> You still haven't posted the output of 'emerge --info' - it's surprising how > often that helps. Often a fault is not where it might immediately appear to > be. Sorry, got distracted by someone... I'll just turn on my laptop and do that now. > You could try re-emerging gcc; perhaps a patch has gone in since you merged > gcc-4.1.1-r3 (shouldn't be the case if you only merge gcc when it's stable). > > The compilation log segment you posted showed '-march=pentium' rather than > '-march=pentium-m', for what it's worth. > I've tried both, but gcc is compiled with -march=pentium-m like any other part of my system.
Created attachment 112426 [details] emerge --info output
hmm; my gcc is -march=pentium3 which isn't so far from pentium-m. No other suggestions come to mind at the moment.
> hmm; my gcc is -march=pentium3 which isn't so far from pentium-m. No other > suggestions come to mind at the moment. I tried recompiling gcc and it really helped... funny though. I haven't been using any unstable versions of gcc and only relied on the updates through gentoo portage. No second part ebuilds or anything! Don't know how to respond to this. It seems there could be a problem somewhere in the structure of how the update where performed by portage. But to find this is probably not possible. Someone should either respond to this or close the bug as fixed! I don't know what to do!
Don't worry about it; as you say it's practically impossible to find out what went wrong before, there's certainly nothing obvious. I've resolved the bug for now; if it happens again, just re-open.
