> > > [... talking about g++ 2.96 ...]
> > Don't use that compiler. It's known to be buggy. Use gcc 3.2.2
> > instead.
> I must confess that yes, I would *really* like to upgrade to
> gcc 3.2.2, but first, I'll present a full disclosure of my
> complete incompetence :-)
> Can someone explain to me, or point me to some literature or
> online documents where it is explained (in terms understandable
> by us, common mortals) how to upgrade or downgrade compilers,
> binary back and forward compatibility, etc.?
> From what I understand, if I replace the compiler, the runtime
> libraries are also replaced, and all of the existing binaries
> are broken. If I leave the original libraries (which to be
> honest, I have no clue if and how I can do it), then the
> programs compiled with the new compiler will not run properly,
> since the executable is not binary-compatible with the runtime
GCC includes the c++ runtime libraries, but libc is separate. The c++
libraries are incompatible between versions, but if you install a new
version the old ones can safely be left in place. Old programs will
use the old libraries.
Quote:> I wonder if I can install gcc 3.2.2 in addition to 2.96 (say,
> put it in /usr/local/bin) and explicitly choose it to compile
> my programs with it. What about my own shared libraries?
> (some portions of my applications are installed as shared
> libraries, and are used by many applications -- some of which
> are already compiled with the older compiler...)
Anything that's already compiled will continue to work. However, if
you install a new C++ compiler you won't be able to link new programs
against old C++ libraries. Recompiling all C++ libraries with the new
compiler will fix that, except that then the old programs will break.
In short, it can be a * business to upgrade a C++ compiler. Plain
C doesn't have any of these problems.
Quote:> One of the reasons why I'm so terrified about doing this is
> because the application I'm talking about is up and running,
> on a server actually connected to the Internet; I wouldn't
> want to start breaking existing software, binaries, services,
That seems wise.
Quote:> etc. I originally asked our providers to install RedHat 8
> (among other reasons, because it comes with gcc 3.* -- I think
> it's 3.2), and they refused, since they argued the kernel
> is incompatible with dual-Athlon processors...
So far, support for old hardware has never been dropped from the Linux
kernel, AFAIK. The newer kernel you get, the better it should work
with new stuff.
> So, to summarize... My head is already hurting, even though
> I have been merely *thinking* about it. Go figure when I
> try to actually do it... :-(
> Any advice? Any documents or some kind soul that would help
> me understand this obscure and mysterious area of the
> development process on Linux?
Try it on a non-critical machine and see what happens. It can't get
more than wrong. The best way to learn the proper way to do it is to
make a few mistakes and fix them. You're unlikely to make the same
mistake more than twice.