[gentoo-amd64] Can not compile gcc

[gentoo-amd64] Can not compile gcc

[Mansour Al Akeel]

[-- Attachment #1: Type: text/plain, Size: 5087 bytes --]

Hello all, I have updated my use flags.

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"

And then tried :
emerge -vuD --newuse world

It failed with the error:
=============================================================
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-target-libstdc++-v3] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make: *** [profiledbootstrap] Error 2
 *
 * ERROR: sys-devel/gcc-4.1.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 4646:  Called toolchain_src_compile
 *             environment, line 5164:  Called gcc_src_compile
 *             environment, line 2972:  Called gcc_do_make
 *             environment, line 2795:  Called die
 * The specific snippet of code:
 *       emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}"
LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET} || die
"emake failed with ${GCC_MAKE_TARGET}";
 *  The die message:
 *   emake failed with profiledbootstrap
 *
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/environment'.
 *

 * Messages for package app-editors/nano-2.1.5:

 * More helpful info about nano, visit the GDP page:
 * http://www.gentoo.org/doc/en/nano-basics-guide.xml

 * Messages for package sys-devel/gcc-4.1.2:

 *
 * ERROR: sys-devel/gcc-4.1.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 4646:  Called toolchain_src_compile
 *             environment, line 5164:  Called gcc_src_compile
 *             environment, line 2972:  Called gcc_do_make
 *             environment, line 2795:  Called die
 * The specific snippet of code:
 *       emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}"
LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET} || die
"emake failed with ${GCC_MAKE_TARGET}";
 *  The die message:
 *   emake failed with profiledbootstrap
 *
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/environment'.
 *
 * Regenerating GNU info directory index...
 * Processed 132 info files.
 * IMPORTANT: 3 config files in '/etc' need updating.
 * See the CONFIGURATION FILES section of the emerge
 * man page to learn how to update config files.
=============================================================
The log file:

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
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-target-libstdc++-v3] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make: *** [profiledbootstrap] Error 2
 *
 * ERROR: sys-devel/gcc-4.1.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 4646:  Called toolchain_src_compile
 *             environment, line 5164:  Called gcc_src_compile
 *             environment, line 2972:  Called gcc_do_make
 *             environment, line 2795:  Called die
 * The specific snippet of code:
 *       emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}"
LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET} || die
"emake failed with ${GCC_MAKE_TARGET}";
 *  The die message:
 *   emake failed with profiledbootstrap
 *
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/environment'.
 *


Any idea ?

[-- Attachment #2: Type: text/html, Size: 7362 bytes --]

Re: [gentoo-amd64] Can not compile gcc

[Barry Schwartz]

Mansour Al Akeel <mansour.alakeel@gmail.com> skribis:
> Any idea ?

If you use ccache, try emptying it.

Re: [gentoo-amd64] Can not compile gcc

[Justin]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

Barry Schwartz schrieb:
> Mansour Al Akeel <mansour.alakeel@gmail.com> skribis:
>   
>> Any idea ?
>>     
>
> If you use ccache, try emptying it.
>
>
>
>   
I think there is something else wrong, because it fails in the configure
phase.

Send us an emerge --info output, please.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-amd64] Can not compile gcc

[Justin]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Branko Badrljica schrieb:
> Justin wrote:
>> Barry Schwartz schrieb:
>>  
>>> Mansour Al Akeel <mansour.alakeel@gmail.com> skribis:
>>>      
>>>> Any idea ?
>>>>           
>>> If you use ccache, try emptying it.
>>>
>>>
>>>
>>>       
>> I think there is something else wrong, because it fails in the configure
>> phase.
>>
>> Send us an emerge --info output, please.
>>
>>   
>
> I'm not an expert, but it seems that it was trying to compile 64-bit
> test code with -m32 flag:
>
> >The log file:
> >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
>
>
> Perhaps he should check his make.conf for CHOST and CLAGS ?
>
Sharp eyed guy!!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-amd64] Can not compile gcc

[Mansour Al Akeel]

[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]

