[gentoo-user] gcc-4.1.1

[gentoo-user] gcc-4.1.1

[Mohammed Hagag]

i just want to know if any one here have built a full desktop with
gcc-4.1.1 without problems ?
i have some problems with xf86 video drivers and some other ebuilds.

i did a bootstartp from normal stage3 and i'm doing emerge -e world
now but some important packages did not compile most of the with
errors about glibc include files.

any one here know any thing about these problems ??
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Peper]

> any one here know any thing about these problems ??
after emerge -e world everything is working fine.

-- 
Best Regards,
Peper
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Julien Cabillot]

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

I use many software from gnome/kde/... and no problems

On 6/7/06, Peper <peper@aster.pl> wrote:
>
> > any one here know any thing about these problems ??
> after emerge -e world everything is working fine.
>
> --
> Best Regards,
> Peper
> --
> gentoo-user@gentoo.org mailing list
>
>


-- 
Julien Cabillot

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

Re: [gentoo-user] gcc-4.1.1

[Kristian Poul Herkild]

Mohammed Hagag wrote:
> i just want to know if any one here have built a full desktop with
> gcc-4.1.1 without problems ?
> i have some problems with xf86 video drivers and some other ebuilds.
> 
> i did a bootstartp from normal stage3 and i'm doing emerge -e world
> now but some important packages did not compile most of the with
> errors about glibc include files.
> 
> any one here know any thing about these problems ??

It works fine here. A few packages (mostly GNUstep ones) fails to
compile with GCC-4.1.1 (at least with my configuration), but we are
talking very  few packages.

Just remember to do 'emerge -e system && emerge -e world' and you'll be
fine.

-Herkild
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Neil Bothwick]

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

On Wed, 7 Jun 2006 16:53:31 +0300, Mohammed Hagag wrote:

> i just want to know if any one here have built a full desktop with
> gcc-4.1.1 without problems ?
> i have some problems with xf86 video drivers and some other ebuilds.

What problems?

> i did a bootstartp from normal stage3 and i'm doing emerge -e world
> now but some important packages did not compile most of the with
> errors about glibc include files.

What error?

> any one here know any thing about these problems ??

That is difficult because you haven't actually told us anything about the
problems you are having. If you give exact details of what you are doing
and the error messages you receive, someone should be able to give useful
advice.


-- 
Neil Bothwick

What's another word for `Thesaurus'?

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

Re: [gentoo-user] gcc-4.1.1

[Bo Ørsted Andresen]

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

Wednesday 07 June 2006 15:53 skrev Mohammed Hagag:
> i just want to know if any one here have built a full desktop with
> gcc-4.1.1 without problems ?

I had to run 'fix_libtool_files.sh 3.3.6' (my previous gcc was v. 3.3.6). I 
did not have to emerge -e world (at least not yet). I have compiled qt, all 
of kde and some other apps that has been upgraded in ~x86 Gentoo during the 
last 12 days with gcc 4.1.1. I have not yet compiled glibc and glib with gcc 
4.1.1. I have yet to see a problem that can't be solved by recompiling 
something. :)

> i have some problems with xf86 video drivers and some other ebuilds.

I you want help you have to be a lot more specific. What xf86 video drivers?

> i did a bootstartp from normal stage3 and i'm doing emerge -e world
> now but some important packages did not compile most of the with
> errors about glibc include files.

Which important packages? What are the errors?

> any one here know any thing about these problems ??

Given the very limited info you have provided, I very much doubt it..

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-user] gcc-4.1.1

[Conneries wearegeeks]

Did it without any problem.

> -----Message d'origine-----
> De : Mohammed Hagag [mailto:mohamedhagag1981@gmail.com]
> Envoyé : mercredi 7 juin 2006 15:54
> À : gentoo-user@lists.gentoo.org
> Objet : [gentoo-user] gcc-4.1.1
> 
> i just want to know if any one here have built a full desktop with
> gcc-4.1.1 without problems ?
> i have some problems with xf86 video drivers and some other ebuilds.
> 
> i did a bootstartp from normal stage3 and i'm doing emerge -e world
> now but some important packages did not compile most of the with
> errors about glibc include files.
> 
> any one here know any thing about these problems ??
> --
> gentoo-user@gentoo.org mailing list


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Roy Wright]

Mohammed Hagag wrote:
> i just want to know if any one here have built a full desktop with
> gcc-4.1.1 without problems ?
> i have some problems with xf86 video drivers and some other ebuilds.
>
> i did a bootstartp from normal stage3 and i'm doing emerge -e world
> now but some important packages did not compile most of the with
> errors about glibc include files.
>
> any one here know any thing about these problems ??
I did: emerge -s && emerge -e && revdep-rebuild

You might want to read:

http://forums.gentoo.org/viewtopic.php?t=282474&highlight=

which basically recommends:

  emerge -s
  emerge -s
  emerge -e
  emerge -e

to make sure the toolchain is built correctly.

HTH,
Roy
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Mike Huber]

I had some weird problems with the emerge -e system (libraries not
being properly identified to ./config scripts, that blocking issue
with pam.d & shadow, usual unstable tree stuff), but after toying with
it for a few hours, I have a successfully running desktop.

On 6/7/06, Roy Wright <royw@cisco.com> wrote:
> Mohammed Hagag wrote:
> > i just want to know if any one here have built a full desktop with
> > gcc-4.1.1 without problems ?
> > i have some problems with xf86 video drivers and some other ebuilds.
> >
> > i did a bootstartp from normal stage3 and i'm doing emerge -e world
> > now but some important packages did not compile most of the with
> > errors about glibc include files.
> >
> > any one here know any thing about these problems ??
> I did: emerge -s && emerge -e && revdep-rebuild
>
> You might want to read:
>
> http://forums.gentoo.org/viewtopic.php?t=282474&highlight=
>
> which basically recommends:
>
>   emerge -s
>   emerge -s
>   emerge -e
>   emerge -e
>
> to make sure the toolchain is built correctly.
>
> HTH,
> Roy
> --
> gentoo-user@gentoo.org mailing list
>
>
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Daniel da Veiga]

