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 1L14kR-0000ZM-Lm for garchives@archives.gentoo.org; Fri, 14 Nov 2008 19:54:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 077C9E01E0; Fri, 14 Nov 2008 19:54:31 +0000 (UTC) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by pigeon.gentoo.org (Postfix) with ESMTP id 99BB5E01E0 for ; Fri, 14 Nov 2008 19:54:30 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so1682767fga.14 for ; Fri, 14 Nov 2008 11:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Ubbela8jckGHfzYRzg8O4yVbqFTQpqeDffWfq02ZiNA=; b=kVqkac+PkEvfI46tA03h+JmIa+8xusgZPxkayYiQ7LaiA6RvKmXShTEcw8zT7lS9Yq PonyauF+RSUsaYlP47LAJMdyu+CAH8pu6oqEdhUX18t6li6VQ2JJS1/www+EcEDEEkKT WkUIiDYMS55PKgTky0kPJ6BtFUZIBqYwIQfN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=OaLSPlPXQ1pWIagZmFsMd2/zOPSLyg3rvNSSDGLqssgOZjkLOl6wo76Yt+0PXgbzjr 2yvRB2YGQCM+3C/HeCnegAr4sfaKmy6TUMkG6Gq2XV3XNLZi2OrADUw5aCa7+KB9Ss7D AqLdelY/eblxq34W4DeSuNkP47gGONDHWskcY= Received: by 10.181.141.18 with SMTP id t18mr344795bkn.203.1226692468341; Fri, 14 Nov 2008 11:54:28 -0800 (PST) Received: by 10.181.16.2 with HTTP; Fri, 14 Nov 2008 11:54:28 -0800 (PST) Message-ID: <2a21586d0811141154o1b037f3fxa913ac312fe88f35@mail.gmail.com> Date: Fri, 14 Nov 2008 15:54:28 -0400 From: "Mansour Al Akeel" To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: Can not compile gcc In-Reply-To: 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=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a21586d0811141002p735a3839h74ec70ff8dd7f524@mail.gmail.com> X-Archives-Salt: 92ca29de-d11a-4ad3-bd06-2a256fe22499 X-Archives-Hash: cacfa9a48db29a4eec8911086c897486 First of all, I apologies for the HTML formatting. On my fedora, I use Thunderbird, and have the emails sent in plain text automatically. Since My system is being UPGRADED to gentoo, I am stuck with the web interface, and totally forgot the plain text requirement. Back again to my problem, I have modified my make.conf to this one: ======================================================= CFLAGS="-march=athlon64 -O2 -pipe" CXXFLAGS="${CFLAGS}" CHOST="x86_64-pc-linux-gnu" MAKEOPT="-j2" #FEATURES="ccache" FEATURES=-sandbox emerge sandbox" USE="X aac aiglx alsa aoss asf bzip2 cairo dbus dvd emerald fam firefox gif glitz gnome gstreamer gtk hal java jpeg mad mp3 mp4 new-login nptl nptlonly nsplugin opengl pdf png samba spell sqlite svg symlink threads tiff truetype unicode x264 xcomposite xinerama xml xorg xscreensaver xv xvid -arts -eds -esd -fortran -ipv6 -kde -qt3 -qt4" VIDEO_CARDS="NVIDIA" ======================================================= And trying the emerge again. I will report the results. I am not stuck with any 32 bit properiatory softwares, but you never know, I may need it. I will keep the option of getting rid of the 32 bit as the last option. Thank you. On Fri, Nov 14, 2008 at 3:30 PM, Duncan <1i5t5.duncan@cox.net> wrote: > > "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/ -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 > >