Summary: | GCC 3.4.0-r6 multilib requires a 32bit sandbox, which also requires a multilib gcc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Darryl Bleau <darrylbleau> |
Component: | New packages | Assignee: | AMD64 Project <amd64> |
Status: | RESOLVED LATER | ||
Severity: | major | CC: | eradicator, florian.huber, jcouzens |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Darryl Bleau
2004-06-07 15:33:53 UTC
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. *** |