Upgrading gcc and glibc (agian)

[Geoff]

On Fri, 01 Aug 2003 15:52:58 -0700, Net Llama! wrote:

<snip>
> 
> I assume that you're referring to the two entries that i wrote.

Yes, those are the ones.  Thanks for writing them and for responding so
promptly to my post.

> As far as
> gcc is concerned, yes its that easy.  Its damn hard to wreck your box by
> not building gcc right.

I can see that the build itself should be straighforward.  I had, in fact,
successfully compiled gcc 3.x previously, but did not install it becauseof
the concerns I mentioned.  In particular I have read that gcc 2.x and 3.x
are C++ binary incompatible.  I may be wrong (which is why I am asking
questions), but I understand this to mean that I may, for example, have
C++ lib.foo on my system compiled under 2.x, together with applications
compiled and dynamically linked against it.  Now I install gcc 3.x and try
to compile some new application.  It won't compile (or maybe run?) against
lib.foo because of the incompatibility, so I recompile lib.foo with 3.x.
Now my existing applications won't link dynamically to lib.foo, so I have
to recompile them.  In itself this is not a very big deal - but I can
imagine having an entertaining time tracking down problems in cases where
there may be multiple dependencies. I believe that there are relatively
sophisticated ways around these problems - by maintaining different
library versions and changing makefiles accordingly, but (keen as I am),
that really is beyond me - and in any case I have a living to earn - much
of it from my linux box.

> As for glibc, its relatively safe, but there's always a possibility
>of
> disaster.  Ironically, just today, i completely wrecked a box that
>was
> running Redhat-6.2, where i tried to upgrade straight to glibc-2.2.5 (it
> was runnning 2.1.2).  But, most of that problem was just the enormity of
> the upgrade, as nothing else had been upgraded yet.  I've successfully
> upgraded several other boxes' glibc without a hitch.  While there are
> always going to be some exceptions, most things will _not_ need to be
> recompiled after upgrading glibc.  Of course it also heavily depends on
> what version of glibc you have, and which you're upgrading to.  rpm will
> have to be recompiled, as it depends heavily on glibc's locale
> libraries.  zlib (and anything that depends on it) might also have to be
> recompiled.  But none of that is a showstopper, and won't incapacitate
> your box if you can't get to it right away.

Well, as said, I am going from glibc 2.2.5 to (I suppose), 2.3.2.  It may
be an advantage that I run LFS, so > 95% of everthing on my system  was
compiled locally and I have a pretty good understanding of the
geography of what I have. I don't even have rpm on the box. I suppose,
however, that  I hanker after some kind of certainty - a set of
instructions telling me precisely what will have to be recompiled so that
I can get on and do it rather than wait and see what does or does not
break.

>> I my system well backed up - so I am not worried about losing it - but
>> I don't want to get started only to screw up because the sxs guidance
>> is assuming something(s) I don't know.
> 
> Well, i don't know what you don't know :)

It would fill encyclopaedias.

>If you've got questions, or
> special circumstances, please ask.  We're all hear to help.

Thanks again.

Geoff