This problem was discovered when trying to bootstrap Prefix Portage on SUSE Enterprise Server 9.3, following the October 29, 2007 version of http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-linux.xml. Applying the workaround of bug 197391, everything goes fine until the `emerge -e system' step, where gcc-4.2.2 refuses to be emerged. Here are the last lines of console output (attachments will be submitted too): /tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/./gcc/xgcc -B/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/./gcc/ -B/tmp/local/g3/usr/i686-pc-linux-gnu/bin/ -B/tmp/local/g3/usr/i686-pc-linux-gnu/lib/ -isystem /tmp/local/g3/usr/i686-pc-linux-gnu/include -isystem /tmp/local/g3/usr/i686-pc-linux-gnu/sys-include -O2 -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so binutils-config: warning: no GCC found on your system! binutils-config error: Could not run/locate "" (/tmp/local/g3/usr/i686-pc-linux-gnu/binutils-bin/2.18.50.0.2/) collect2: ld returned 1 exit status make[4]: *** [libgcc_s.so] Error 1 make[4]: Leaving directory `/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/gcc' make[3]: *** [libgcc.a] Error 2 make[3]: Leaving directory `/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' make: *** [profiledbootstrap] Error 2 * * ERROR: sys-devel/gcc-4.2.2 failed. * Call stack: * ebuild.sh, line 1598: Called dyn_compile * ebuild.sh, line 936: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * gcc-4.2.2.ebuild, line 94: Called gcc_src_compile * toolchain.eclass, line 1571: Called gcc_do_make * toolchain.eclass, line 1443: 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 profiledbootstrap * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/temp/build.log'.
Created attachment 134633 [details] script, partial console output, build.log for gcc-4.2.2
Thanks, this looks like the same problem as mentioned in bug #197407 *** This bug has been marked as a duplicate of bug 197407 ***
I tried the remedy of bug 197407, but did not have success. In bug 197407 it is suggested to use binutils-config-1.9-r04.1. I set up entries in etc/portage/package.mask and etc/portage/package.unmask to achieve that. Emerging gcc-4.2.2 still fails, but at a different point. The last lines of console output are: make[2]: Entering directory `/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' Configuring stage profile in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /tmp/local/g3/usr/bin/install -c checking whether NLS is requested... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for i686-pc-linux-gnu-gcc... /tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/./prev-gcc/xgcc -B/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/./prev-gcc/ -B/tmp/local/g3/usr/i686-pc-linux-gnu/bin/ checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stageprofile-intl] Error 77 make[2]: Leaving directory `/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' make[1]: *** [stageprofile-bubble] Error 2 make[1]: Leaving directory `/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' make: *** [profiledbootstrap] Error 2 * * ERROR: sys-devel/gcc-4.2.2 failed. * Call stack: * ebuild.sh, line 1598: Called dyn_compile * ebuild.sh, line 936: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * gcc-4.2.2.ebuild, line 94: Called gcc_src_compile * toolchain.eclass, line 1571: Called gcc_do_make * toolchain.eclass, line 1443: 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 profiledbootstrap * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/temp/build.log'.
Created attachment 134646 [details] build.log of gcc-4-2-2 when using binutils-config-1.9-r04.1
Created attachment 134649 [details] config.log where the failure occurs Attaching var/tmp/portage/sys-devel/gcc-4.2.2/work/build/intl/config.log, which indicates a linkage problem.
OK: configure:2118: checking for C compiler default output file name configure:2121: /tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/./prev-gcc/xgcc -B/tmp/local/g3/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/./prev-gcc/ -B/tmp/local/g3/usr/i686-pc-linux-gnu/bin/ -I/tmp/local/g3/usr/include conftest.c >&5 /lib/libc.so.6: undefined reference to `__libc_stack_end@GLIBC_2.1' /lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `___tls_get_addr@GLIBC_2.3' /lib/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE' collect2: ld returned 1 exit status Feels like maybe something went wrong with the linker compilation. Can you check that $EPREFIX/usr/bin/ld shows some normal paths being included, just to be sure?
By accident I screwed up the ldwrapper. I restored it in svn. Though I think this is unrelated to this problem. In any case, just to be sure, would you please try to update from svn (the bootstrap image contains the broken version :( ) and re-emerge binutils-config-1.9-r4 again. It should install the ldwrapper as we used for a long time without trouble.
Created attachment 134659 [details] output of $EPREFIX/usr/bin/ld --verbose I ran `$EPREFIX/usr/bin/ld --verbose' and collected the output to a file. Near the beginning it lists some SEARCH_DIR paths: SEARCH_DIR("/tmp/local/g3/usr/i686-pc-linux-gnu/lib"); SEARCH_DIR("/tmp/local/g3/usr/lib/binutils/i686-pc-linux-gnu/2.18.50.0.2"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
another related thing for this case is if you happen to have a /lib32 and what/how SuSE installs 64-bits (if on your system) where/what dir. The Gentoo setup differs from the Fedora one, which may indicate it differs from the SuSE one too.
Which profile do you use? Are you on a 64-bits machine?
I'll try to rerun from scratch using the more recent binutils-config today. It will have to run mostly unattended because I am away a lot. 32 or 64 bits .. not sure, this is a machine set up by others. How can I check? There is no /lib32 directory under root. uname -a says Linux ws4941 2.6.5-7.244-smp #1 SMP Mon Dec 12 18:32:25 UTC 2005 i686 i686 i386 GNU/Linux contents of /proc/cpuinfo is processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping : 6 cpu MHz : 2400.541 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm pni monitor ds_cpl tm2 est bogomips : 3181.44 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping : 6 cpu MHz : 2400.541 cache size : 4096 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm pni monitor ds_cpl tm2 est bogomips : 3181.44
Created attachment 134684 [details] console output from early failure Hmm .. my re-run attempt failed early. Don't have time to investigate in depth, I enclose some console output for now.
Hmm .. it seems that the bootstrap-prefix.sh script tries to download http://dev.gentoo.org/%7Egrobian/distfiles/prefix-overlay-20071023.tar.bz2, and the file does not exist? Just to rule out any misconfiguration, the MD5 of the bootstrap-prefix.sh that I use is: 8b09aa2f88fa739ce6c174936ce95a2d bootstrap-prefix.sh
correct, I removed the flawed image to prevent any more damage to happen. I will upload a new image (with correct ldwrapper, hopefully) today.
Trying again, starting fresh with everything downloaded today. The `emerge -e system' step still fails; it does not manage to build gcc. Here is some console output; also see attachments: make[3]: Leaving directory `/tmp/local/g4/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' make[2]: Leaving directory `/tmp/local/g4/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' make[2]: Entering directory `/tmp/local/g4/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' Configuring stage profile in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /tmp/local/g4/usr/bin/install -c checking whether NLS is requested... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for i686-pc-linux-gnu-gcc... /tmp/local/g4/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/./prev-gcc/xgcc -B/tmp/local/g4/var/tmp/portage/sys-devel/gcc-4.2.2/work/build/./prev-gcc/ -B/tmp/local/g4/usr/i686-pc-linux-gnu/bin/ checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stageprofile-intl] Error 77 make[2]: Leaving directory `/tmp/local/g4/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' make[1]: *** [stageprofile-bubble] Error 2 make[1]: Leaving directory `/tmp/local/g4/var/tmp/portage/sys-devel/gcc-4.2.2/work/build' make: *** [profiledbootstrap] Error 2 * * ERROR: sys-devel/gcc-4.2.2 failed. * Call stack: * ebuild.sh, line 1598: Called dyn_compile * ebuild.sh, line 936: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * gcc-4.2.2.ebuild, line 94: Called gcc_src_compile * toolchain.eclass, line 1579: Called gcc_do_make * toolchain.eclass, line 1451: 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 profiledbootstrap * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/tmp/local/g4/var/tmp/portage/sys-devel/gcc-4.2.2/temp/build.log'.
Created attachment 134900 [details] step-by-step script being used
Created attachment 134903 [details] compressed build.log
Created attachment 134917 [details] .../work/build/intl/config.log
binutils-config: warning: no GCC found on your system! Did you run binutils-config?
Hi Fabian, my step-by-step script does not explicitly invoke binutils-config. Should it do so? If so, at which step? There is also the question of versions. Should I accept the default version of binutils-config (1.9-r4), or should I arrange that 1.9-r04.1 gets emerged? Or .. are you saying that I should look in the console output and find out if binutils-config is getting invoked somewhere? In that case, is there some good "fingerprint" to look for? (hmmm .. I might of course put a wrapper around the binutils-config binary to really see how it gets used?)
I tried running `binutils-config --list-profiles' manually just before the `emerge -e system' step. The two lines of response that I get are !!! Problem with sandbox binary. Disabling... Using binutils-config info in /tmp/local/g5/ /tmp/local/g5/ is my EPREFIX. Does this mean that something is already broken, and that the root cause must be found at some earlier point?
I was in error. binutils-config is run, otherwise it doesn't warn you don't have a GCC installed yet. Of course you're working on that. can you run file on /lib/libc.so.6?
> file /lib/libc.so.6 /lib/libc.so.6: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped
I think we finally get a hint here. The amd64 profile is a /multilib/ profile. However, your libc seems to be 32-bits only. Do you have a /lib64/libc.so.6 too? Is that one 64-bits? Is the code produced by previous merges 32 or 64-bits? To get your setting going, you may have to switch to the default-prefix/linux/x86 profile to stick to 32-bits, until we find out how 64-bits is done on SuSE.
I checked, there is no /lib64 directory. I also tried `ls -ld /*64* /*/*64* /*/*/*64*' but nothing interesting comes up. And, $EPREFIX/etc/make.profile points to .../default-prefix/linux/x86.
You're absolutely right. I mess things up. A pity though. Could you try to emerge gcc using the bootstrap script? Just to try and see if outside the portage/ebuild environment things do compile fine.
OK, I started a new run from scratch where I have inserted ./bootstrap-prefix.sh $EPREFIX gcc right after the `./bootstrap-prefix $EPREFIX portage' line. (Hmm .. or should that have been `./bootstrap-prefix.sh $EPREFIX gcc'? If so I'll re-run.)
Ideally it's put in $EPREFIX/tmp so it won't cause collisions lateron. For now it doesn't matter though, as I just want to know if it compiles at all.
It seems it went fine. The step-by-step script is already into the autoconf things, and I can run `$EPREFIX/usr/bin/gcc --version' which responds with "4.1.1".
This experiment ended in `emerge -e system'. After emerging binutils (31 of 60) it failed to emerge sys-apps/which-2.16 (32 of 60). The console output goes >>> Compiling source in /tmp/local/g13/var/tmp/portage/sys-apps/which-2.16/work/which-2.16 ... ./configure --prefix=/tmp/local/g13/usr --host=i686-pc-linux-gnu --mandir=/tmp/local/g13/usr/share/man --infodir=/tmp/local/g13/usr/share/info --datadir=/tmp/local/g13/usr/share --sysconfdir=/tmp/local/g13/etc --localstatedir=/tmp/local/g13/var/lib --build=i686-pc-linux-gnu checking for a BSD-compatible install... /tmp/local/g13/usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc checking for C compiler default output... configure: error: C compiler cannot create executables See `config.log' for more details. I will re-run with boostrap-emerging gcc to $EPREFIX/tmp now.
that won't help. Please show me the relevant snippet from config.log that shows why no executables can be created.
Created attachment 135583 [details] config.log from `emerge -e system', sys-apps/which (just after binutils) The config.log where compiling no longer works.
Can you please stop attaching binary files? Thanks.
gcc version 4.1.1 configure:2019: $? = 0 configure:2021: i686-pc-linux-gnu-gcc -V </dev/null >&5 i686-pc-linux-gnu-gcc: '-V' option must have argument configure:2024: $? = 1 configure:2048: checking for C compiler default output configure:2051: i686-pc-linux-gnu-gcc -I/tmp/local/g13/usr/include -L/tmp/local/g13/usr/lib64 -Wl,-rpath=/tmp/local/g13/usr/lib64 -L/tmp/local/g13/usr/lib -Wl,-rpath=/tmp/local/g13/usr/lib -L/tmp/local/g13/lib64 -Wl,-rpath=/tmp/local/g13/lib64 -L/tmp/local/g13/lib -Wl,-rpath=/tmp/local/g13/lib conftest.c >&5 binutils-config: warning: no GCC found on your system! /lib/libc.so.6: undefined reference to `__libc_stack_end@GLIBC_2.1' /lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `___tls_get_addr@GLIBC_2.3' /lib/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE' collect2: ld returned 1 exit status It is quite interesting to see that the binutils-wrapper is being used. I don't understand why it is used at all if this is your bootstrapped compiler, unless you bootstrapped over an already existing prefix.
OK, got the point about not attaching binaries. Why binutils-wrapper is used .. I have no idea. In general I try to do everything from scratch all the time, to ensure reproducibility. I attach my latest step-by-step script with all tweaks so you can have a look.
Created attachment 135588 [details] step-by-step script The script.
Ok, this goes beyond my understanding. is i686-pc-linux-gnu-gcc the bootstrapped gcc? If yes, what does gcc -v show?
I'll check what gcc -v produces. First I will roll back the step-by-step script to do `bootstrap-prefix.sh $EPREFIX gcc' (thus not building to $EPREFIX/tmp which gets wiped before `emerge -e system'). It will take an hour or three.
Here is gcc info just before invoking `emerge -e system': > which gcc /tmp/local/g13/usr/bin/gcc > gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /tmp/local/g13/var/tmp/gcc-4.1.1/gcc-4.1.1/configure --prefix=/tmp/local/g13/usr --mandir=/tmp/local/g13/usr/share/man --infodir=/tmp/local/g13/usr/share/info --datadir=/tmp/local/g13/usr/share --disable-checking --disable-werror --disable-nls --with-system-zlib --enable-languages=c,c++ Thread model: posix gcc version 4.1.1
ok, using this gcc, can you compile a simple program, e.g. % cat > test.c #include <stdio.h> int main() { printf("hello world!\n"); } ^D % gcc -o test test.c % ./test
No, it appears that gcc is broken, see below. However, maybe it is broken because it was placed in $EPREFIX and not $EPREFIX/tmp? I could re-run and have it in $EPREFIX/tmp, and defer the removal of $EPREFIX/tmp things until after `emerge -e system'. Anyway, your test yields this, erarafo@ws4941 [tmp/local/g13]: which gcc /tmp/local/g13/usr/bin/gcc erarafo@ws4941 [tmp/local/g13]: cat >test.c #include <stdio.h> int main() { printf("hi\n"); } erarafo@ws4941 [tmp/local/g13]: gcc -o test test.c binutils-config: warning: no GCC found on your system! /lib/libc.so.6: undefined reference to `__libc_stack_end@GLIBC_2.1' /lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `___tls_get_addr@GLIBC_2.3' /lib/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE' collect2: ld returned 1 exit status
the fact that the bootstrapped compiler fails, indicates there is much more wrong here. Bootstrapping doesn't do anything fancy, just configure, make, make install (sort of). I'm starting to suspect SuSE from once again changing something which shouldn't be changed...
I did the re-run with the bootstrap GCC 4.1.1 installed to $EPREFIX/tmp (and wiping of $EPREFIX/tmp postponed). It does make a difference, the GCC usability test now succeeds when just about to start the `emerge -e system'. The script is chewing along happily .. right now emerging binutils. So far so good, now digging into the gcc-4.2.2 source! And then, somewhere into the gcc-4.2.2 emerge, the compile gets unusable. I was actually rerunning the compile-link-run of test.c in another window and noticed that it no longer works. The immediately preceding emerge step (`emerge which') succeeds. So somehow it is as if the emerging of gcc-4.2.2 messes up the environment. And why this should happen on SUSE but not on, say, Fedora, is a mystery. The environment is now in a state like this: which gcc /tmp/local/g13/tmp/usr/bin/gcc erarafo@ws4941 [tmp/local/g13]: gcc -o test test.c binutils-config: warning: no GCC found on your system! /lib/libc.so.6: undefined reference to `__libc_stack_end@GLIBC_2.1' /lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `___tls_get_addr@GLIBC_2.3' /lib/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE' collect2: ld returned 1 exit status
I am doing a re-run from scratch where I have edited bootstrap-prefix.sh so that it builds gcc-4.2.2 instead of 4.1.1. I was thinking that possibly there would be some incompatibility between gcc-4.2.2 and SuSE's glibc, and in that case the bootstrap process would grind to an early halt. This is not the case though, gcc-4.2.2 is now in $EPREFIX/tmp and at this moment coreutils is being emerged. My prediction is that bootstrapping will self-destruct again when gcc-4.2.2 is emerged to the final location. More to come...
Nothing new: amidst emerging gcc the GCC stops working, with the same symptoms as before. At least we know that it does not have anything to do with specific gcc version numbers.
I am now running a refined step-by-step script to try and get more insight. Like before I am using a gcc 4.1.1 installed to $EPREFIX/tmp. Instead of `emerge -e system' I am sourcing a file of individual `emerge --nodeps' commands, created by some postprocessing of an `emerge -epq --color=n system' command. In this script I am doing the GCC usability test at certain points: Beginning of script, before emerging binutils, before emerging which, before emerging gcc, and after emerging gcc (binutils, which, gcc, are subsequent packages in the sequence). I am suspecting that it is not really GCC that breaks but rather `ld'. So I have added `which ld' and `ld --version' commands along with the GCC usability tests. More to follow when the script has once again ground to a halt.
OK, here are some more details of what goes on. Just before binutils is emerged, as part of `emerge -e system', the environment is in fine shape. The GCC is in $EPREFIX/tmp, and the `ld' program is /usr/bin/ld (identifying itself as "GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux)"). Then, just before sys-apps/which is emerged, the GCC is still in $EPREFIX/tmp, but the `ld' program is now $EPREFIX/usr/bin/ld. Typing `ld --version' however yields "GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux)", just like before. This ld program is most likely non-functional. Attempting to compile and link the test program produces binutils-config: warning: no GCC found on your system! /lib/libc.so.6: undefined reference to `__libc_stack_end@GLIBC_2.1' /lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `___tls_get_addr@GLIBC_2.3' /lib/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE' $EPREFIX/usr/bin/ld is a symlink to i686-pc-linux-gnu-ld, which is in turn a symlink to $EPREFIX//usr/i686-pc-linux-gnu/bin/ld (absolute path with a doubled slash before the 'usr' directory name). This object is, forgiving the doubled slash, a binary executable. Analyzing it with `strings' shows that it contains the string "binutils-config: warning: no GCC found on your system!". In conclusion then, the `emerge -e system' emerges binutils, thereby installing an `ld' program to $EPREFIX/usr/bin which appears to be non-functional. Later on, when this program is used, there is an emerge failure. It appears that this happens somewhere during the `emerge gcc' that follows soon after binutils.
(In reply to comment #47) > Then, just before sys-apps/which is emerged, the GCC is still in $EPREFIX/tmp, > but the `ld' program is now $EPREFIX/usr/bin/ld. Typing `ld --version' however > yields "GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux)", just like before. That is weird! That means the wrapper doesn't actually find the prefixed ld/binutils. The ld that you run is the small wrapper program that binutils-config installs. It is correct that you find the "no GCC on your system" message there, as it is the wrapper program, not the linker itself. I start to think you found a really nasty bootstrap bug here. Can you post your PATH variable contents here? The wrapper program uses it to scan for the linker. See the source http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/sys-devel/binutils-config/files/ldwrapper-1.2.c What I don't understand is, that if the path is insufficient, it should fall back to calling binutils-config itself. That last step is slow, but should at least work. What does `binutils-config --get-bin-path` return for you?
The PATH: /tmp/local/g13/usr/bin /tmp/local/g13/bin /tmp/local/g13/tmp/usr/bin /tmp/local/g13/tmp/bin /home/erarafo/.afs/1/rbin /home/erarafo/.afs/1/pbin /env/seki/bin /home/erarafo/.afs/1/ibin /usr/atria/bin /usr/afsws/bin /usr/openwin/bin /opt/kde3/bin /opt/gnome/bin /usr/games /home/erarafo/bin /usr/bin/X11 /usr/bin /bin /usr/sbin /sbin /usr/lib/java/jre/bin /app/arc/0/bin /usr/openwin/bin /usr/dt/bin /usr/ccs/bin /usr/sbin /sbin > which binutils-config /tmp/local/g13/usr/bin/binutils-config > binutils-config --get-bin-path !!! Problem with sandbox binary. Disabling... /tmp/local/g13/usr/i686-pc-linux-gnu/binutils-bin/2.18.50.0.2
just for the fun of it... can you edit etc/make.conf to set FEATURES="-sandbox" such that binutils-config won't complain about not being able to start sandbox any more and see if compilation of the small program suddenly works?
I tried it. The complaint goes away. But the small program fails to compile+link just like before.
do you have strace installed on the SuSE box? I'd like to see what the final exec call of the ldwrapper is.
/usr/bin/strace is there. Not quite sure how to go about this .. I did cd /tmp/local/g13/usr/i686-pc-linux-gnu/bin mv ld ld-displaced cat <<'EOF' >ld #!/bin/sh exec strace /tmp/local/g13/usr/i686-pc-linux-gnu/bin/ld-displaced "$@" EOF chmod +x ld and then a re-run of `gcc -o test test.c'. There was some output, to be attached.
Created attachment 135803 [details] strace output
Hmm .... maybe not a good thing to rename the `ld' binary executable. I intercepted the arguments that ld-displaced got, and re-renamed the binary back to "ld" and ran it with the arguments. This produced a different output. That is not correct either though, as one of the argument is the .o file to be linked, in /tmp, which is no longer present. Will have to take a break for some real life job now. Back again later today.
Created attachment 135808 [details] strace output, second attempt I attach this strace output after all. Maybe it is usable for debugging, for example if the ld program examines its environment and aborts before it even tries to look for the non-existent /tmp/*.o file to be linked.
Alas, no, the program definitely tries to open the /tmp/ccc*.o file. Oh well, a third run will be needed with everything in place.
what I see is that it looks like it invokes the correct linker. However the flags it passes to it (which you intercepted) look like voodoo to me. What happens if you do the linking yourself? e.g. % gcc -c -o test.o test.c % ld -o test test.o and % /tmp/local/g13/usr/i686-pc-linux-gnu/binutils-bin/2.18.50.0.2/ld -o test test.o
Created attachment 135814 [details] strace output, 2 different linker invocations ... hope I got it all right ..
I think I have a better strace capture now. This is how I made it, 1. Rename the binary "ld" in $EPREFIX/usr/i686-pc-linux-gnu/bin to something else. 2. In that directory, create a shellscript that captures the arguments it gets to /dev/shm/args, and makes a backup copy of the file which is passed as argument 13 (this will be the *.o file created by gcc). 3. Run `cd $EPREFIX; gcc -o test test.c'. This finishes silently and happily, because the shellscript was invoked. 4. Edit /dev/shm/args so that the 13th argument is now the backed-up *.o file. 5. Remove the shellscript, restore the binary "ld" from step 1. 6. Run strace ld `cat /dev/shm/args`. In this way ldwrapper gets all the hairy arguments that it would normally get when running `gcc -o test test.c'. The strace will be attached as strace-5.txt. It shows that the real prefix-gentoo linker is invoked and works hard for a while. At the end it does an "unlink" of the would-be binary named "test". Finally, if running the ld command (6) with no strace the result is as usual, binutils-config: warning: no GCC found on your system! /lib/libc.so.6: undefined reference to `__libc_stack_end@GLIBC_2.1' /lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `___tls_get_addr@GLIBC_2.3' /lib/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE'
Created attachment 135835 [details] a better strace of what the ld-wrapper and real ld is doing
This problem could not be reproduced on a cleanly installed SUSE Enterprise Server 9 SP 3 machine. Apparently the machine under investigation is having something broken with the system libraries, or with symlinks pointing to libraries. It is not easy to find a workaround for the machine in question, and even if a workaround could be found it is questionable if it should be included in the prefix-gentoo software distribution. Resolving as INVALID.
