Bug 23555

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.