Re: [gentoo-amd64] Re: Can not compile gcc

["Mansour Al Akeel" <mansour.alakeel@gmail.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@cox.net> wrote:
>
> "Mansour Al Akeel" <mansour.alakeel@gmail.com> 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
>
>