Bug 23555 - libc5 and glibc2 versions of libz have same version number
libc5 and glibc2 versions of libz have same version number
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-07 16:01 EST by Guy Harris
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-10 05:35:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Guy Harris 2001-01-07 16:01:46 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
latter doesn't.

glibc2 and libc5 have different major version numbers, suggesting either
that

	1) they are binary-incompatible (e.g., due to data structures
	   changing their layout)

or

	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

	/usr/i486-linux-libc5/lib
	/usr/lib

but perhaps there should be separate "ld.so.conf" files for the separate
run-time linkers.

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.
Comment 1 Trond Eivind Glomsrxd 2001-01-08 12:14:52 EST
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)
Comment 2 Jakub Jelinek 2001-01-10 05:34:50 EST
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.
Comment 3 Jakub Jelinek 2001-02-12 04:35:28 EST
Closed because of inactivity.

Note You need to log in before you can comment on or make changes to this bug.