On 6/7/06, Mike Huber <michael.huber@gmail.com> wrote:
> I had some weird problems with the emerge -e system (libraries not
> being properly identified to ./config scripts, that blocking issue
> with pam.d & shadow, usual unstable tree stuff), but after toying with
> it for a few hours, I have a successfully running desktop.
>
> On 6/7/06, Roy Wright <royw@cisco.com> wrote:
> > Mohammed Hagag wrote:
> > > i just want to know if any one here have built a full desktop with
> > > gcc-4.1.1 without problems ?
> > > i have some problems with xf86 video drivers and some other ebuilds.
> > >
> > > i did a bootstartp from normal stage3 and i'm doing emerge -e world
> > > now but some important packages did not compile most of the with
> > > errors about glibc include files.
> > >
> > > any one here know any thing about these problems ??
> > I did: emerge -s && emerge -e && revdep-rebuild
> >
> > You might want to read:
> >
> > http://forums.gentoo.org/viewtopic.php?t=282474&highlight=
> >
> > which basically recommends:
> >
> >   emerge -s
> >   emerge -s
> >   emerge -e
> >   emerge -e
> >
> > to make sure the toolchain is built correctly.
> >

I'm watching this topic with curiosity, I have switched to ~x86
recently and after it all (and a few debugging) I have all my packages
testing now, but have not switched to the new GCC for fear of things
breaking beyound my knowledge on how to fix it. So, if people start
replying saying things are stable with the new GCC I might switch to
it completely and wait a few days before the "emerge -e system &&
emerge -e world" completes.

Right now I really need my notebook, so, I'm not even thinking about
such a complex and time consuming operation.

-- 
Daniel da Veiga
Computer Operator - RS - Brazil
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
------END GEEK CODE BLOCK------
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Evan Klitzke]

The pam-login/shadow blocking issue was a portage specific thing --
you would have gotten it no matter what version of gcc you were
running.  In this case it was because pam-login being deprecated.

On 6/7/06, Mike Huber <michael.huber@gmail.com> wrote:
> I had some weird problems with the emerge -e system (libraries not
> being properly identified to ./config scripts, that blocking issue
> with pam.d & shadow, usual unstable tree stuff), but after toying with
> it for a few hours, I have a successfully running desktop.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Roy Wright]

Daniel da Veiga wrote:
> I'm watching this topic with curiosity, I have switched to ~x86
> recently and after it all (and a few debugging) I have all my packages
> testing now, but have not switched to the new GCC for fear of things
> breaking beyound my knowledge on how to fix it. So, if people start
> replying saying things are stable with the new GCC I might switch to
> it completely and wait a few days before the "emerge -e system &&
> emerge -e world" completes.
>
I was running stable with a lot of testing unmasked.  Then upgraded
to gcc-4.1.1 with an immediate emerge -s && emerge -e, which went
mostly smooth. 

Then decided to go ~x86 for the system.  That is where the pain was,
particularly expat which caused most of kde/gnome to need to be
upgraded.  Unfortunately a lot of the tools to do the rebuild also
depended on expat.  So it was update a few packages, rebuild a tool,
update a few more packages, ...  Lesson learned is when upgrading
to expat-2, immediately take the hours needed to do the
revdep-rebuild (in all honesty, I didn't see the ewarn message
because I was upgrading 448 packages).  It really would have been
nice if the expat-2 emerge package died after giving the instructions
to revdep-rebuild...

So far (5 days) the system has been real nice, no problems.  KDE
appears (subjective) faster (with USE=kdehiddenvisibility).  So +1 on
upgrading a ~x86 to gcc-4.1.1.

For those considering stable to testing, the main changes are
pam-logon/shadow (unmerge pam-logon), coldplug/udev (unmerge
coldplug), expat (revdep-rebuild), ocaml (dependent packages must
be manually rebuilt afterwards).

HTH,
Roy
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Daniel da Veiga]

On 6/7/06, Roy Wright <royw@cisco.com> wrote:
> Daniel da Veiga wrote:
> > I'm watching this topic with curiosity, I have switched to ~x86
> > recently and after it all (and a few debugging) I have all my packages
> > testing now, but have not switched to the new GCC for fear of things
> > breaking beyound my knowledge on how to fix it. So, if people start
> > replying saying things are stable with the new GCC I might switch to
> > it completely and wait a few days before the "emerge -e system &&
> > emerge -e world" completes.
> >
> I was running stable with a lot of testing unmasked.  Then upgraded
> to gcc-4.1.1 with an immediate emerge -s && emerge -e, which went
> mostly smooth.
>
> Then decided to go ~x86 for the system.  That is where the pain was,
> particularly expat which caused most of kde/gnome to need to be
> upgraded.  Unfortunately a lot of the tools to do the rebuild also
> depended on expat.  So it was update a few packages, rebuild a tool,
> update a few more packages, ...  Lesson learned is when upgrading
> to expat-2, immediately take the hours needed to do the
> revdep-rebuild (in all honesty, I didn't see the ewarn message
> because I was upgrading 448 packages).  It really would have been
> nice if the expat-2 emerge package died after giving the instructions
> to revdep-rebuild...
>
> So far (5 days) the system has been real nice, no problems.  KDE
> appears (subjective) faster (with USE=kdehiddenvisibility).  So +1 on
> upgrading a ~x86 to gcc-4.1.1.
>
> For those considering stable to testing, the main changes are
> pam-logon/shadow (unmerge pam-logon), coldplug/udev (unmerge
> coldplug), expat (revdep-rebuild), ocaml (dependent packages must
> be manually rebuilt afterwards).
>

That is some precious info. I'll remember that when switching next week, thanks.
I will not have much problems with dependencies/blocks and stuff
because I already switched the whole tree to ~x86, masking some
blocks, so, now it is just a matter of recompiling stuff. Anyway, If I
switch, do the emerge -e system and world and eventually stop, nothing
will (in theory) be broken as long as I mantain compatibility
libraries right? I'll switch from 3.4.5 to 4.1, dunno if there were
substancial changes like when switching from 3.3 to 3.4. Anyway, gotta
read the gcc upgrade guide again.

