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. _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
