ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-users: Re: [Ethereal-users] Re: Strange behaviour ethereal 0.9.0 (self compiled)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Tue, 5 Feb 2002 01:52:52 -0800
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".