Red Hat Bugzilla – Bug 23555
libc5 and glibc2 versions of libz have same version number
Last modified: 2016-11-24 10:28:36 EST
Somebody tried configuring and building Ethereal on Red Hat 6.1; the
configure script found libz, and found "gzseek()" in libz, so it
configured Ethereal to use libz (to read gzipped capture files), but
the subsequent link stage failed to find "gzseek()" in libz.
The problem appeared to be that, for some reason, the configure stage
found "/usr/lib/libz.so.1", but the link stage found
"/usr/i486-linux-libc5/lib/libz.so.1"; the former is based on a newer
version of libz than the latter, as the former has "gzseek()" while the
glibc2 and libc5 have different major version numbers, suggesting either
1) they are binary-incompatible (e.g., due to data structures
changing their layout)
2) the Linux world got screwed by AT&T getting rid of shared
library minor version numbers when they implemented a
SunOS 4.x-derived shared library mechanism in SVR4 (shafting
other OSes using ELF).
In the former case, binaries built with libc5 and binaries built with
glibc2 would need to use different shared libraries except for shared
libraries that make *no* calls to libc routines whatsoever (I suppose
if a library calls only routines that *are* binary-compatible in the
two versions of libc, that isn't necessary, but it's probably too risky
to do that).
In the latter case, there's no "nice" solution, short of picking up what
I think Sun implemented in recent Solaris releases, i.e. a mechanism for
putting minor version numbers into shared library binary files.
If libc5 and glibc2 binaries use different run-time linker binaries, the
two run-time linkers should try to avoid picking up shared libraries for
the other version of libc; the person who had the problem with Ethereal
claimed that "/etc/ld.so.conf" contained
but perhaps there should be separate "ld.so.conf" files for the separate
If libc5 and glibc2 binaries use the *same* run-time linker, this problem
is harder to solve - libc5 binaries and glibc2 binaries both appear to
expect libz to have a major version number of 1, so bumping the major
version number of the glibc2 version of libz to 2 would break glibc2
binaries linked with the shared version of glibc2.
This isn't a zlib problem, but a linker/glibc problem. Reassigning (although I'm
pretty sure there isn't that much to do about it... and glibc is already using a
versioning scheme for symbols)
libc5 uses different dynamic loader (ld-linux.so.1) than glibc2 (ld-linux.so.2),
but they use the same cache file which has flags to which of these libraries
belong, so in the cache is /usr/i486-linux-libc5/lib/libz.so.1 marked as
ELF libc5 while /usr/lib/libz.so.1 is marked as ELF libc6 and the dynamic linkers
of course only look for "their" libraries.
I believe the issue is different: if the link stage found
/usr/i486-linux-libc5/lib/libz.so.1 then you must have used the compatibility
compiler (or put -L/usr/i486-linux-libc5/lib yourself in), but if configure
did not found that library, it means either a wrong compiler was used at
configure time, or that the configure script looked at gzseek by not calling
compiler but using other method.
So, unless I know how was Ethereal instructed to use the compatibility compiler,
I tell more.
Closed because of inactivity.