Ethereal-users: Re: [Ethereal-users] compiling

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: Thu, 13 Sep 2001 21:54:35 -0700
On Thu, Sep 13, 2001 at 10:44:40PM -0500, Tim Whitehead wrote:
> 
> cket-ypxfr.o packet-zebra.o asn1.o column.o follow.o in_cksum.o ipproto.o
> prefs.o print.o ps.o ptvcursor.o reassemble.o util.o xdlc.o register.o capture.o
> file.o filters.o proto_hier_stats.o summary.o wiretap/libwiretap.a gtk/libui.a
> epan/libethereal.a epan/ftypes/libftypes.a epan/dfilter/libdfilter.a -lcrypto
> .libs/etherealS.o -lpcap -L/usr/local/lib -L/usr/X11R6/lib -lgtk -lgdk
> -L/opt/gnome/lib -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm -lz
> -Wl,--export-dynamic
> wiretap/libwiretap.a(toshiba.o): In function `toshiba_check_file_type':
> toshiba.o(.text+0xba): undefined reference to `gzgets'
> wiretap/libwiretap.a(toshiba.o): In function `parse_toshiba_rec_hdr':
> toshiba.o(.text+0x35b): undefined reference to `gzgets'
> toshiba.o(.text+0x425): undefined reference to `gzgets'
> wiretap/libwiretap.a(toshiba.o): In function `parse_toshiba_hex_dump':
> toshiba.o(.text+0x634): undefined reference to `gzgets'
> collect2: ld returned 1 exit status
> rm -f .libs/etherealS.o
> make[2]: *** [ethereal] Error 1
> make[2]: Leaving directory `/home/tigmoid/ethereal/ethereal-0.8.19'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/tigmoid/ethereal/ethereal-0.8.19'
> make: *** [all-recursive-am] Error 2
> 
> 
> Any suggestions?

Don't install XFree86 4.x, or, if you do so, make sure that you
configure it with a configuration file that defines "HasZlib" as YES -
and make sure it does *NOT* install any files with names beginning with
"libz" in the directory in which it installs its libraries.

If you've already installed XFree86 from source, and there is a file
named "libz.a" or "libz.so" or "libz.so.N" for some number "N" in the
directory in which XFree86's libraries are installed, as well as one in
some other library directory, reconfigure XFree86, making sure "HasZlib"
is defined as YES is defined in "linux.cf" (XFree86 4.x appears to do so
*ONLY* if "LinuxDistribution" is "LinuxDebian", so if you're using, say,
Slackware, it probably won't define it), rebuild XFree86, reinstall it,
and then get rid of all the "libz.*" files in the XFree86 library
directory. 

If you've already installed it from binaries, and there is a file named
"libz.a" or "libz.so" or "libz.so.N" for some number "N" in the
directory in which XFree86's libraries are installed, ask whoever
supplied the binaries to supply you with a binary with HasZlib defined
and without its own copy of zlib.

(The problem is that XFree86 uses zlib, and has its own version for use
on platforms that don't have it.  It's a really old version, which lacks
a routine that Ethereal uses.  If you install, on a system that has an
up-to-date version of zlib, a version of XFree86 that includes the old
version, the Ethereal configure script will find the up-to-date version,
but the Ethereal build will find the old version, because it links with
the XFree86 libraries.

Having two versions of a library on a system is a good way to cause all
sorts of problems with programs that expect one version but get the
other, so it's generally Not A Good Idea.

The current version of the configure script in the Ethereal CVS tree
checks, if it finds a zlib that has "gzgets()", whether the zlib you get
when you link with the X11 libraries also has "gzgets()" and, if not,
stops with an error, telling the user to rebuild XFree86 without its own
zlib.  The Ethereal 0.8.19 version, alas, doesn't.)

The alternative is to configure Ethereal with "--without-zlib", and
rebuild.  If you don't care whether you can read gzipped files from
within Ethereal, that works; if you do, you'll have to clean up XFree86
(or whatever else gave you two zlibs, but that's the most likely
candidate).