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 1L162I-00070w-7C for garchives@archives.gentoo.org; Fri, 14 Nov 2008 21:17:02 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7C6D6E00D4; Fri, 14 Nov 2008 21:17:00 +0000 (UTC) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by pigeon.gentoo.org (Postfix) with ESMTP id 02749E00D4 for ; Fri, 14 Nov 2008 21:16:59 +0000 (UTC) Received: by fk-out-0910.google.com with SMTP id 18so1937721fks.2 for ; Fri, 14 Nov 2008 13:16:57 -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=Wzbr9BI/4Yr7zmwL9/IiNsgq9va7k0XLmRad29OzHNw=; b=FSMbUyVWVjMHwqyn1hOO7xe+dOx6qr2Z228/RCzbXYQYFPZwXvOxLQFlkUQng76LkP QhiiAY3fib7zccWLaF+15XAzE6PVsNz3sxHFoZVHqcOlFbzSJ+4gO3MJcU1GImObr+Cc pB0+5997D+wX1wiMNi3+z9wO1JNXGQ81ibcrs= 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=tNaAc/uIs9BDaDXEewYHeb/DHPUBxL1rVkuAPQJNiA6r5bIPrQQNlncT0xSLLU8Fkt NMNPsCuwkKXyx/X3181Zq2SIByk9UPmRLSC4x2GsDXSB4dxW2AAR/BBCQauNMFYAmhWC noceL1g0gxf/pOgP7ERMDGh4pYbeyo5FxU85Y= Received: by 10.181.139.10 with SMTP id r10mr375790bkn.64.1226697417320; Fri, 14 Nov 2008 13:16:57 -0800 (PST) Received: by 10.181.16.19 with HTTP; Fri, 14 Nov 2008 13:16:57 -0800 (PST) Message-ID: <43ba12950811141316h34dea6cfl933ad9206fcc37c9@mail.gmail.com> Date: Fri, 14 Nov 2008 22:16:57 +0100 From: "Tonko Mulder" To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Can not compile gcc In-Reply-To: <2a21586d0811141154o1b037f3fxa913ac312fe88f35@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 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a21586d0811141002p735a3839h74ec70ff8dd7f524@mail.gmail.com> <2a21586d0811141154o1b037f3fxa913ac312fe88f35@mail.gmail.com> X-Archives-Salt: f0931956-a73b-425b-ab29-368f6c808c42 X-Archives-Hash: 4d36ce1fabb1e5fc855ebfb450abc572 I got the same error because I had the noexec option in my fstab file. The option was set on my swap file bus affected my whole system. my 2c 2008/11/14, Mansour Al Akeel : > 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 >> >> > > -- Verzonden vanaf mijn mobiele apparaat Tonko