"Mansour Al Akeel" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 14 Nov 2008 14:02:19 -0400:
> checking for x86_64-pc-linux-gnu-gcc... > /var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc > -B/var/tmp/portage/sys-devel/gcc-4.1.2/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 First, please kill the HTML. There's enough "old fogies" like me that don't like it, on most Linux related lists at least, that it's really not a good idea. We have a choice as to whether to reply or not, and some of the guys that have been around the longest and therefore tend to have the most wisdom to apply to a problem, may not reply to HTML posts at all -- or even see them in some cases, if they filter them out, as I do for regular mail. Do you really want to potentially kill the single reply that might have otherwise been the only one with a working fix? Anyway, back to your question. See that -m32? That's telling the new gcc it just built while bootstrapping itself and is there testing, to compile the test in 32-bit mode. It (I think) builds the 64-bit stuff first, and is then failing on the 32-bit stuff. IOW, it's an issue related to the 32-bit aspect of the compile for both 64-bit and 32-bit support, that you get when you are running a multilib profile. Personally, since I don't do the proprietaryware that's the biggest reason to do 32-bit compatibility in the first place, and all the freedomware I run has long since been 64-bit, I didn't have any reason to stay with multilib. And, since it gave me headaches like this every so often, and even when it was working, both gcc and glibc, which are both already fairly long merges, took effectively double the time to build because they were being built for both 64-bit and 32-bit, I had lots of reason NOT to stay with multilib. So I switched to the no-multilib profile and simplified my life with faster and more trouble-free gcc and glibc compiles, and have been VERY happy I did so. Of course if you're still held captive by some proprietaryware or other that's only available in 32-bit, that's not going to be an option for you. There are several possible triggers for this problem. The first one is a broken 32-bit sandbox. For that, try turning it off and remerging sandbox. If it works, you should then be able to remerge gcc without issue and remerge sandbox normally. FEATURES=-sandbox emerge sandbox If that doesn't work, one thing that has been a problem in the past but one would hope doesn't apply any more, is if you had eselect-compiler and gcc-config-2.0 merged at some point. If you did, there's a bug on it you should look at. If you didn't, this one doesn't apply. There are various other possibilities due to various broken configs and etc relating to the 32-bit side of the multilib toolchain. Often the simplest solution to these is to remerge a known working usually older gcc, hopefully overwriting whatever's wrong with your current setup, after which you can normally rebuild the newer gcc using the working old one, and be back on track. If you've been running FEATURES=buildpkg for some time, you may have several older versions of gcc in your binary package archive and can just remerge one of them, temporarily downgrading gcc to fix the problem, then use it to merge a current gcc. This of course is one of the benefits of running with that feature enabled. If you have NOT been running with FEATURES=buildpkg enabled, you have a choice. If you have another working gentoo/amd64 machine available, you can quickpkg it's gcc, copy it over and emerge -K it onto the affected machine. Otherwise you'll have to choose between trusting a version someone else may offer you and grabbing one off the latest gentoo/amd64 install stages. This would involve downloading a stage tarball, untarring it somewhere temporary, chrooting into it, doing a quickpkg of the gcc therein, then from outside the chroot, doing an emerge -K of the binpkg built by the quickpkg. When you get your system working correctly again (but before you go back to your system/world rebuild), you may wish to consider FEATURES=buildpkg. If you turn it on, you can then do your system/world rebuild and will have binpkgs of everything, available if you need them. After awhile, you'll have a couple older versions of most packages as well, in case you need to revert to an older one for some reason. It's a quite handy thing to have available, and can sure save a lot of needless recompiling at times, even if you /don't/ ever use it to get out of another hole like a busted gcc. Spacewise, a full FEATURES=buildpkg system and world set, with what I have merged here, runs about a gig, but you'll want at least 2 gigs available for binpkgs and preferably 4 gigs or so, so you don't have to clean out old versions too often, on whatever partition you decide to store them on. The default storage location is $PORTDIR/packages, IIRC, but you can point portage at a different location by setting PKGDIR in make.conf as appropriate. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