I have already initiated the build again after I modified the USE flags to
the defaults that came with the installation cd. Here's the dfaults:
==================================================================
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /etc/make.conf.example for a more detailed example.
CFLAGS="-O2 -pipe"
CXXFLAGS="-O2 -pipe"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before
changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE flags that were used in addition to what is provided by
the
# profile used for building.
USE="mmx sse sse2"
=================================================================

I am still waiting to see the results. When the error occured I was using
the following make.conf:

======================================================
CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

CHOST="x86_64-pc-linux-gnu"

MAKEOPT="-j2"
FEATURES="ccache"

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"
===================================================

I should have kept a back up of the build.log but if anyone needs it, I can
do emerge again, and send you the file, as I have this strong feeling that
the build I am doing now will fail as well.
Thank you all.


On Fri, Nov 14, 2008 at 2:40 PM, Justin <justin@j-schmitz.net> wrote:

> Branko Badrljica schrieb:
> > Justin wrote:
> >> Barry Schwartz schrieb:
> >>
> >>> Mansour Al Akeel <mansour.alakeel@gmail.com> skribis:
> >>>
> >>>> Any idea ?
> >>>>
> >>> If you use ccache, try emptying it.
> >>>
> >>>
> >>>
> >>>
> >> I think there is something else wrong, because it fails in the configure
> >> phase.
> >>
> >> Send us an emerge --info output, please.
> >>
> >>
> >
> > I'm not an expert, but it seems that it was trying to compile 64-bit
> > test code with -m32 flag:
> >
> > >The log file:
> > >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
> >
> >
> > Perhaps he should check his make.conf for CHOST and CLAGS ?
> >
> Sharp eyed guy!!
>
>

