Ethereal-users: Re: [Ethereal-users] Re: Strange behaviour ethereal 0.9.0 (self compiled)
On Tue, Feb 05, 2002 at 10:38:06AM +0100, pigi@xxxxxxxx wrote:
> > Try building with "--disable-libz". If that works, it's almost
> > certainly a libz problem of some sort.
>
> I did it and obviously it works.
I.e., you configured with "--disable-libz" and rebuilt, and Ethereal now
works?
If so, please download the Ethereal 0.9.1 source tarball and configure
and build it - *without* getting rid of any version of libz (i.e., don't
remove the one in "/usr/X11R6/lib", and don't rebuild XFree86, before
configuring and building Ethereal). It *should* fail in the
configuration stage, with an
old zlib found when linking with X11 - get rid of old zlib.
error.
> I have two differents statics libz on my system.
> The first one is on /usr/lib/ and the other on /usr/X11R6/lib/.
> This second one ( which should be probably the wrong one ) comes from
> www.xfree.org ( as I needed an update of my X ambient ).
> The first one comes from the original package of Slackware 8.
I've seen this before on Slackware systems - and possibly on other Linux
systems.
XFree86 has, I guess, some form of gzipped font file support, or
something such as that. This may have come from one of the X11R6
releases from X.org.
To implement that, it includes a copy of a really old version of libz,
so that, on platforms that *don't* have libz, you can still get gzipped
font file support.
If XFree86 is built from source on a system that *does* have libz, the
configuration file for your system (in "xc/config/cf") should be changed
to define HasZlib as YES before configuring and building, so that it
doesn't build and install its own libz.
Installing the old libz on a system with a newer libz means that
programs *not* linked with a "-L" flag that includes the directory
containing X11 libraries will get linked with the new libz, but programs
that *are* linked with that flag will get linked with the old libz.
This means, for example, that Tethereal (which is not an X application)
will get the new libz, but Ethereal (which *is* an X application on
UNIX) will get the old libz.
> I would figure also why the Makefile generated would link staticly the
> libz. Any hint ?
Do you have any non-static libz's? If so, where are they, and is
Tethereal statically, or dynamically, linked with libz?
If you do, you may only have one in "/usr/lib", not in "/usr/X11R6/lib",
in which case Tethereal will be dynamically linked with the libz in
"/usr/lib", but Ethereal will be statically linked with the libz in
"/usr/X11R6/lib".
