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.