Re: [gentoo-dev] Gcc 3.0.4 installed system

[Geert Bevin]

The second bootstrap will certainly work, you could also just have done
'emerge gcc' which would first install gcc3 and then start the bootstrap
itself. Saving quite some time normally.

On Sun, 2002-04-07 at 14:38, Christian Hergl wrote:
> Hello all, Hello Preston,
>
> just adding my 2 cents. I'm in the process to emerge a system based on
> the gcc 3.0.4 as discussed earlier in this threat.
> Having the glibc and gcc3 compiled with the gcc 2.95 of the stage1 iso
> image made me worried after your post.
> And indeed, the mini compiler of the iso refused to accept the
> march=athlon flag for the bootstrap.
> So, I did the bootstrap with march=i686, and right now am
> re-bootstrapping again with the gcc3.0 and march=athlon, which hopefully
> now compiles a decent optimized gcc and glibc. And should savely give a
> full gcc3 system later.
>
> Could you confirm that the second bootstrap would be a working interim
> solution till a gentoo 1.1 (which, to my suprise seems to be
> downloadable from the gentoo ftp site. Anyone from IRC know what it
> does?) is released?
>
> Greetings,
> Christian
>
> Preston A. Elder wrote:
> > I'm sure it does ...
> >
> > But unless I'm missing something here, changing the profile does NOTHING
> > to change the utilities (read: tar, bzip2, cp, mv, ls, etc) that are
> > installed WITH the system.
> >
> > Read my email again carefully.  I manually made my own
> > 'default-1.0-gcc3' profile by changing the packages file to use gcc3
> > instead of 2.95 and then bootstrapped with it -- and it worked fine
> > right up until it installed glibc.
> >
> > Just incase your not a coder.  GLIBC supplies both C and C++ libraries
> > and symbols for other programs to use.  All C++ symbols are 'mangled',
> > which is a method the compiler uses to differentiate different functions
> > with the same name but different types (read up on C++ function
> > overloading and name mangling).
> >
> > 3.0 changed the mangling scheme used to mangle C++ names from what was
> > used with 2.x -- which means, quite simply, if you have an application
> > thats been compiled against libraries built with gcc 2.x, and then you
> > compile the libraries with 3.x, the application will cease to work,
> > because it will not be able to find the symbols it needs to run.
> > Usually, this will result in a core dump.  This only affects programs
> > written in C++.
> >
> > This is exactly what happens with utilities such as tar, which is
> > written in C++ (which surprised me).  Which is why, your
> > default-1.0-gcc3 profile will *NOT* enable someone to bootstrap with gcc
> > 3.0, unless you happen to have a stage1 ISO that has statically linked
> > binaries in it (theoretically, if you have statically linked binaries on
> > the whole system, you dont even NEED a /lib or /usr/lib directory,
> > because its all statically linked).
> >
> > This was the point I was trying to make.  Dont get me wrong, I'm glad
> > the gcc3 profile is there, and I'm using it, because I use gcc3
> > exclusively -- however gcc3 (for now), is only available as a
> > POST-bootstrap (ie. stage2) compilation, until we get a 1.0 ISO with
> > statically linked binaries -- or binaries that are still dynamically
> > linked, but all compiled with gcc3.0 against a glibc compiled with
> > gcc3.0.  Which brings in the chicken and the egg problem.
> >
> > This is also why you will have to lock people into a specific glibc
> > version in your gcc3 profile (which I've noticed you dont do right
> > now).  Say someone bootstraps as normal, then installs gcc3, then
> > switches to your gcc3 profile, and continues to build the system.  If,
> > at some later point, a new revision or version of glibc comes out, and
> > is put into the portage tree, and the user then does a world upgrade,
> > they will attempt to re-compile glibc.  It will compile, but as soon as
> > it installs, a good proportion of the rest of their system will stop
> > working for exactly the reason I described.  I've manually locked my
> > glibc version because of this fact, because I know I cant re-compile it
> > with gcc3 without breaking my system.
> >
> > If I get time, I'll sit down and think about how to actually create a
> > stage1 (the thing you tar -xvbjf onto your hard disk) system that is
> > totally gcc3 based, or see if I can create a stage1 with all statically
> > linked binaries in it.  For now, thats not high on my priority list.
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@g.o
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>
-- 
Geert Bevin             Uwyn
"Use what you need"     Lambermontlaan 148
http://www.uwyn.com     1030 Brussels
gbevin@××××.com         Tel & Fax [phone]