Summary: | gnustep-gui-0.9.5 fails to compile with an internal compiler error | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joe <josyoun> |
Component: | New packages | Assignee: | Gentoo Gnustep project <gnustep> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | c.turner, toolchain |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | PPC | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
second set of error logs
Smaller testcase |
Description
Joe
2005-09-13 17:16:34 UTC
I don't know much about the hardened toolchain; adding 'hardened' to the CC-list. This bug definitely caused GCC to explode, and it seems to be to be related to hardened added functionality. What I would like to know is if the hardened-gcc stuff is actively tested with ObjC code from 'upstream', or even ever tested? If not, is there a way to restrict use of a hardened-enabled gcc from being beinh used from ebuilds? (I'm guessing not really.) Because I don't know if ObjC really works with 'hardened', bugs in GNUstep or not, I'm not sure if ObjC code itself is simply likely to fail. Joe: could you use gcc-config to use the non-hardened version of the compiler? Does that let allow the package to continue compiling? Also, the error output notes that the failing pre-processed source is here: "/var/tmp/portage/gnustep-gui-0.9.5/temp/ccBcU9ml.out" -- could you please post that? (maybe compress it and make it available somewhere, or here) To verify whether the bug is triggered by the hardened compiler, use gcc-config to switch to the 'vanilla' compiler (do 'gcc-config -l' to see) and emerge this one package with that (don't forget to switch back afterwards). If it works with vanilla, but fails with the hardened compiler, then you can point the finger at different defaults enacted by the hardened gcc. If this proves to be the case, try with the hardenednopie and hardenednossp variants, which helps narrow things down a bit. The build still fails when I use gcc-config powerpc-unknown-linux-gnu-3.4.4-vanilla. I've placed the preprocessed source for the build using the normal, hardened compiler at http://www.owlnet.rice.edu/~jgy4865/ccBcU9ml.out The preprocessed source for the build using the vanilla compiler is at http://www.owlnet.rice.edu/~jgy4865/ccleLhy8.out I'll go ahead and wipe this version of gcc off my computer and try a completely unhardened version of gcc to see what happens. I recompiled gcc, glibc, glib, make, gnustep-make, gnustep-base, gnustep-gui in that order with hardened removed from the USE flags. I still receive an internal compiler error when compiling gnustep-gui. I've posted the current preprocessed source at http://www.owlnet.rice.edu/~jgy4865/ccBl9iKA.out I'm currently using Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/specs Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure --prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/3.4.4 --includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/include --datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4 --mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/include/g++-v3 --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --enable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --enable-java-awt=gtk --enable-languages=c,c++,objc,java,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8) [1] powerpc-unknown-linux-gnu-3.4.4 * [2] powerpc-unknown-linux-gnu-3.4.4-hardened [3] powerpc-unknown-linux-gnu-3.4.4-hardenednopie [4] powerpc-unknown-linux-gnu-3.4.4-hardenednopiessp [5] powerpc-unknown-linux-gnu-3.4.4-hardenednossp I rebuilt my entire system using emerge -e world with the nonhardened version of gcc and hardened removed from the USE flags. I still receive the same error. I've placed the processed source at www.owlnet.rice.edu/~jgy4865/ccByDtu8.out Can confirm problem. Attached compiler output, gcc -v, and preprocessed sources, appears to be same error (compiler error in NSTextView) Thanks! did not mention, never ran with hardened toolkit. Created attachment 78348 [details]
second set of error logs
second set of error logs for bug confirmation
Swapping hardened for toolchain, since this turns out to happen on the vanilla compiler as well. This appears to be fixed in gcc-3.4.5. Can someone please verify this for me? Created attachment 78475 [details]
Smaller testcase
Here is a much smaller testcase to use. Using gcc-3.4.4 it should ICE if you do: gcc -c -O2 testcase.x.mi. Doing the same with 3.4.5 should be successful. It is for me atleast :)
Works for me with 3.4.5 |