🚀 go-pugleaf

On Fri, 8 Jan 1999, Andreas Jaeger wrote:

> 2) If I compile my own binaries against glibc 2.1, all the other
>    libraries I use must be linked against glibc 2.1, too. 
>    a) Is this really correct?  

To my experience, no, you should not need to do this, with one notable
exception though: all the libs that are based or depend on libio will need
to be recompiled.

While doing the upgrade on my system I had to recompile only ncurses and
slang to get things to work.

>    b) Can I recompile all libraries and will my old binaries continue
>       to work, or should these libraries have a different major/minor
>       number?

You can do that, again, for everything that does not depend on libio. It
is the changes to the libio that are bringing us to the next subject,
which is...

> 3) What's the issue with glibc-compat-2.0.10*?  In what situations is
>    it needed?

Well, older binaries that were linked statically against glibc 2.0 will
reference the older nss modules (libnss_files.so.1 instead of
libnss_files.so.2). Also, the old glibc-2.0 compiled static libraries
(libfoo.a) which happen to depend on the older libio behavior will be
broken by the glibc 2.1 upgrade. The idea is to produce a libcompat.a that
people will be able to use to link in if they want to compile a static
library generated against glibc 2.0 into a program on a glibc 2.1 system.
You should just add -lcompat and you should be fine. 

Of course this does not work yet, i am working on it, my goal is to make
it possible for example to use Oracle's static .a libs to develop things
on a glibc 2.1 system. I am just fighting my way through detecting the
incompatibilities and why things break...

Cristian
--
----------------------------------------------------------------------
Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.