Summary: | sys-apps/sandbox emerge fails when an incomplete i686 cross-compiiler is installed | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Vincent Legoll <vincent.legoll> |
Component: | Sandbox | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | albzey, owen, renean |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
config.log file with error and infos
config.log |
Description
Vincent Legoll
2007-12-19 20:56:14 UTC
Created attachment 138911 [details]
config.log file with error and infos
As a workaround: cd /usr/x86_64-pc-linux-gnu mv i686-pc-linux-gnu i686-pc-linux-gnu-old emerge sandbox mv i686-pc-linux-gnu-old i686-pc-linux-gnu has worked for me... I get the same error here without a special crosscompiler. Moving out all the /usr/bin/i686-* to a tmp-dir did get me going, but that can't be the solution... Same thing for me without any crosscompilators. Moving /usr/bin/i686-* to a tmp-dir also helped. Got the same error while trying to emerge sandbox-1.2.20_alpha2-r1 it failed because you have an incomplete i686 toolchain. you only have the C compiler, not glibc and the second stage compiler. if you had a full proper toolchain installed, it'd actually work just fine. try exporting CC=gcc before emerging sandbox. I am on amd64 with a fully 64bit system. It should not even think about any 32bit compilers! And I am not using any (special) crosscompiling stuff. Only standard amd64 things are going on here. that's an incorrect statement. you're on an amd64 multilib system. thus your system has both 32bit and 64bit pieces installed. if you dont have an i686 cross-compiler installed, then why do you have any i686 binaries at all ? what installed those things in /usr/bin/i686-* ? do you have a /usr/i686-pc-linux-gnu directory ? Okay. But I didn't install any crosscompiling suite explicitely by hand like the original poster did. So I did not "want" to have the crosscompiler. And I don't want to mess with what compiler is the right one to use. Thats the task of the ebuild or configure-script or the systems profile. And something there is not working right if emerging sandbox (regardless which version) fails because it picks up the wrong compiler. And from my point of view I only have one compiler, everything else is imposed by the system and should thus be handled correctly by the system. I even un-installed all the old gcc versions because I didn't want to mess with that anymore. stop giving long winded explanations about things that dont matter and answer the questions i posted please I was certain I did comment here with the answers. Weird. I'm reposting: I do have: /usr/i686-pc-linux-gnu/lib with files: libbfd-2.18.so libbfd.so libopcodes-2.18.so libopcodes.so installed by app-emulation/emul-linux-x86-baselibs-20071215 I also have in /usr/bin the files: i686-pc-linux-gnu-c++ i686-pc-linux-gnu-g++ i686-pc-linux-gnu-gccbug i686-pc-linux-gnu-cc i686-pc-linux-gnu-g77 i686-pc-linux-gnu-gcov i686-pc-linux-gnu-cpp i686-pc-linux-gnu-gcc i686-pc-linux-gnu-gfortran however equery b does not show any package as responsible for them. did (do?) you have eselect-compiler / gcc-config-2 installed ? No, I have sys-devel/gcc-config-1.3.16 pointing to the only installed compiler [1] x86_64-pc-linux-gnu-4.1.2 * Created attachment 139154 [details]
config.log
My config.log - different since I had no cross-compiler.
your issue is different ... you have old i686 wrappers installed (probably by having eselect-compiler installed on your system) simply delete the i686 binaries in /usr/bin/ (In reply to comment #7) > what installed those things in /usr/bin/i686-* ? do > you have a /usr/i686-pc-linux-gnu directory ? Sorry, I didn't see these questions... The files /usr/bin/i686-* seem to belong to nobody (who left them there?), "equery b /usr/i686-*" returns: [ Searching for file(s) /usr/i686-pc-linux-gnu in *... ] app-emulation/emul-linux-x86-baselibs-20071215 (/usr/i686-pc-linux-gnu) you two have eselect-compiler problems. delete the wrappers at /usr/bin/i686-*. Hello again, this bug reoccurred with sandbox-1.2.18.1-r3 The proposed workaround of "export CC=gcc" did the trick Regarding comment #5, no I don't have a "broken" or incomplete cross-compiler it has everything *I* need it to have and is working fine as-is. The problem arise because sandbox wants to use that as my system compiler, if sandbox depends on a fully functional cross-compiler being setup, I think this requirement should be expressed as a dependency in the ebuild. I stumbled over that problem too. I have a cross compiler configuration with i686-, powerpc- and my host is x86_64. After searching the config.log I found that the used i686 compiler did not know about the -march=core2 option so I upgraded it and that did the job. But why does sandbox build 32 bit binaries at all. And how is it supposed to do that on systems which are multilib, but with no i686 gcc installed (there is no compiler in emul-linux-x86)? *** Bug 225167 has been marked as a duplicate of this bug. *** I too can confirm this bug. The following failed: crossdev -t i686-pc-linux-gnu -s4 --without-headers --g 4.3.1 However, i686-pc-linux-gnu/gcc and i686-pc-linux-gnu/linux-headers were reorted as installed by portage. Emerging sandbox (for an emerge -e world) failed until i removed the the 2 packages mentioned previously. please retest with sandbox-1.3.0 *** Bug 255341 has been marked as a duplicate of this bug. *** Continuing from Bug 255341, I emerged using "CC=x86_64-pc-linux-gnu-gcc emerge sandbox", then updated portage to allow the new lzma patch format, then tried updating to unstable sandbox (1.3.2), and it worked! It found and used the correct compiler: * Configuring sandbox for ABI=x86... * econf: updating sandbox-1.3.2/config.sub with /usr/share/gnuconfig/config.sub * econf: updating sandbox-1.3.2/config.guess with /usr/share/gnuconfig/config.guess ../sandbox-1.3.2//configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib32 --build=x86_64-pc-linux-gnu <snip> checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc Thanks guys! Owen, thanks for reporting back with your success. It sounds like sandbox 1.3 ebuilds have indeed resolved this problem of picking the wrong toolchain. should be fixed now http://sources.gentoo.org/eclass/multilib.eclass?r1=1.71&r2=1.72 This bug breaks #261670 I think you need to restore the environment new issue, new bug |