-- 
Daniel da Veiga
Computer Operator - RS - Brazil
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
------END GEEK CODE BLOCK------
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Richard Fish]

On 6/7/06, Roy Wright <royw@cisco.com> wrote:
> You might want to read:
>
> http://forums.gentoo.org/viewtopic.php?t=282474&highlight=
>
> which basically recommends:
>
>   emerge -s
>   emerge -s
>   emerge -e
>   emerge -e


Ugh, this is completely pointless.  A single "emerge -e world" is sufficient.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Evan Klitzke]

AFAIK, the only thing that you need to compile twice is GCC.  And you
don't even really need to do that twice.  The second pass will may
pass on new optimizations that will make it more efficient, but the
code it outputs will be exactly the same.

-- Evan Klitzke

On 6/7/06, Richard Fish <bigfish@asmallpond.org> wrote:
> On 6/7/06, Roy Wright <royw@cisco.com> wrote:
> > You might want to read:
> >
> > http://forums.gentoo.org/viewtopic.php?t=282474&highlight=
> >
> > which basically recommends:
> >
> >   emerge -s
> >   emerge -s
> >   emerge -e
> >   emerge -e
>
>
> Ugh, this is completely pointless.  A single "emerge -e world" is sufficient.
>
> -Richard
> --
> gentoo-user@gentoo.org mailing list
>
>
-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] gcc-4.1.1

[Bob Young]

> On 6/7/06, Roy Wright <royw@cisco.com> wrote:
> > You might want to read:
> >
> > http://forums.gentoo.org/viewtopic.php?t=282474&highlight=
> >
> > which basically recommends:
> >
> >   emerge -s
> >   emerge -s
> >   emerge -e
> >   emerge -e
>
>
> Ugh, this is completely pointless.  A single "emerge -e world" is
> sufficient.
>

Depends on what you consider sufficient. Although what the page recommends
was misquoted, it actually suggests:

emerge -e system
emerge -e system
emerge -e world
emerge -e world

That's probably is a little bit excessive, but the reason for doing the two
emerge -e systems is so that the new tool chain is built with the new tool
chain. At the end of the first emerge -e system you may have a new compiler,
but that new compiler was built with the old compiler. What you actually
want is a gcc-4.1.1 that was built with gcc-4.1.1. You could emerge the
compiler twice before doing the emerge -e system, but the the emerges that
happen before glibc is rebuilt are linked against a glibc that was built
with the old compiler. Same with the rest of the tool chain and libraries.

That being said "emerge -e system" is probably overkill just for a new
toolchain. Updating a subset of all possible toolchain related things and
then following that by a single emerge -e world would probably be sufficient
for most people. This page: http://forums.gentoo.org/viewtopic-t-345229.html
is about doing an install, but it shows how to update a subset of the entire
tool chain. Note that the article does in the end, do a double emerge -e
system, so the the value of updating a toolchain subset is questionable for
the article's purposes.

In short:

emerge gcc-config glibc binutils libstdc++-v3 gcc
emerge gcc-config glibc binutils libstdc++-v3 gcc
emerge -e world

To be clear, in order to make sure absolutely everything is updated and the
libraries that are linked against are also updated prior to use, the two
emerge -e system commands, are the definitive solution. For those who don't
want to spend many extra hours of compile time, in order to gain a 0.5%
increase in performance, the above is offered for consideration.

Regards,
Bob Young


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Jerry McBride]

On Wednesday 07 June 2006 21:50, Bob Young wrote:
> > On 6/7/06, Roy Wright <royw@cisco.com> wrote:
> > > You might want to read:
> > >
> > > http://forums.gentoo.org/viewtopic.php?t=282474&highlight=
> > >
> > > which basically recommends:
> > >
> > >   emerge -s
> > >   emerge -s
> > >   emerge -e
> > >   emerge -e
> >
> > Ugh, this is completely pointless.  A single "emerge -e world" is
> > sufficient.
>
> Depends on what you consider sufficient. Although what the page recommends
> was misquoted, it actually suggests:
>
> emerge -e system
> emerge -e system
> emerge -e world
> emerge -e world
>
> That's probably is a little bit excessive, but the reason for doing the two
> emerge -e systems is so that the new tool chain is built with the new tool
> chain. At the end of the first emerge -e system you may have a new
> compiler, but that new compiler was built with the old compiler. What you
> actually want is a gcc-4.1.1 that was built with gcc-4.1.1. You could
> emerge the compiler twice before doing the emerge -e system, but the the
> emerges that happen before glibc is rebuilt are linked against a glibc that
> was built with the old compiler. Same with the rest of the tool chain and
> libraries.
>
> That being said "emerge -e system" is probably overkill just for a new
> toolchain. Updating a subset of all possible toolchain related things and
> then following that by a single emerge -e world would probably be
> sufficient for most people. This page:
> http://forums.gentoo.org/viewtopic-t-345229.html is about doing an install,
> but it shows how to update a subset of the entire tool chain. Note that the
> article does in the end, do a double emerge -e system, so the the value of
> updating a toolchain subset is questionable for the article's purposes.
>
> In short:
>
> emerge gcc-config glibc binutils libstdc++-v3 gcc
> emerge gcc-config glibc binutils libstdc++-v3 gcc
> emerge -e world
>
> To be clear, in order to make sure absolutely everything is updated and the
> libraries that are linked against are also updated prior to use, the two
> emerge -e system commands, are the definitive solution. For those who don't
> want to spend many extra hours of compile time, in order to gain a 0.5%
> increase in performance, the above is offered for consideration.
>
> Regards,
> Bob Young

Wow! I said the same thing a week or so ago and got the same rebuttal. 
However, it's what I do none the less. And it works.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Richard Fish]

On 6/7/06, Bob Young <BYoung@nucoretech.com> wrote:
> chain. At the end of the first emerge -e system you may have a new compiler,
> but that new compiler was built with the old compiler.

This is false.  Gcc uses itself to build itself.  It uses the system
compiler to build an initial version of itself, and then uses that
version to build itself.  And then for good measure, it uses that
version to build the final version.  It's called a 3-stage bootstrap,
and is documented in the file INSTALL/build.html in the gcc sources.
You can also look at /usr/portage/eclass/toolchain.eclass to determine
that Gentoo uses the "bootstrap-lean" target by default.

