Wireshark · Wireshark-dev: Re: [Wireshark-dev] Portability issue of capture files.

[Guy Harris <guy@xxxxxxxxxxxx>]

LEGO wrote:

> there's libz.1.2.3 in both /usr/lib and /opt/local/lib

Gak.  Any idea what package installed its own private libz?  It probably 
shouldn't be doing that, unless it needs 1.2.3 or later and can't work 
with earlier versions.

> as soon as I removed that in /opt/local/lib I solved the issue...
> diferent library same mis-bahaviour as I used to have with open-ssl

Hmm.  libz tends to have problems on BSDish systems, courtesy of 
lseek()'s offset argument being 64-bit even on 32-bit platforms (see the 
long comment in wiretap/file_wrappers.c for details); OS X is a BSDish 
system in that regard.

Modern versions of BSDs have fixed the libz problem, although OpenBSD 
did it differently from the way the other BSDs (including OS X) do.

That's often the source of, umm, *surprising* behavior when reading 
capture files with versions of Wireshark built with libz if the version 
with which it was built is different from the version it's linking with 
at run time.

(Just out of curiosity, are there zlib.h and zconf.h headers in 
/opt/local/include?  If so, does zconf.h define z_off_t and, if so, how 
does it define it?  If it defines it as anything other than "long" under 
all circumstances, it's probably not binary-compatible with the zlib 
that comes with OS X.)

I just looked at the zlib.h on 10.4.7 - there's a zlibCompileFlags() 
routine that returns information including the size of z_off_t; at least 
for versions of zlib that have that routine, we could have wiretap 
check, at run time, whether the size matches the size we were built 
with, and fail if it's not.