On Fri, 01 Aug 2003 15:52:58 -0700, Net Llama! wrote: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.
Kurt is definitely much more of an expert on this than I. I also remember reading about this, but haven't yet run into it. This is just one of those forward looking issues that i've yet to experience. There are no backward looking issues though.
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.
Its impossible to tell you everything that needs to be recompiled, since there are essentially an infinite number of possibilities. All i can mention are the things i've run into, which are rpm, zlib, bzip2 & binutils. Thus far, everything else has worked.
If you can get gcc & glibc upgraded and still be able to go about your day to day activities, then you should be out of the woods. As Kurt mentioned, at this time there aren't really many advantages to having the latest & greatest, other than having the latest & greatest. So if you aren't comfortable, then don't do it.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman [EMAIL PROTECTED] Linux Step-by-step & TyGeMo: http://netllama.ipfox.com
7:00am up 18 days, 9:42, 1 user, load average: 0.14, 0.19, 0.09
_______________________________________________ Linux-users mailing list [EMAIL PROTECTED] Unsubscribe/Suspend/Etc -> http://www.linux-sxs.org/mailman/listinfo/linux-users