Frankly, anybody who claims that gcc needs to be merged twice so it
can be built with itself and produce better object code does not have
a clue what they are talking about and you should simply disregard
anything else they have to say about what is necessary/useful when
upgrading gcc.

> happen before glibc is rebuilt are linked against a glibc that was built
> with the old compiler.

And guess what difference this makes to the end result.  None.  Nada.  Nothing.

Because for basically every program on your system, they are
*dynamically linked* against glibc.  This means that you can recompile
glibc with different CFLAGS, a different compiler version, whatever,
and they will *never notice*.  Well, unless you use broken CFLAGS or a
broken compiler, but no amount of "emerge -e world" can help you then.

There are a few statically linked programs that will include glibc
internally.  These are used only for system recovery purposes...there
is no need to worry about them at all.

Again, *anybody* who claims that the end result of a compile depends
upon what version of glibc you have installed, much less what CFLAGS
or compiler glibc was built with, does not know what they are talking
about.

> for most people. This page: http://forums.gentoo.org/viewtopic-t-345229.html
> is about doing an install, but it shows how to update a subset of the entire
> tool chain. Note that the article does in the end, do a double emerge -e
> system, so the the value of updating a toolchain subset is questionable for
> the article's purposes.

Any article, on the forums or anywhere else, that claims some speed
benefit resulting from doing emerge -e world twice is wrong.

>
> In short:
>
> emerge gcc-config glibc binutils libstdc++-v3 gcc
> emerge gcc-config glibc binutils libstdc++-v3 gcc
> emerge -e world

There is no value to having glibc or libstdc++-v3 in the first line.
There is no value at all to doing that twice.

Also, libstdc++-v3 is only needed by a few binary-only programs on
Gentoo.  Moreover, it is simply a build of gcc-3.3.6, which as I
already said uses itself to build itself, so I cannot see any point in
ever re-merging libstdc++-v3 due to a gcc upgrade, much less doing
that 3 or 4 times!

> To be clear, in order to make sure absolutely everything is updated and the
> libraries that are linked against are also updated prior to use, the two
> emerge -e system commands, are the definitive solution. For those who don't
> want to spend many extra hours of compile time, in order to gain a 0.5%
> increase in performance, the above is offered for consideration.

No, there will not even be a 0.5% increase in performance.  Not even
0.1%.  Not even 0.000000000.....000001%.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Richard Fish]

On 6/7/06, Evan Klitzke <eklitzke@gmail.com> wrote:
> AFAIK, the only thing that you need to compile twice is GCC.  And you
> don't even really need to do that twice.  The second pass will may
> pass on new optimizations that will make it more efficient, but the
> code it outputs will be exactly the same.

You are correct that gcc's output will be the same, but you don't need
to merge it twice because gcc uses itself to build itself.  It uses a
3-stage bootstrap, where it uses the system compiler to build an
initial version of itself, then uses that version to rebuild itself.
Then for good measure, it then uses that version to build the final
version of itself.  The final result is completely independant of the
original compiler.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Mohammed Hagag]

thanks every body,
every thing goes fine now without errors i didn't change any thing
just a reboot then etc-update; env-update and every thing works fine.

On 6/8/06, Richard Fish <bigfish@asmallpond.org> wrote:
> On 6/7/06, Evan Klitzke <eklitzke@gmail.com> wrote:
> > AFAIK, the only thing that you need to compile twice is GCC.  And you
> > don't even really need to do that twice.  The second pass will may
> > pass on new optimizations that will make it more efficient, but the
> > code it outputs will be exactly the same.
>
> You are correct that gcc's output will be the same, but you don't need
> to merge it twice because gcc uses itself to build itself.  It uses a
> 3-stage bootstrap, where it uses the system compiler to build an
> initial version of itself, then uses that version to rebuild itself.
> Then for good measure, it then uses that version to build the final
> version of itself.  The final result is completely independant of the
> original compiler.
>
> -Richard
> --
> gentoo-user@gentoo.org mailing list
>
>
-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] gcc-4.1.1

[Bob Young]

> -----Original Message-----
> From: richard.j.fish@gmail.com [mailto:richard.j.fish@gmail.com]On
> Behalf Of Richard Fish
> Sent: Wednesday, June 07, 2006 9:24 PM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] gcc-4.1.1
>
>
> On 6/7/06, Bob Young <BYoung@nucoretech.com> wrote:
> > chain. At the end of the first emerge -e system you may have a
> new compiler,
> > but that new compiler was built with the old compiler.
>
> This is false.  Gcc uses itself to build itself.  It uses the system
> compiler to build an initial version of itself, and then uses that
> version to build itself.  And then for good measure, it uses that
> version to build the final version.  It's called a 3-stage bootstrap,
> and is documented in the file INSTALL/build.html in the gcc sources.
> You can also look at /usr/portage/eclass/toolchain.eclass to determine
> that Gentoo uses the "bootstrap-lean" target by default.

No, sorry that's just wrong. gcc is slotted, if the above were true there
would be no need for gcc-config in order to select a default compiler. When
a new compiler is emerged, it does *not* automatically become the default
system compiler, it must be selected, and that can only happen after it has
successfully been emerged. The first time a new gcc compiler is emerged, it
is indeed built with the previous version of the compiler that is currently
istalled as the system default.


> Frankly, anybody who claims that gcc needs to be merged twice so it
> can be built with itself and produce better object code does not have
> a clue what they are talking about and you should simply disregard
> anything else they have to say about what is necessary/useful when
> upgrading gcc.

It does have to be emerged twice in order for it to be built with itself,
anybody who thinks otherwise doesn't understand the basic principles of
compiling and linking.

> > happen before glibc is rebuilt are linked against a glibc that was built
> > with the old compiler.
>
> And guess what difference this makes to the end result.  None.
> Nada.  Nothing.
>
> Because for basically every program on your system, they are
> *dynamically linked* against glibc.

Are you absolutely 100% sure that every single system utility and
application is *dynamically* linked, and that no apps or utilities anywhere
in the system specifies *static* linking?

