[gentoo-dev] Re: [gentoo-user] Bootstrapping w. gcc-3.1

[gentoo-dev] Re: [gentoo-user] Bootstrapping w. gcc-3.1

[Lars Pechan]

(This is the continuation of a thread started in gentoo-user).

I'm not clear on this... Did you bootstrap twice then? Once from vanilla 
Gentoo CD gcc-2.95.3 to gcc-3.1 and then once more to rebuild glibc with 
gcc-3.1?

If you did I'm a bit surprised as I did try that as well with those very flags 
(-march=i686 -O3 -pipe) and it still crapped out in the same place??

If you didn't then you have a glibc that was built by gcc-2.95.3. I'm not 
fully up to speed on potential abi incompatibilities but isn't that asking 
for trouble?

While we're on the issue, I have another questions in relation to this:

I have seen comments in various places (incl. the LFS source Wilbert was 
refering to) that glibc should be built with a plain vanilla gcc without any 
optimization at all but then you see others who seem to be running quite 
happily with glibcs that have been optimized. This seems a particularly 
thorny issue as some optimizations affect the abi (-msse -mfpmath=sse on 
athlons for example) and certainly this could lead to all sorts of troubles 
the day you try to install a binary package, couldn't it? 

If that's correct then the logical conclusion would be not to do any 
optimization or at least take care to make sure that the abi is unaffected?

While we're on the subject am I correct in stating that any binary package in 
widespread use today (Opera. JBuilder) will not run under a gcc-3.1 system 
because of changes in the abi between 2.95.3 and 3.1? (Until the vendors 
release new versions compiled with gcc-3.1 that is). Or is there some sort of 
compatibility layer that handles this?

Sorry for the length...

/Lasse


On Wed, 22 May 2002 00:56, Spider wrote:
> Okay,
> I've succesfully bootstrapped gcc 3.1 on my system ( ahtlon-tbird ) but,
> i used i686 optimizations in the boostrap process (-march=i686 -O3
> -pipe)  and it works (even better with the 3.1-r1 that doesn't have the
> texinfo overhead)
>
> Now, Ive seen the same problem here if you compile the three with
> ahtlon-tbird, then any succeeding compile of glibc will break with the
> broken pipe, so this seems to be either binutils, glibc gettext or gcc
> bug... hard to tell which, isn't it? ;)
>
> since it works with i686 I'd just suggest that you stay with that for
> now.
>
> perl still breaks (use --buildpkg and --usepkg if you want it to work
> nicely for you)
>
> xfree86 is still to be fixed. ( I want a faster machine, 82 minutes
> between ebuild change and result isn't my idea of fun :p ;)
>
> the most recent ncurses will break (use the older snapshot and you're
> ok)
>
>
> well.. thats it for now.
> //Spider
>
>
> begin  quote
> On Tue, 21 May 2002 12:34:16 +1200
>
> Lars Pechan <lars.pechan@paradise.net.nz> wrote:
> > Hello,
> > has anybody successfully boostrapped based on gcc-3.1? I tried this
> > over the weekend by starting from scratch on a new partition, emerging
> > gcc-3.1 and then bootstrapping. (For details see
> > http://forums.gentoo.org/viewtopic.php?t=2902 ).
> >
> > The build would consistently fail with a broken pipe when compiling
> > glibc (sorry don't have the details on hand).
> >
> > And yes, I realise this probably wasn't going to work but one has to
> > try these things...
> >
> > I'm sure other people haven't managed to keep away from doing the same
> > so I'm curious to see if they've had the same problem.
> >
> >
> > Regards,
> >
> > /Lasse
> >
> > _______________________________________________
> > gentoo-user mailing list
> > gentoo-user@gentoo.org
> > http://lists.gentoo.org/mailman/listinfo/gentoo-user

Re: [gentoo-dev] Re: [gentoo-user] Bootstrapping w. gcc-3.1

[Spider]

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

Which 8< scissors... 

begin  quote
On Wed, 22 May 2002 14:44:53 +1200
Lars Pechan <lars.pechan@paradise.net.nz> wrote:


> I'm not clear on this... Did you bootstrap twice then? Once from
> vanilla Gentoo CD gcc-2.95.3 to gcc-3.1 and then once more to rebuild
> glibc with gcc-3.1?

Nope, I untarred the 1.2 stage1 tarball, rsynced, updated profile, and
unmasked the gcc 3.1 and texinfo from package.mask 

Then I proceeded with bootstrap, using default i686 compilator options.

> If you did I'm a bit surprised as I did try that as well with those
> very flags (-march=i686 -O3 -pipe) and it still crapped out in the
> same place??

Oh, didn't do that for me at all....  
 
> If you didn't then you have a glibc that was built by gcc-2.95.3. I'm
> not fully up to speed on potential abi incompatibilities but isn't
> that asking for trouble?

No, the bootstrap will first build 
baselayout:  gettext : binutils : gcc
then 
glibc baselayout gettext binutils gcc

and each step of gcc will build gcc 3 times. just to make sure it all
works.

> 
> I have seen comments in various places (incl. the LFS source Wilbert
> was refering to) that glibc should be built with a plain vanilla gcc
> without any optimization at all but then you see others who seem to be
> running quite happily with glibcs that have been optimized. This seems
> a particularly thorny issue as some optimizations affect the abi
> (-msse -mfpmath=sse on athlons for example) and certainly this could
> lead to all sorts of troubles the day you try to install a binary
> package, couldn't it? 

Yes, it could very well do bad things, and the glibc overrides the
CFLAGS and CXXFLAGS to make sure you have -O2 on the end.. I'm afraid
this isn't 100% fool proof since that wont stop your custom added
-fno-recurse -fremove-harddrive -fwipe-planet  or whatnot :p



> If that's correct then the logical conclusion would be not to do any 
> optimization or at least take care to make sure that the abi is
> unaffected?

that's recommended.. and actually, gcc will bail out if you try to build
it with too much optimization as well... not good.

> 
> While we're on the subject am I correct in stating that any binary
> package in widespread use today (Opera. JBuilder) will not run under a
> gcc-3.1 system because of changes in the abi between 2.95.3 and 3.1?
> (Until the vendors release new versions compiled with gcc-3.1 that
> is). Or is there some sort of compatibility layer that handles this?

Yes, this is the case, unless you download the static packages they will
have problems.  I think we could hack up some compability package that
built those libs only and installed them, then added it to ld.so just to
get things working with binary packages, but for me, I'm quite against
binary releases of things....  

 
> Sorry for the length...
No problem :)

 
> /Lasse
//Spider


--
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

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