From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L14NP-000704-RV for garchives@archives.gentoo.org; Fri, 14 Nov 2008 19:30:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E7490E01F1; Fri, 14 Nov 2008 19:30:41 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id A65CCE01F1 for ; Fri, 14 Nov 2008 19:30:41 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L14NG-00034v-Qb for gentoo-amd64@lists.gentoo.org; Fri, 14 Nov 2008 19:30:34 +0000 Received: from ip68-230-99-190.ph.ph.cox.net ([68.230.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Nov 2008 19:30:34 +0000 Received: from 1i5t5.duncan by ip68-230-99-190.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Nov 2008 19:30:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Can not compile gcc Date: Fri, 14 Nov 2008 19:30:28 +0000 (UTC) Message-ID: References: <2a21586d0811141002p735a3839h74ec70ff8dd7f524@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-99-190.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 1cf519db-c51a-45bc-8b53-9e8c34500e91 X-Archives-Hash: dd3aee07050c2ce37a935c64cd06a500 "Mansour Al Akeel" posted 2a21586d0811141002p735a3839h74ec70ff8dd7f524@mail.gmail.com, 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/ -isyste= m > /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=20 don't like it, on most Linux related lists at least, that it's really not= =20 a good idea. We have a choice as to whether to reply or not, and some of= =20 the guys that have been around the longest and therefore tend to have the= =20 most wisdom to apply to a problem, may not reply to HTML posts at all --=20 or even see them in some cases, if they filter them out, as I do for=20 regular mail. Do you really want to potentially kill the single reply=20 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=20 gcc it just built while bootstrapping itself and is there testing, to=20 compile the test in 32-bit mode. It (I think) builds the 64-bit stuff=20 first, and is then failing on the 32-bit stuff. IOW, it's an issue=20 related to the 32-bit aspect of the compile for both 64-bit and 32-bit=20 support, that you get when you are running a multilib profile. Personally, since I don't do the proprietaryware that's the biggest=20 reason to do 32-bit compatibility in the first place, and all the=20 freedomware I run has long since been 64-bit, I didn't have any reason to= =20 stay with multilib. And, since it gave me headaches like this every so=20 often, and even when it was working, both gcc and glibc, which are both=20 already fairly long merges, took effectively double the time to build=20 because they were being built for both 64-bit and 32-bit, I had lots of=20 reason NOT to stay with multilib. So I switched to the no-multilib profile and simplified my life with=20 faster and more trouble-free gcc and glibc compiles, and have been VERY=20 happy I did so. Of course if you're still held captive by some proprietaryware or other=20 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= =20 broken 32-bit sandbox. For that, try turning it off and remerging=20 sandbox. If it works, you should then be able to remerge gcc without=20 issue and remerge sandbox normally. FEATURES=3D-sandbox emerge sandbox If that doesn't work, one thing that has been a problem in the past but=20 one would hope doesn't apply any more, is if you had eselect-compiler and= =20 gcc-config-2.0 merged at some point. If you did, there's a bug on it you= =20 should look at. If you didn't, this one doesn't apply. There are various other possibilities due to various broken configs and=20 etc relating to the 32-bit side of the multilib toolchain. Often the=20 simplest solution to these is to remerge a known working usually older=20 gcc, hopefully overwriting whatever's wrong with your current setup,=20 after which you can normally rebuild the newer gcc using the working old=20 one, and be back on track. =20 If you've been running FEATURES=3Dbuildpkg for some time, you may have=20 several older versions of gcc in your binary package archive and can just= =20 remerge one of them, temporarily downgrading gcc to fix the problem, then= =20 use it to merge a current gcc. This of course is one of the benefits of=20 running with that feature enabled. If you have NOT been running with FEATURES=3Dbuildpkg enabled, you have a= =20 choice. If you have another working gentoo/amd64 machine available, you=20 can quickpkg it's gcc, copy it over and emerge -K it onto the affected=20 machine. Otherwise you'll have to choose between trusting a version=20 someone else may offer you and grabbing one off the latest gentoo/amd64=20 install stages. This would involve downloading a stage tarball,=20 untarring it somewhere temporary, chrooting into it, doing a quickpkg of=20 the gcc therein, then from outside the chroot, doing an emerge -K of the=20 binpkg built by the quickpkg. When you get your system working correctly again (but before you go back=20 to your system/world rebuild), you may wish to consider=20 FEATURES=3Dbuildpkg. If you turn it on, you can then do your system/worl= d=20 rebuild and will have binpkgs of everything, available if you need them. = =20 After awhile, you'll have a couple older versions of most packages as=20 well, in case you need to revert to an older one for some reason. It's a= =20 quite handy thing to have available, and can sure save a lot of needless=20 recompiling at times, even if you /don't/ ever use it to get out of=20 another hole like a busted gcc. Spacewise, a full FEATURES=3Dbuildpkg system and world set, with what I=20 have merged here, runs about a gig, but you'll want at least 2 gigs=20 available for binpkgs and preferably 4 gigs or so, so you don't have to=20 clean out old versions too often, on whatever partition you decide to=20 store them on. The default storage location is $PORTDIR/packages, IIRC,=20 but you can point portage at a different location by setting PKGDIR in=20 make.conf as appropriate. --=20 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