> There are a few statically linked programs that will include glibc
> internally.  These are used only for system recovery purposes...there
> is no need to worry about them at all.

Really, so people who intentionally and specifically want to upgrade
absolutely *everything* should not worry about what gets left out because
Richard says it's unimportant?

The issue is about upgrading gcc and even the gcc upgrade howto recommends
an emerge -e world. It's clear that gcc it self at least has to be emerged
twice in order to build the new gcc *with* the new gcc. Whether this is
strictly necessary or not is certaintly debatable, but since it executes
fairly quickly, and seems a prudent step, I'd argue that it's a reasonable
course. Of course a selecting the new gcc as the default with gcc-config is
also required in between, but that's self evident. Adding gcc-config, glibc,
binutils, libstdc++-v3, quickly covers the most important parts of the basic
tool chain, and covers most utilities or apps that might specify static
linking, and executes much much faster than an emerge -e system.

> There is no value to having glibc or libstdc++-v3 in the first line.
> There is no value at all to doing that twice.

Twice is the only way to build the new gcc *with* the new gcc. I should have
added the gcc-config select command in between, but I thought that was
pretty clearly necessary.

> Also, libstdc++-v3 is only needed by a few binary-only programs on
> Gentoo.  Moreover, it is simply a build of gcc-3.3.6, which as I
> already said uses itself to build itself,  so I cannot see any point in
> ever re-merging libstdc++-v3 due to a gcc upgrade

I know you said it, but that doesn't mean you were correct. The fact is that
anything emerged is built with the currently selected system compiler, the
first time a new compiler is emerged it is built with the current (old)
compiler (duh). *After* it is successfuly emerged, it can be selected as the
default system compiler, then re-emergeing gcc will result in the new
compiler being built with the new compiler.

The same holds true for libstdc++-v3 orginally it was built with the default
system compiler, it makes sense to have it rebuilt with the new compiler.

Regards,
Bob Young


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Hans-Werner Hilse]

Hi,

On Thu, 8 Jun 2006 05:34:49 -0700 "Bob Young" <BYoung@nucoretech.com>
wrote:

> No, sorry that's just wrong. gcc is slotted, if the above were true
> there would be no need for gcc-config in order to select a default
> compiler.

Did you follow the documentation pointer given in the mail you are
replying to before making such statements? In fact, you're wrong here.

> When a new compiler is emerged, it does *not* automatically
> become the default system compiler, it must be selected, and that can
> only happen after it has successfully been emerged. The first time a
> new gcc compiler is emerged, it is indeed built with the previous
> version of the compiler that is currently istalled as the system
> default.

You haven't understood a word from the posting you're replying to.

> It does have to be emerged twice in order for it to be built with
> itself, anybody who thinks otherwise doesn't understand the basic
> principles of compiling and linking.

Try to understand what you are replying to. GCC's internal build logic
does the staging. That's got nothing to do with what your system calls
when you issue "gcc", and only at that point the slotting of GCC
versions comes into play.

> > Because for basically every program on your system, they are
> > *dynamically linked* against glibc.
> 
> Are you absolutely 100% sure that every single system utility and
> application is *dynamically* linked, and that no apps or utilities
> anywhere in the system specifies *static* linking?

What would that change? We're talking about GCC, not glibc.

> > There are a few statically linked programs that will include glibc
> > internally.  These are used only for system recovery
> > purposes...there is no need to worry about them at all.
> 
> Really, so people who intentionally and specifically want to upgrade
> absolutely *everything* should not worry about what gets left out
> because Richard says it's unimportant?

If the build logic of those programs uses glibc statically, the
specific ebuilds for such programs have to get updated in order to
incorporate fixes that are needed in statically compiled libraries.

Following *your* logic, one would have to do emerge -e world after the
slightest update just for the case that the updated package is compiled
statically into something.

> The issue is about upgrading gcc and even the gcc upgrade howto
> recommends an emerge -e world. It's clear that gcc it self at least
> has to be emerged twice in order to build the new gcc *with* the new
> gcc.

Repeating this doesn't make it more true than being plain wrong.

> > There is no value to having glibc or libstdc++-v3 in the first line.
> > There is no value at all to doing that twice.
> 
> Twice is the only way to build the new gcc *with* the new gcc. I
> should have added the gcc-config select command in between, but I
> thought that was pretty clearly necessary.

He was talking about glibc at that point. I don't see no value either.

> > Also, libstdc++-v3 is only needed by a few binary-only programs on
> > Gentoo.  Moreover, it is simply a build of gcc-3.3.6, which as I
> > already said uses itself to build itself,  so I cannot see any
> > point in ever re-merging libstdc++-v3 due to a gcc upgrade
> 
> The same holds true for libstdc++-v3 orginally it was built with the
> default system compiler, it makes sense to have it rebuilt with the
> new compiler.

Not sure here, but it may well be possible that the ebuild in question
builds a gcc 3.3 for bootstrapping this, too.

-hwh
-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] gcc-4.1.1

[Bob Young]

> -----Original Message-----
> From: Hans-Werner Hilse [mailto:hilse@web.de]
> Sent: Thursday, June 08, 2006 6:32 AM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] gcc-4.1.1
>
> You haven't understood a word from the posting you're replying to.
>
> > It does have to be emerged twice in order for it to be built with
> > itself, anybody who thinks otherwise doesn't understand the basic
> > principles of compiling and linking.
>
> Try to understand what you are replying to. GCC's internal build logic
> does the staging. That's got nothing to do with what your system calls
> when you issue "gcc", and only at that point the slotting of GCC
> versions comes into play.


Show me some documentation for this "staging" you refer to. When you "emerge
gcc" it is built with the current compiler, if the current compiler is gcc
3.4.6, and you emerge gcc 4.1.1, that means that while gcc 4.1.1 is being
emerged it is built with gcc 3.4.6. gcc 4.1.1 can't be built with 4.1.1
because it hasn't been emerged yet, and as far as the system knows it
doesn't actually exist yet. Can you clearly and concisely explain to me how
something that is in the process of being emerged can be used to emerge
itself? Doesn't make sense.

