Re: [gentoo-dev] Gcc 3.0.4 installed system

[Geert Bevin]

Bootstrap gives you baselayout, binutils, gcc, glibc and gettext
compiled with gcc3. Everything (including these utilities you talk
about) else is compiled again when you do 'emerge system'. The only
thing I did afterwards is 'ebuild
/var/db/pkg/sys-devel/gcc-2.95.3-r5/gcc-2.95.3-r5.ebuild unmerge' to
ensure that it's not present at all on the system anymore.
The system I have running has no libraries of gcc 2.95.3 installed and
everything is running fine and has been compiled with gcc3. Remember
that is what stage1 -> stage2 -> stage3 really is for.
Sure a stage1 that has been prepared with gcc3 would be cleaner and it's
not that difficult to do. However as long as gcc3 isn't the default
gentoo compiler, I don't see much use for it.

On Sun, 2002-04-07 at 12:40, 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.
>
> On Sun, 2002-04-07 at 06:14, Geert Bevin wrote:
> > Changing the profile in /etc/make.profile to default-1.0-gcc3 should
> > make you bootstrap against gcc3 instead.
> >
> > On Sun, 2002-04-07 at 05:29, Preston A. Elder wrote:
> > > Personally, I'd be very interested to know how you did this 'from
> > > scratch'.
> > >
> > > I myself have done this from the post-bootstrap (but pre emerge system)
> > > stage on, but I cant bootstrap with 3.0.x, why?
> > >
> > > Well, the image the ISO installs has many applications on it, not linked
> > > statically (eg. tar, etc) -- compiling gcc3.0.4 works fine, but as soon
> > > as it then compiles glibc 2.2.5 and installs it, nothing else works.
> > >
> > > The utilities on the install image look for glibc 2.2.5 compiled with
> > > gcc 2.95.x.  So until there is an install image that has statically
> > > linked binaries on it, I dont see how a bootstrap can be achieved using
> > > 3.0.x compilers.
> > >
> > > I too, however, have installed a 3.0.x based system.  I did the
> > > bootstrap on 2.95.3, then first thing after bootstrap, I merged gcc
> > > 3.0.4, and then did my emerge system.  As Geert said, a few problems
> > > along the way, but not many.  I too made patches for all the problems I
> > > found, I submitted them to Geert.  The patches I made are ALL backward
> > > compatable to 2.95.3 (I believe, I've not tested this).  But then, I
> > > could also have compiled a different package set than he did.
> > >
> > >
> > > On Sat, 2002-04-06 at 07:01, Geert Bevin wrote:
> > > > Hi all,
> > > >
> > > > I finally installed 1.0 from scratch and decided to try it out with gcc
> > > > 3.0.4 instead of 2.95.3. Along the way I encountered some problems, but
> > > > surprisingly little. I've fixed everything that needed fixing and sadly
> > > > some packages are backwards incompatible. For that reason and for the
> > > > ease of maintenance I've created a dedicated gcc 3 profile.
> > > >
> > > > So, for those that want to try this out, just link the default-1.0-gcc3
> > > > profile instead of default-1.0 to /etc/make.profile. Note that this will
> > > > only work for installations from scratch and not for updates since
> > > > applications that link against libstdc++ v2 require the libraries of gcc
> > > > v2 and not gcc v3.
> > > >
> > > > There are still some packages that don't compile such as galeon and
> > > > openjade, but these will be fixed in a matter of time since I need them
> > > > ;-) Feel free to submit fixes too.
> > > >
> > > > Best regards,
> > > >
> > > > Geert Bevin
> > > > --
> > > > Geert Bevin             Uwyn
> > > > "Use what you need"     Lambermontlaan 148
> > > > http://www.uwyn.com     1030 Brussels
> > > > gbevin@××××.com         Tel & Fax [phone]
> > > >
> > > > _______________________________________________
> > > > gentoo-dev mailing list
> > > > gentoo-dev@g.o
> > > > http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> > >
> > > Thanks,
> > >
> > > --
> > > PreZ
> > > Systems Administrator
> > > GOTH.NET
> > >
> > > Goth Code '98:   tSKeba5qaSabsaaaGbaa75KAASWGuajmsvbieqcL4BaaLb3F4
> > >                  nId5mefqmDjmmgm#haxthgzpj4GiysNkycSRGHabiabOkauNSW
> > >
> > > GOTH.NET - http://www.goth.net
> > > Free online resource for the gothic community.
> > --
> > Geert Bevin             Uwyn
> > "Use what you need"     Lambermontlaan 148
> > http://www.uwyn.com     1030 Brussels
> > gbevin@××××.com         Tel & Fax [phone]
> >
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@g.o
> > http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> --
> PreZ
> Systems Administrator
> GOTH.NET
>
> Goth Code '98:   tSKeba5qaSabsaaaGbaa75KAASWGuajmsvbieqcL4BaaLb3F4
>                  nId5mefqmDjmmgm#haxthgzpj4GiysNkycSRGHabiabOkauNSW
>
> GOTH.NET - http://www.goth.net
> Free online resource for the gothic community.
-- 
Geert Bevin             Uwyn
"Use what you need"     Lambermontlaan 148
http://www.uwyn.com     1030 Brussels
gbevin@××××.com         Tel & Fax [phone]