[-- Attachment #2: Type: text/html, Size: 3746 bytes --]

Re: [gentoo-amd64] Can not compile gcc

[Beso]

2008/11/14 Mansour Al Akeel <mansour.alakeel@gmail.com>:
> I have already initiated the build again after I modified the USE flags to
> the defaults that came with the installation cd. Here's the dfaults:
> ==================================================================
> # These settings were set by the catalyst build script that automatically
> # built this stage.
> # Please consult /etc/make.conf.example for a more detailed example.
> CFLAGS="-O2 -pipe"
> CXXFLAGS="-O2 -pipe"
> # WARNING: Changing your CHOST is not something that should be done lightly.
> # Please consult http://www.gentoo.org/doc/en/change-chost.xml before
> changing.
> CHOST="x86_64-pc-linux-gnu"
> # These are the USE flags that were used in addition to what is provided by
> the
> # profile used for building.
> USE="mmx sse sse2"
> =================================================================
>
> I am still waiting to see the results. When the error occured I was using
> the following make.conf:
>
> ======================================================
> CFLAGS="-march=athlon64 -O2 -pipe"
> CXXFLAGS="${CFLAGS}"
>
> CHOST="x86_64-pc-linux-gnu"
>
> MAKEOPT="-j2"
> FEATURES="ccache"
>
> 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"
> ===================================================
>
> I should have kept a back up of the build.log but if anyone needs it, I can
> do emerge again, and send you the file, as I have this strong feeling that
> the build I am doing now will fail as well.
> Thank you all.
>
>
> On Fri, Nov 14, 2008 at 2:40 PM, Justin <justin@j-schmitz.net> wrote:
>>
>> Branko Badrljica schrieb:
>> > Justin wrote:
>> >> Barry Schwartz schrieb:
>> >>
>> >>> Mansour Al Akeel <mansour.alakeel@gmail.com> skribis:
>> >>>
>> >>>> Any idea ?
>> >>>>
>> >>> If you use ccache, try emptying it.
>> >>>
>> >>>
>> >>>
>> >>>
>> >> I think there is something else wrong, because it fails in the
>> >> configure
>> >> phase.
>> >>
>> >> Send us an emerge --info output, please.
>> >>
>> >>
>> >
>> > I'm not an expert, but it seems that it was trying to compile 64-bit
>> > test code with -m32 flag:
>> >
>> > >The log file:
>> > >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
>> >
>> >
>> > Perhaps he should check his make.conf for CHOST and CLAGS ?
>> >
>> Sharp eyed guy!!
>>
>
>


hmm. you seem to have a problem with gcc. try removing the ccache
feature and compile it without. usually this works.

-- 
dott. ing. beso

[gentoo-amd64] Re: Can not compile gcc

[Duncan]

"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

Re: [gentoo-amd64] Can not compile gcc

[Branko Badrljica]

Justin wrote:
> Barry Schwartz schrieb:
>   
>> Mansour Al Akeel <mansour.alakeel@gmail.com> skribis:
>>   
>>     
>>> Any idea ?
>>>     
>>>       
>> If you use ccache, try emptying it.
>>
>>
>>
>>   
>>     
> I think there is something else wrong, because it fails in the configure
> phase.
>
> Send us an emerge --info output, please.
>
>   

I'm not an expert, but it seems that it was trying to compile 64-bit 
test code with -m32 flag:

 >The log file:
 >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


Perhaps he should check his make.conf for CHOST and CLAGS ?

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

[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" <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
>
>

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@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
>>
>>
>
>

-- 
Verzonden vanaf mijn mobiele apparaat

Tonko

Re: [gentoo-amd64] Can not compile gcc

[Mansour Al Akeel]

I don't know what you mean by swap file bus. The only noexec I have is
on /dev/shm. I jam still waiting for gcc to finish building, no
problems so far, but again, issue may occur any time. Here's my fstab.
If you see anything wrong please let me know.

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
/dev/sda3               /               ext3            noatime         0 1
/dev/sda5               none            swap            sw              0 0
/dev/cdrom              /mnt/cdrom      auto            noauto,ro       0 0
#/dev/fd0               /mnt/floppy     auto            noauto          0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
#  use almost no memory if not populated with files)
shm                     /dev/shm        tmpfs
nodev,nosuid,noexec     0 0




On Fri, Nov 14, 2008 at 5:16 PM, Tonko Mulder <tonko.mulder@gmail.com> wrote:
> 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@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
>>>
>>>
>>
>>
>
> --
> Verzonden vanaf mijn mobiele apparaat
>
> Tonko
>
>

Re: [gentoo-amd64] Can not compile gcc

[Christoph Mende]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

On Fri, 14 Nov 2008 14:02:19 -0400
"Mansour Al Akeel" <mansour.alakeel@gmail.com> wrote:

> Any idea ?
Enable IA32_EMULATION in your kernel

-- 
Christoph Mende
Gentoo/AMD64 Operational Lead and Release Engineering
GPG: EE2A 454A 6A3B A2D8 E43B  FF45 2A19 C3B3 6DA0 C1AF

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-amd64] Can not compile gcc

[Mansour Al Akeel]

OK, that's it. I have this in my make.conf, and emerged gcc with:
emerge -vuD --newuse gcc
----------------------------------------------------------------------------------------------------------------------------------------------
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"
----------------------------------------------------------------------------------------------------------------------------------------------

Now, that's what I am getting.

checking for gawk... gawk
checking whether make sets $(MAKE)... yes
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
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run
C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-target-libstdc++-v3] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make: *** [profiledbootstrap] Error 2
 *
 * ERROR: sys-devel/gcc-4.1.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 4638:  Called toolchain_src_compile
 *             environment, line 5156:  Called gcc_src_compile
 *             environment, line 2964:  Called gcc_do_make
 *             environment, line 2787:  Called die
 * The specific snippet of code:
 *       emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}"
LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET}
|| die "emake failed with ${GCC_MAKE_TARGET}";
 *  The die message:
 *   emake failed with profiledbootstrap
 *
 * If you need support, post the topmost build error, and the call
stack if relevant.
 * A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/environment'.
 *

I just enabled IA32_EMULATION and recompiling my kernel. I downloaded
the latest kernel form kernel instead of the one that comes with
gentoo. I will report the results.
Just out of curiosity, how did you know that IA32_EMULATION is not
enabled? Which message told you this ?



On Fri, Nov 14, 2008 at 5:48 PM, Christoph Mende <angelos@gentoo.org> wrote:
> On Fri, 14 Nov 2008 14:02:19 -0400
> "Mansour Al Akeel" <mansour.alakeel@gmail.com> wrote:
>
>> Any idea ?
> Enable IA32_EMULATION in your kernel
>
> --
> Christoph Mende
> Gentoo/AMD64 Operational Lead and Release Engineering
> GPG: EE2A 454A 6A3B A2D8 E43B  FF45 2A19 C3B3 6DA0 C1AF
>