Regards,
Bob Young



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Bo Ørsted Andresen]

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

Thursday 08 June 2006 16:00 skrev Bob Young:
> Show me some documentation for this "staging" you refer to.

If you unpack the gcc sources you will find it in gcc-*/INSTALL/build.html as 
already mentioned by Richard. But you can also see it at [1].

[1] http://gcc.gnu.org/install/build.html

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-user] gcc-4.1.1

[Bob Young]

> -----Original Message-----
> From: Bo Ørsted Andresen [mailto:bo.andresen@zlin.dk]
> Sent: Thursday, June 08, 2006 7:29 AM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] gcc-4.1.1
>
>
> Thursday 08 June 2006 16:00 skrev Bob Young:
> > Show me some documentation for this "staging" you refer to.
>
> If you unpack the gcc sources you will find it in
> gcc-*/INSTALL/build.html as
> already mentioned by Richard. But you can also see it at [1].
>
> [1] http://gcc.gnu.org/install/build.html
>

Okay, I stand corrected.

Regards,
Bob Young


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Toby Cubitt]

On Thu, Jun 08, 2006 at 07:00:22AM -0700, Bob Young wrote:
> 
> 
> > From: Hans-Werner Hilse [mailto:hilse@web.de]
> > Sent: Thursday, June 08, 2006 6:32 AM
> > To: gentoo-user@lists.gentoo.org
> > Subject: Re: [gentoo-user] gcc-4.1.1
> >
> > Try to understand what you are replying to. GCC's internal build logic
> > does the staging. That's got nothing to do with what your system calls
> > when you issue "gcc", and only at that point the slotting of GCC
> > versions comes into play.
> 
> 
> Show me some documentation for this "staging" you refer to.

He did! In the INSTALL/build.html file in the gcc sources.

> When you "emerge gcc" it is built with the current compiler, if the
> current compiler is gcc 3.4.6, and you emerge gcc 4.1.1, that means
> that while gcc 4.1.1 is being emerged it is built with gcc
> 3.4.6. gcc 4.1.1 can't be built with 4.1.1 because it hasn't been
> emerged yet, and as far as the system knows it doesn't actually
> exist yet.

Yes. The *first* time that gcc 4.1.1 is built. But then the gcc build
process builds it a *second* time, using the gcc 4.1.1 it's just
built. And for good measure, it goes on to build it a *third* time
with the second version it produced. This is all done by the gcc build
process (it's in the Makefile), which is what emerge runs.

> Can you clearly and concisely explain to me how something that is in
> the process of being emerged can be used to emerge itself? Doesn't
> make sense.

You're obviously right that you have to *compile* a new gcc at least
twice. But this is done automatically by the gcc build process, so
there's no need to build (or emerge) gcc twice.

This has nothing to do with gentoo. Downloading the gcc sources
manually and running ./configure, make, make install (or whatever the
exact gcc build process is) would work too: you'd only need to do it
once.

Toby
-- 
PhD Student
Quantum Information Theory group
Max Planck Institute for Quantum Optics
Garching, Germany

email: toby@dr-qubit.org
web: www.dr-qubit.org
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Richard Fish]

Others have already coverd the major points, so just a couple of
things to add...

On 6/8/06, Bob Young <BYoung@nucoretech.com> wrote:
> Are you absolutely 100% sure that every single system utility and
> application is *dynamically* linked, and that no apps or utilities anywhere
> in the system specifies *static* linking?

I didn't say "every single system utility and application".  I said
"basically every program", which was a bad way of saying "almost all",
since it might not be obvious for non-native english speakers (and
even some native english speakers).

> > There are a few statically linked programs that will include glibc
> > internally.  These are used only for system recovery purposes...there
> > is no need to worry about them at all.
>
> Really, so people who intentionally and specifically want to upgrade
> absolutely *everything* should not worry about what gets left out because
> Richard says it's unimportant?

No.  They should follow the gcc upgrade guide that says emerge -e
system followed by emerge -e world.

BTW, I was incorrect when I stated "only for system recover purposes".
 The static programs do include things like busybox (which doesn't use
glibc at all AFAIK), nash, and insmod.static, which are /mostly/
useful for system recovery.  But it also includes things that have to
run before the root filesystem is mounted, like splash and suspend
utilities.

I still think anybody worried about the performance of (e.g.) lvm is a
bit crazy, but if they want to remerge it after remerging glibc to get
the new "optimized" code, well, so be it...

> The same holds true for libstdc++-v3 orginally it was built with the default
> system compiler, it makes sense to have it rebuilt with the new compiler.

There is simply no way to build libstdc++-v3 with the new compiler; it
would break any programs that need it.  Gcc likes to make incompatible
changes in the C++ ABI from one version to the next, so building -v3
with the new gcc would give you the old stdc++ library, but the new
ABI, and your programs would be broken.

This is one of the major reasons that gcc uses itself to build itself,
to make sure that it's ABI is consistent.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Vladimir G. Ivanovic]

On Thu, 2006-06-08 at 11:05 -0700, Richard Fish wrote:
> There is simply no way to build libstdc++-v3 with the new compiler; it
> would break any programs that need it.  Gcc likes to make incompatible
> changes in the C++ ABI from one version to the next, so building -v3
> with the new gcc would give you the old stdc++ library, but the new
> ABI, and your programs would be broken.
> 
> This is one of the major reasons that gcc uses itself to build itself,
> to make sure that it's ABI is consistent.
> 
        scarlatti ~ $ genlop libstdc++-v3
         * sys-libs/libstdc++-v3
        
             Wed Dec 21 10:45:38 2005 >>> sys-libs/libstdc++-v3-3.3.4
             Sun Mar  5 07:58:19 2006 >>> sys-libs/libstdc++-v3-3.3.6
             Sat Mar 18 13:23:43 2006 >>> sys-libs/libstdc++-v3-3.3.6
             Sun Apr  2 04:07:24 2006 >>> sys-libs/libstdc++-v3-3.3.6
        scarlatti ~ $ equery depends libstdc++-v3
        [ Searching for packages depending on libstdc++-v3... ]
        sys-devel/gcc-3.4.6-r1

