Emerged gcc-3.4.0-r2. Remerged every package on the entire system with 3.4.0 that would merge (there were only 5-6 that would not). Enter gcc-3.4.0-r6. Looks good, time to move up. Set /etc/make.profile to gcc34-amd64, and try to emerge. This is the last snippet of what I get: config.status: executing default-1 commands Adding multilib support to Makefile in /var/tmp/portage/gcc-3.4.0-r6/work/gcc-3.4.0/libstdc++-v3 multidirs=32 with_multisubdir= Running configure in multilib subdirs 32 pwd: /var/tmp/portage/gcc-3.4.0-r6/work/build/x86_64-pc-linux-gnu/libstdc++-v3 Running configure in multilib subdir 32 pwd: /var/tmp/portage/gcc-3.4.0-r6/work/build/x86_64-pc-linux-gnu mkdir 32 configure: creating cache ./config.cache checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -m32 checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/var/tmp/portage/gcc-3.4.0-r6/work/build' make: *** [profiledbootstrap] Error 2 I've tried: Using gcc-3.4.0-r2 with '-O2 -ftracer -fweb -pipe -fomit-frame-pointer -march=k8' gcc-3.4.0-r2 with '-O2 -pipe' gcc-3.3.3-r5 with '-O2 -pipe' Always the same error. The contents of the config.log that are supposed to give me more details are: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:581: checking host system type configure:602: checking target system type configure:620: checking build system type configure:675: checking for a BSD compatible install configure:2844: checking for x86_64-pc-linux-gnu-ar configure:2877: checking for ar configure:2916: checking for x86_64-pc-linux-gnu-as configure:2949: checking for as configure:2988: checking for x86_64-pc-linux-gnu-dlltool configure:3021: checking for dlltool configure:3060: checking for x86_64-pc-linux-gnu-ld configure:3132: checking for x86_64-pc-linux-gnu-nm configure:3165: checking for nm configure:3204: checking for x86_64-pc-linux-gnu-ranlib configure:3237: checking for ranlib configure:3276: checking for x86_64-pc-linux-gnu-windres configure:3309: checking for windres configure:3348: checking for x86_64-pc-linux-gnu-objcopy configure:3381: checking for objcopy configure:3420: checking for x86_64-pc-linux-gnu-objdump configure:3453: checking for objdump configure:3502: checking for x86_64-pc-linux-gnu-ar configure:3535: checking for ar configure:3574: checking for x86_64-pc-linux-gnu-as configure:3607: checking for as configure:3646: checking for x86_64-pc-linux-gnu-dlltool configure:3679: checking for dlltool configure:3718: checking for x86_64-pc-linux-gnu-ld configure:3751: checking for ld configure:3790: checking for x86_64-pc-linux-gnu-nm configure:3823: checking for nm configure:3862: checking for x86_64-pc-linux-gnu-ranlib configure:3895: checking for ranlib configure:3934: checking for x86_64-pc-linux-gnu-windres configure:3967: checking for windres configure:4034: checking whether to enable maintainer-specific portions of Makefiles
Upon further investigation, I think I was looking at the wrong config.log. The one I quoted here was /var/tmp/portage/gcc-3.4.0-r6/work/build/config.log. I read /var/tmp/portage/gcc-3.4.0-r6/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/config.log, and I think I found the source of the problem: configure:2358: $? = 0 configure:2360: /var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/ -B/usr/x86_64-pc-li$ Reading specs from /var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/specs Configured with: /var/tmp/portage/gcc-3.4.0-r6/work/gcc-3.4.0/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4 -$ Thread model: posix gcc version 3.4.0 20040601 (Gentoo Linux 3.4.0-r6, ssp-3.4-2, pie-8.7.6.3) configure:2363: $? = 0 configure:2365: /var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/ -B/usr/x86_64-pc-li$ xgcc: `-V' must come at the start of the command line configure:2368: $? = 1 configure:2387: /var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/ -B/usr/x86_64-pc-li$ configure:2390: $? = 0 configure:2424: checking for C compiler default output file name configure:2427: /var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.4.0-r6/work/build/gcc/ -B/usr/x86_64-pc-li$ configure:2430: $? = 0 configure:2476: result: a.out configure:2481: checking whether the C compiler works configure:2487: ./a.out ./a.out: error while loading shared libraries: /lib/libsandbox.so: cannot open shared object file: No such file or directory configure:2490: $? = 127 configure:2499: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. Can't find /lib/libsandbox.so. Which of course, is there: ls -al /lib/libsandbox.so -rwxr-xr-x 1 root root 35848 May 28 11:03 /lib/libsandbox.so So I'm still confused, just confused in a different place now :)
64bit/32bit problem ?
ohhhh boy. if there isnt a 32bit sandbox, you cant compile gcc with multilib... but if you dont compile gcc with multilib, you cant compile a 32bit sandbox. that and the environment variable for disabling sandbox from inside ebuilds doesnt prevent libsandbox from being loaded... is there a way to solidly disable sandbox from inside an ebuild without having to use FEATURES="-sandbox"?
Emerge is successful with FEATURES="-sandbox" I'm leaving the status as is as I don't know if this is indicative of a bigger problem (the 'Portage needs a 32 and 64 bit libsandbox' bug, perhaps?).
The only way to isolate the disabling of sandbox would be to create a seperate ebuild for amd64 and only amd64 that sets RESTRICT="nosandbox" This completely disables the loading of sandbox and should not be taken lightly. (Thus the seperate ebuild). A PDEPEND on >=portage-2.0.50-r8 might be a good idea as well. I suggest posting a rescue tarball of 2.0.50-r8 for users to update to that are not bootstrapping from a multilib capable stage/system.
i definately dont want to use a different gcc ebuild for amd64... i would very much prefer somehow forcing installation of a 32bit sandbox. however, in order to do that i would have to force a multilib gcc and that's just not kosher either. re-assigning to amd64@gentoo.org, this isnt really a toolchain bug.
is there any objections to including a binary 32bit sandbox with portage releases for amd64? it can be compiled on any plain old x86 box and placed in /lib32.
mini irc log from #gentoo-portage: <carpaski_> I'm not sure how mismatched libs for sandbox would handled. <carpaski_> sandbox-amd64-multilib <carpaski_> Or maybe jsut sandbox-multilib <carpaski_> and install and limit it with keywords <carpaski_> Need to test different sandbox lib versions with that. <Lv> oh boy <carpaski_> I don't have any changes lined up for sandbox, so I don't imagine it will be a problem until we work out what to do. <carpaski_> sandbox-multilib-bin <Lv> carpaski_: i was thinking for the portage ebuild itself... so that if it fails the currently existing test for building a 32bit sandbox it could just throw in a 32bit bin <Lv> that way you dont accidentally get two ebuilds owning the same file <carpaski_> I don't want to start including 32bit bins in the source tarball. <carpaski_> I _could_ dep on it on amd64... <Lv> carpaski_: yeah, amd64 only <Lv> in the SRC_URI <carpaski_> multilib? ( amd64? ( sandbox-multilib-bin ) ) <Lv> ok. <carpaski_> Have that be a depend... and portage can then replace it. <carpaski_> Lv: If you want to take a shot at making up the tarball and ebuild, go ahead... otherwise you can file a bug and I'll work on it in the next day or two.
marking later since this is no longer a real issue with the 2004.3 stages
*** Bug 63377 has been marked as a duplicate of this bug. ***