Re: [gentoo-amd64] Can not compile gcc

[Beso]

2008/11/14 Branko Badrljica <brankob@avtomatika.com>:
> Mansour Al Akeel wrote:
>>
>> Just out of curiosity, how did you know that IA32_EMULATION is not
>> enabled? Which message told you this ?
>>
>>
>
> He probably just suspected. Kernel's inability to run 32-bit code could be
> one of the reasons why the test code run failed.
> Other reason might be some linking error or somesuch...


the ability to compile other stuff tells that you're having problems
with the multilib profile. i suspect that you're working on a
no-multilib profile, instead.
try a ls -l /etc | grep profile and see where the actual profile is poiting.

-- 
dott. ing. beso

Re: [gentoo-amd64] Can not compile gcc

[Mansour Al Akeel]

I am not gentoo expert and no idea about profiles. However that's what I got:

lrwxrwxrwx 1 root root    50 Nov 13 17:22 make.profile ->
../usr/portage/profiles/default/linux/amd64/2008.0
-rw-r--r-- 1 root root  2141 Jun 16 22:51 profile
-rw-r--r-- 1 root root   815 Nov 14 16:12 profile.env

I am emerging gcc again. I will see how things will go. In the mean
while I am looking into disabling multilib and remove it. I just don't
know how, and googling a bit while the emerge process is running.



On Fri, Nov 14, 2008 at 6:31 PM, Beso <givemesugarr@gmail.com> wrote:
> 2008/11/14 Branko Badrljica <brankob@avtomatika.com>:
>> Mansour Al Akeel wrote:
>>>
>>> Just out of curiosity, how did you know that IA32_EMULATION is not
>>> enabled? Which message told you this ?
>>>
>>>
>>
>> He probably just suspected. Kernel's inability to run 32-bit code could be
>> one of the reasons why the test code run failed.
>> Other reason might be some linking error or somesuch...
>
>
> the ability to compile other stuff tells that you're having problems
> with the multilib profile. i suspect that you're working on a
> no-multilib profile, instead.
> try a ls -l /etc | grep profile and see where the actual profile is poiting.
>
> --
> dott. ing. beso
>
>

Re: [gentoo-amd64] Can not compile gcc

[Branko Badrljica]

Mansour Al Akeel wrote:
> Just out of curiosity, how did you know that IA32_EMULATION is not
> enabled? Which message told you this ?
>
>   
He probably just suspected. Kernel's inability to run 32-bit code could 
be one of the reasons why the test code run failed.
Other reason might be some linking error or somesuch...

Re: [gentoo-amd64] Can not compile gcc

[Beso]

2008/11/14 Mansour Al Akeel <mansour.alakeel@gmail.com>:
> I am not gentoo expert and no idea about profiles. However that's what I got:
>
> lrwxrwxrwx 1 root root    50 Nov 13 17:22 make.profile ->
> ../usr/portage/profiles/default/linux/amd64/2008.0
> -rw-r--r-- 1 root root  2141 Jun 16 22:51 profile
> -rw-r--r-- 1 root root   815 Nov 14 16:12 profile.env
>
> I am emerging gcc again. I will see how things will go. In the mean
> while I am looking into disabling multilib and remove it. I just don't
> know how, and googling a bit while the emerge process is running.
>
>
>
> On Fri, Nov 14, 2008 at 6:31 PM, Beso <givemesugarr@gmail.com> wrote:
>> 2008/11/14 Branko Badrljica <brankob@avtomatika.com>:
>>> Mansour Al Akeel wrote:
>>>>
>>>> Just out of curiosity, how did you know that IA32_EMULATION is not
>>>> enabled? Which message told you this ?
>>>>
>>>>
>>>
>>> He probably just suspected. Kernel's inability to run 32-bit code could be
>>> one of the reasons why the test code run failed.
>>> Other reason might be some linking error or somesuch...
>>
>>
>> the ability to compile other stuff tells that you're having problems
>> with the multilib profile. i suspect that you're working on a
>> no-multilib profile, instead.
>> try a ls -l /etc | grep profile and see where the actual profile is poiting.
>>
>> --
>> dott. ing. beso
>>