I definitely built libstdc++-v3 with gcc-4.1.1, but interestingly genlop
doesn't report any USE or CFLAGS for it. Hmmm.

        scarlatti ~ $ genlop -i libstdc++-v3
         * sys-libs/libstdc++-v3
        
        
           Total builds: 4
           Global build time: 59 minutes and 57 seconds.
           Average merge time: 14 minutes and 59 seconds.
        
           Info about currently installed ebuild:
        
           * sys-libs/libstdc++-v3-3.3.6
           Install date: Sun Apr  2 04:07:24 2006

Anyway, I haven't had any problems, but maybe that's because no package
I have uses libstdc++-v3.

--- Vladimir

Vladimir G. Ivanovic
Palo Alto, CA 94306
+1 650 678 8014
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Richard Fish]

On 6/9/06, Vladimir G. Ivanovic <vgivanovic@comcast.net> wrote:
> I definitely built libstdc++-v3 with gcc-4.1.1, but interestingly genlop
> doesn't report any USE or CFLAGS for it. Hmmm.

Look at the ebuild for libstdc++-v3.  It actually builds gcc-3.3 with
C++ support, and then pulls the libstdc++.so library out of that.  As
we've already discussed, gcc uses itself to build itself, so you
actually built libstdc++-v3 with gcc-3.3.

-Richard
-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] gcc-4.1.1

[Bob Young]

> -----Original Message-----
> From: Jerry McBride [mailto:mcbrides9@comcast.net]
> Sent: Wednesday, June 07, 2006 7:10 PM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] gcc-4.1.1
>
>
> On Wednesday 07 June 2006 21:50, Bob Young wrote:
> Note that the
> > article does in the end, do a double emerge -e system, so the
> the value of
> > updating a toolchain subset is questionable for the article's purposes.
> >
> > In short:
> >
> > emerge gcc-config glibc binutils libstdc++-v3 gcc
> > emerge gcc-config glibc binutils libstdc++-v3 gcc
> > emerge -e world
> >
> > To be clear, in order to make sure absolutely everything is
> updated and the
> > libraries that are linked against are also updated prior to use, the two
> > emerge -e system commands, are the definitive solution. For
> those who don't
> > want to spend many extra hours of compile time, in order to gain a 0.5%
> > increase in performance, the above is offered for consideration.
> >
> > Regards,
> > Bob Young
>
> Wow! I said the same thing a week or so ago and got the same rebuttal.
> However, it's what I do none the less. And it works.
>

I've been thinking about this over the last week or so. In particular the
fact that gcc always uses itself to build itself, does elminate the need for
building gcc twice. That being the case, emerging the new gcc then selecting
it as the default system compiler followed by a single emerge -e world
should be all that is necessary. I suppose it's possible that a few apps or
utilities that use static linking *could* possibly end up linking against
libraries that have not been rebuilt with the new compiler yet due to build
order issues. However since the number of apps and utilities that actually
use static linking is very small, it doesn't seem that a double emerge -e
world or system is justified.

That being said, seems these two articles appear to be giving out bad
information:

http://forums.gentoo.org/viewtopic.php?t=282474&highlight=

http://forums.gentoo.org/viewtopic-t-345229.html


If I've mis-characterisized the issue in the above description I'd
appreciate it if someone would correct any mis-statements. Lastly, since the
Gentoo handbook no longer describes a stage one install, is there any
"official" documentation that describes the *correct* way to do a stage3
install and end up with the same level of optimization and customization
that used to be provided by a stage1 install?

--
Regards,
Bob Young


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Richard Fish]

On 6/12/06, Bob Young <BYoung@nucoretech.com> wrote:
> That being said, seems these two articles appear to be giving out bad
> information:
>
> http://forums.gentoo.org/viewtopic.php?t=282474&highlight=
>
> http://forums.gentoo.org/viewtopic-t-345229.html

Yes, I would have to agree.  The first is just so utterly wrong I
can't actually read it all the way through.

I also have problems with the second, aside from the gcc issues.  It
puts a lot of effort into fine-tuning hdparm settings, but misses the
noatime option in fstab that actually makes a much bigger difference.
And it recommends -nptlonly, without any reasoning why.  Of course it
is also marked as "deprecated", with a link to the new version, but
that requires some kind of login to access.

But basically the forums, the wiki, and even this mail list are all
"buyer beware!"  They are all unofficial, and there is no quality
control other that what is provided by other users.

Heck, don't even trust me without doing some of your own research.  I
will sometimes mention whatever official sources support my position,
but usually only if I am trying to make a particularly strong
argument.  If I make an unsupported assertion, you *should* question
it!  *I may not* actually know what I am talking about!

> appreciate it if someone would correct any mis-statements. Lastly, since the
> Gentoo handbook no longer describes a stage one install, is there any
> "official" documentation that describes the *correct* way to do a stage3
> install and end up with the same level of optimization and customization
> that used to be provided by a stage1 install?

The FAQ entry:
http://www.gentoo.org/doc/en/faq.xml?style=printable#stage12

Note that although the faq is about installing from stage1 (or
stage2), it really doesn't say how to install from stage1.  It tells
how to get to the same point from a stage3 install.

There was a discussion about this on gentoo-dev late last year.  While
not 'official documentation', it is at least from people who should
know what they are talking about:

http://article.gmane.org/gmane.linux.gentoo.devel/33251/match=decision+remove+stage1+2

So the answer seems to be:

1. Install a stage3 as documented
2. [Edit and] run bootstrap.sh
3. emerge -e system

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Thomas T. Veldhouse]

Bob Young wrote:
> Depends on what you consider sufficient. Although what the page recommends
> was misquoted, it actually suggests:
>
> emerge -e system
> emerge -e system
> emerge -e world
> emerge -e world
>
> That's probably is a little bit excessive, but the reason for doing the two
> emerge -e systems is so that the new tool chain is built with the new tool
> chain. At the end of the first emerge -e system you may have a new compiler,
> but that new compiler was built with the old compiler. What you actually
> want is a gcc-4.1.1 that was built with gcc-4.1.1. You could emerge the
> compiler twice before doing the emerge -e system, but the the emerges that
> happen before glibc is rebuilt are linked against a glibc that was built
> with the old compiler. Same with the rest of the tool chain and libraries.
>
>   
Hmm ... unless the build of gcc has changed over the years, it used to 
build the compiler as a bootstrap and then use new compiler (xgcc) to 
build the final compiler for install (gcc).  Thus, the standard make 
script already builds the compiler twice.  I don't know that a compiler 
rebuild is really necessary when binutils is updated.




