On 9/7/06, Guy Harris <guy@xxxxxxxxxxxx> wrote:
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.
Darwinports does use its own dependencies for a *lot* of things even
if unnecessary. Happens for openssl which they deliver the same
version that tiger has as well as zlib, iconv and others. I think they
do that because they want it to work from Cheetah to Tiger... I regret
they do not check whether what's already there is OK.
(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.)
Both OS X's and Darwinports' use the one defined in
/usr/include/sys/_types.h as __int64_t .
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.
I think it has more to do with the binary using offets for symbols of
one dylib on another dylib (as I said I had the same issue in the past
with openssl on my PPC powerbook ).
Honestly I had never understood the obscure magic behind dynamic
linking. What makes it look weird to me is that my PPC powerbook has
both copies of zlib as well but it doesn't misbehave while on the
intel one does...
Luis
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan