Re: [gentoo-amd64] Can not compile gcc

[Tonko Mulder]

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 <mansour.alakeel@×××××.com>:
> 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@×××.net> wrote:
>>
>> "Mansour Al Akeel" <mansour.alakeel@×××××.com> posted
>> 2a21586d0811141002p735a3839h74ec70ff8dd7f524@××××××××××.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