-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc-4.1.1

[Thomas T. Veldhouse]

Bob Young wrote:
>   
>> -----Original Message-----
>> From: richard.j.fish@gmail.com [mailto:richard.j.fish@gmail.com]On
>> Behalf Of Richard Fish
>> Sent: Wednesday, June 07, 2006 9:24 PM
>> To: gentoo-user@lists.gentoo.org
>> Subject: Re: [gentoo-user] gcc-4.1.1
>>
>>
>> On 6/7/06, Bob Young <BYoung@nucoretech.com> wrote:
>>     
>>> chain. At the end of the first emerge -e system you may have a
>>>       
>> new compiler,
>>     
>>> but that new compiler was built with the old compiler.
>>>       
>> This is false.  Gcc uses itself to build itself.  It uses the system
>> compiler to build an initial version of itself, and then uses that
>> version to build itself.  And then for good measure, it uses that
>> version to build the final version.  It's called a 3-stage bootstrap,
>> and is documented in the file INSTALL/build.html in the gcc sources.
>> You can also look at /usr/portage/eclass/toolchain.eclass to determine
>> that Gentoo uses the "bootstrap-lean" target by default.
>>     
>
> No, sorry that's just wrong. gcc is slotted, if the above were true there
> would be no need for gcc-config in order to select a default compiler. When
> a new compiler is emerged, it does *not* automatically become the default
> system compiler, it must be selected, and that can only happen after it has
> successfully been emerged. The first time a new gcc compiler is emerged, it
> is indeed built with the previous version of the compiler that is currently
> istalled as the system default.
>   
xgcc is built with the previous system compiler.  Then xgcc is used to 
build the new gcc for installation.  The final install is a self-built 
gcc and is not built by the previous system compiler.
>
>   
>> Frankly, anybody who claims that gcc needs to be merged twice so it
>> can be built with itself and produce better object code does not have
>> a clue what they are talking about and you should simply disregard
>> anything else they have to say about what is necessary/useful when
>> upgrading gcc.
>>     
>
> It does have to be emerged twice in order for it to be built with itself,
> anybody who thinks otherwise doesn't understand the basic principles of
> compiling and linking.
>   
I think you have ignored what the previous poster suggested.
>   
>>> happen before glibc is rebuilt are linked against a glibc that was built
>>> with the old compiler.
>>>       
>> And guess what difference this makes to the end result.  None.
>> Nada.  Nothing.
>>
>> Because for basically every program on your system, they are
>> *dynamically linked* against glibc.
>>     
>
> Are you absolutely 100% sure that every single system utility and
> application is *dynamically* linked, and that no apps or utilities anywhere
> in the system specifies *static* linking?
>
>   
>> There are a few statically linked programs that will include glibc
>> internally.  These are used only for system recovery purposes...there
>> is no need to worry about them at all.
>>     
>
> Really, so people who intentionally and specifically want to upgrade
> absolutely *everything* should not worry about what gets left out because
> Richard says it's unimportant?
>
> The issue is about upgrading gcc and even the gcc upgrade howto recommends
> an emerge -e world. It's clear that gcc it self at least has to be emerged
> twice in order to build the new gcc *with* the new gcc. 
Wrong.  The gcc package builds a bootstrap compiler (the new version), 
called xgcc and then it uses that to build [after some tests] the final 
installed gcc.  A single emerge of gcc will create a compiler that was 
built by itself.

Thus, if you move from 3.3.4 to 4.1.0:

emerge -u gcc

You WILL have a gcc that was compiled by a 4.1.0 compiler.

> Whether this is
> strictly necessary or not is certaintly debatable, but since it executes
> fairly quickly, and seems a prudent step, I'd argue that it's a reasonable
> course. Of course a selecting the new gcc as the default with gcc-config is
> also required in between, but that's self evident. Adding gcc-config, glibc,
> binutils, libstdc++-v3, quickly covers the most important parts of the basic
> tool chain, and covers most utilities or apps that might specify static
> linking, and executes much much faster than an emerge -e system.
>
>   
>> There is no value to having glibc or libstdc++-v3 in the first line.
>> There is no value at all to doing that twice.
>>     
>
> Twice is the only way to build the new gcc *with* the new gcc. I should have
> added the gcc-config select command in between, but I thought that was
> pretty clearly necessary.
>
>   
You didn't pay attention to what he wrote.  I hope perhaps my post made 
it more clear.

Tom Veldhouse


-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] gcc-4.1.1

[Bob Young]

> -----Original Message-----
> From: Thomas T. Veldhouse [mailto:veldy@veldy.net]
> Sent: Friday, June 16, 2006 10:25 AM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] gcc-4.1.1

> You didn't pay attention to what he wrote.  I hope perhaps my post made
> it more clear.
>
> Tom Veldhouse

The only thing your post made clear is that you don't bother to read all of
a thread before replying to it. Maybe this will help:


The following reply was sent by me on Thur 6/8/2006 7:57 AM
*************************************************************


> -----Original Message-----
> From: Bo Ørsted Andresen [mailto:bo.andresen@zlin.dk]
> Sent: Thursday, June 08, 2006 7:29 AM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] gcc-4.1.1
>
>
> Thursday 08 June 2006 16:00 skrev Bob Young:
> > Show me some documentation for this "staging" you refer to.
>
> If you unpack the gcc sources you will find it in
> gcc-*/INSTALL/build.html as
> already mentioned by Richard. But you can also see it at [1].
>
> [1] http://gcc.gnu.org/install/build.html
>

Okay, I stand corrected.

Regards,
Bob Young

*************************************************************



-- 
gentoo-user@gentoo.org mailing list