well, the profile points to the multilib profile.  i'm on it and don't
have any real problems.
could you describe in detail what you're using:
should be useful the following:

emerge --info
contents of /etc/make.conf
contents of /etc/fstab
contents of /usr/src/linux/.config
what stage are you using and from where. funtoo stage3 tars are based
on portage tree and are built automatically every week so this won't
have you rebuild a lot of stuff (amd64 ones)
are you doing a fresh install or an upgrade?
on an upgrade are you changin a lot of stuff?!

if i were you and were doing a fresh install i'd just save the confs,
check that they're safe, and download a new portage and stage3 from
funtoo, untar them and then emerge world again to rebuild with the
personal confs. this way you'll have a 90% of chance that everything
is going well. after cleaning everything. also i'd set up an lvm -
luks home partition so that personal data is encrypted. there are
how-to's about this on gentoo-wiki and in the forums.

-- 
dott. ing. beso

[gentoo-amd64] Re: Can not compile gcc

[Duncan]

"Mansour Al Akeel" <mansour.alakeel@gmail.com> posted
2a21586d0811141154o1b037f3fxa913ac312fe88f35@mail.gmail.com, excerpted
below, on  Fri, 14 Nov 2008 15:54:28 -0400:

> FEATURES=-sandbox emerge sandbox"

I'm sorry, I didn't make myself clear on this.  If you change the feature 
in make.conf, you'd use your normal features only change "sandbox" to 
"-sandbox".

What I was suggesting there was to go on the command line (not 
make.conf).  You set FEATURES to -sandbox for just a single command, 
which is emerge sandbox.

So combining that with the ccache suggestion, now for both gcc and 
sandbox, it would be this (after setting the FEATURES line in make.conf 
back to normal):

First command:

FEATURES="-ccache -sandbox" emerge sandbox

Second command:

FEATURES="-ccache -sandbox" emerge gcc

If you are lucky, after those two commands, you should be back to normal 
and can remerge gcc without anything funny in either make.conf or on the 
command line.

-- 
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

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

[Mansour Al Akeel]

After I enabled IA32_EMULATION everything went fine. gcc emerge was
succefull and installed glibc, now I am installing gnome. Since I am
new to gentoo, I decided to have a look at the profile concept. In the
future, if I find that I don't need the 32-bit java plugin for applets
or flash or drivers for my wireless, nvidia ... etc, I will reconsider
switching my profile to no-multilib. I am expecting a lot of issues to
resolve when I do so, but that's ok.

Thanks a lot for every one.

[gentoo-amd64] Re: Can not compile gcc

[Duncan]

"Mansour Al Akeel" <mansour.alakeel@gmail.com> posted
2a21586d0811141858h285d1e98ka29524bc2d74ed47@mail.gmail.com, excerpted
below, on  Fri, 14 Nov 2008 22:58:41 -0400:

> After I enabled IA32_EMULATION everything went fine. gcc emerge was
> succefull and installed glibc, now I am installing gnome. 

Cool! =:^)

> Since I am new
> to gentoo, I decided to have a look at the profile concept. In the
> future, if I find that I don't need the 32-bit java plugin for applets
> or flash or drivers for my wireless, nvidia ... etc, I will reconsider
> switching my profile to no-multilib. I am expecting a lot of issues to
> resolve when I do so, but that's ok.

Profiles are a neat concept, indeed.  It's very useful to be able to set 
a desktop or server, or no-multilb, profile, and have it "magically" set 
many USE flags and some other stuff appropriately, without having to set 
each one individually.

If you stick around for awhile, new profiles come online with support for 
new features, and old ones may be deprecated.  There's a nice howto guide 
for changing or upgrading your profile, when the time comes, but it's 
generally quite easy, and because Gentoo normally does rolling upgrades, 
making individual package upgrades available as they come out, you've 
usually upgraded nearly all your packages before changing the profile, 
and it's MUCH MUCH easier than upgrading from one release to another of a 
binary distribution.

-- 
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