On Sun, Aug 05, 2001 at 09:42:50AM +1000, Walter wrote:
> > I've experienced this many times before... It's because of Xfree86
> > (possibly only 4.x)... It includes a libz that doesn't include the
> > functions, which is in the sharedlib path first, but the link path for
> > gcc has the /usr/lib/libz one, which does have the functions in it.
>
> I'm using Xfree86 4.x, installed by hand. So it's not Slackware's
> fault, for the record ;)
>
> So in order to resolve this, I should go find libz on freshmeat or
> something and overwrite it?
No.
The first step is to see how many libz shared libraries are installed;
if there is one installed in whatever directory XFree86 4.x installed
its libraries, and another one installed in another directory, use the
"nm" command to try to see if one of them defines "gzgets" and another
doesn't.
If the one installed by XFree86 doesn't, and the other one does, the
problem is what Nathan described.
If so, then did you install XFree86 from source, or from a binary
package?
If it's from source, then you should:
get rid of the zlib installed by XFree86;
make absolutely positively sure that whatever ".cf" file was
used to configure libz defines HaveZlib;
do the entire XFree86 4.x configure and build process from the
beginning (do a "make clean" or whatever cleans out all the
generated files, and then re-run the configuration process,
making sure all Makefiles get rebuilt);
install XFree86 4.x again;
make sure that it did *not* install zlib and, if it did, go back
and debug the XFree86 build process to see why it thinks it has
to install zlib (perhaps it didn't find the zlib in the other
directory), and loop until it works.
If it's from binary, then uninstall the binary, complain to its supplier
that it installs a very old version of zlib on a system that has a newer
better version (I should send a note to the XFree86 people asking them
to upgrade to a later version of zlib, so this sort of stuff doesn't
keep happening), and do an installation from source, as per the above.
Then do a "make distclean" in the Ethereal source directory, re-run
configure, and rebuild.
At some point, I'll stick a check into the Ethereal configure script to
make sure the answer it gets to the question "does zlib have gzgets?" is
the same regardless of whether the linking process includes the flags
used for GTK+ applications or not and, if it doesn't, stop with an error
(the user would then either have to fix X11 or build without zlib).
> Guy, do you still want me to send the logs to ethereal-dev?
Only if you don't find those two versions of zlib.