Compiling GCC-4.5.0:trunk or 20090514 fails on my System Gentoo Intel Atom N270 With following log message: > tmp-mlib.h; \ fi echo '#include "tree.def"' > tmp-all-tree.def echo timestamp > s-gtyp-input lsf=""; for f in $lsf; do \ echo "#include \"$f\""; \ done | sed 's|/var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/gcc-4.5.0-9999/gcc/||' > tmp-specs.h echo 'END_OF_BASE_TREE_CODES' >> tmp-all-tree.def /bin/sh /var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/gcc-4.5.0-9999/gcc/../move-if-change tmp-specs.h specs.h i686-pc-linux-gnu-gcc -c -O -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-styl$ 835 übersetzte Meldungen, 2830 ungenaue Ãbersetzungen, 3424 unübersetzte Meldungen. make[3]: *** Keine Regel vorhanden, um das Target »proto«, benötigt von »native«, zu erstellen. Schluss. make[3]: *** Warte auf noch nicht beendete Prozesse... /bin/sh /var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/gcc-4.5.0-9999/gcc/../move-if-change tmp-mlib.h multilib.h echo '#include "c-common.def"' >> tmp-all-tree.def echo timestamp > s-specs ltf="/var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/gcc-4.5.0-9999/gcc/ada/gcc-interface/ada-tree.def /var/tmp/portage/sys-de$ echo "#include \"$f\""; \ done | sed 's|/var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/gcc-4.5.0-9999/gcc/||' >> tmp-all-tree.def echo timestamp > s-mlib 6332 übersetzte Meldungen, 564 ungenaue Ãbersetzungen, 193 unübersetzte Meldungen. /bin/sh /var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/gcc-4.5.0-9999/gcc/../move-if-change tmp-all-tree.def all-tree.def echo timestamp > s-alltree 7089 übersetzte Meldungen. /bin/sh /var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/gcc-4.5.0-9999/gcc/../move-if-change tmp-optionlist optionlist echo timestamp > s-options make[3]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/build/gcc' make[2]: *** [all-stage1-gcc] Fehler 2 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/build' make[1]: *** [stage1-bubble] Fehler 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/build' make: *** [bootstrap] Fehler 2 Same on my Core2 Duo machine. Same with gcc-4.5.0_alphaXXXXXXXXX from toolchain overlay Reproducible: Always Steps to Reproduce: 1.emerge gcc-4.5 2. 3.
Created attachment 191901 [details] emerge --info Here's my emerge --info I've already tested it without distcc and ccache but it does not help.
It could be related to this. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33200 use_fixproto=yes does not exist in 4.5 will test it and report.
try removing the proto sed line from toolchain.eclass
ok i removed this line from the pre9999 ebuild # protoize don't build on FreeBSD, skip it if ! is_crosscompile && ! use elibc_FreeBSD ; then # enable protoize / unprotoize sed -i -e '/^LANGUAGES =/s:$: proto:' "${S}"/gcc/Makefile.in fi now it compiles fine but at the end i have access errors i think. here's my build.log with deny messages will test the gcc-4.5.0_alphaXXXXXXXX ebuild with modified toolchain.eclass but i think it will result with the same messages.
Created attachment 191952 [details] build.log-gcc-4.5-pre9999 with removed sed entry
no idea where that is coming from. feel free to debug it.
ok guys now it works with FEATURES="-sandbox" i think its just for creating the directorys now i remerge it with sandbox flag and will report if it works in a few minutes
removing these lines from toolchain.eclass or ebuild # protoize don't build on FreeBSD, skip it if ! is_crosscompile && ! use elibc_FreeBSD ; then # enable protoize / unprotoize sed -i -e '/^LANGUAGES =/s:$: proto:' "${S}"/gcc/Makefile.in fi and setting FEATURES="-sandbox" fixed this bug.
that's not fixed, that's installing files into the live file system.
but after installing it without sandbox you can run it for a second time with sanbox feature and then it works. What is installing files into live file system?
I know, but that's not a fix, it's a workaround. It shouldn't be trying to create directories directly in /usr, that's a bug which needs to be fixed. When I have a minute I'll try to figure out why and send it upstream.
Created attachment 192255 [details, diff] gcc45-plugin-destdir.patch i think this should do it, but bootstrap is broken for me right now so it hasn't been tested.
that change looks correct to me ... gcc-patches@gcc.gnu.org ?
as soon as i track down why I can't bootstrap. seems to be broken with -Wl,--as-needed.
Okay, bootstrap passed and patch sent.
I stuck a < 4.5 around the protoize lines in toolchain.eclass. I kept getting emails about it.
Could someone please add a patch for the Sandbox bug until it is patched in gcc source. Everytime i wish to update world i need to set FEATURES="-sandbox" for the lonely gcc 4.5 compiler.
gcc-4.5.0-alpha20090625 worked for me today, so i guess this is fixed
(In reply to comment #18) > gcc-4.5.0-alpha20090625 worked for me today, so i guess this is fixed for me it's not emerge: {standard input}: Assembler messages: {standard input}:28: Error: no such instruction: `movbe 8(%ebp),%eax' make[3]: *** [_bswapsi2.o] Error 1 make[3]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.0_alpha20090625/work/build/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.0_alpha20090625/work/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.0_alpha20090625/work/build' make: *** [bootstrap-lean] Error 2 * * ERROR: sys-devel/gcc-4.5.0_alpha20090625 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 4804: Called toolchain_src_compile * environment, line 5328: Called gcc_src_compile * environment, line 3052: Called gcc_do_make * environment, line 2843: Called die * The specific snippet of code: * emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}" LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET} || die "emake failed with ${GCC_MAKE_TARGET}"; * The die message: * emake failed with bootstrap-lean
Now i have these errors too. I think it has something to do with binutils. take a look at these: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40540
Don't expect this ebuild to always work. Send stuff upstream unless you can identify something that we are doing wrong with the ebuild.
