Re: woody's libc vs. the rest of the world's libc?
On Wed, Jul 04, 2001 at 04:15:28PM +0200, Marcelo E. Magallon wrote:
>
> this is getting annoying, to say the least. I compile a program on a
> woody|sid box (linkage: -ldl -lm, and -lc implicitly) and try to run it
> on something (anything) else and the dynamic linker complains about not
> being able to find version GLIBC_2.2. This happens more often than not
> (in the particular case that triggered this email the other system has
> libc 2.1.3, whose SONAME *is* libc.so.6). Is there a way to solve this
> problem *without* installing a new libc on the *other* system? And a
> somewhat related question: if these versions (2.0.x vs 2.1.3 vs 2.2.x)
> are not 100% ABI compatible, why do we keep pretending they are?
>
Glibc is usually backwards compatible, but not forwards compatible.
That is, a program linked against glibc 2.2 will probably not run
under glibc 2.1, but a program linked against glibc 2.1 will probably
on glibc 2.2.
So the trick is that you need a development environment which has the
glibc 2.1 include files and stub libraries, and the resulting binaries
can run on both the newer and older systems. (Of course, your
binaries built in such an environment won't be able to take advantage
of the newer features of glibc 2.2, such as advanced
internationalization support, but that's the tradeoff you have to
pay).
> Other instances of this problem, from the top of my head: am-utils will
> break everytime a new libc is installed, in its most annoying
> manifestation it doesn't fail to load, it just blocks trying to mount
> any filesystem; nis also breaks after a libc6 upgrade (see
> changelog.Debian for Miquel's comments regarding this).
That's the reverse case, and it's not supposed to happen, but it does.
One of the reasons that the LSB was started was to try to help
insulate providers of binary packages from this kind of headache.
(This is why we have a separate directory for LSB libraries; so that
when the glibc folks screw up and make a backwards incompatible
change, we can hopefully work around the problem.)
I suggest that when these sorts of things happen, that you complain to
the newly formed glibc steering committee, and try to fix these sorts
of problems at the source. I once received e-mail from an glibc
developer stating that he considered it a feature that a backwards
incompatible change he made broke binary compatibility with evil
propietary software(tm), but I've been assured by the vice president
of the FSF that he's no longer in charge, and that the FSF and glibc
steering committee now consider it important to maintain backwards
binary compatibility.
(Of course it may be that am-utils and nis are violating abstraction
boundaries, and that's why they are glibc version dependent. If
that's the case, then someone will need to negotiate with the glibc
folks so that the appropriate portable interfaces can be exported. I
haven't had a chance to study those two specific cases in any kind of
depth.)
- Ted
Reply to: