At 17:41 Uhr -0500 02.02.2002, David R. Morrison wrote:
>Max Horn <[EMAIL PROTECTED]> wrote:
>
>> I have to correct myself: the actual cause is that we use a different
>> install_name at link time, i.e. we give libz.1.dylib as install_name,
>> and Apple obviously libz.1.1.3.dylib.
>
>Very good.
Max Horn <[EMAIL PROTECTED]> wrote:
> I have to correct myself: the actual cause is that we use a different
> install_name at link time, i.e. we give libz.1.dylib as install_name,
> and Apple obviously libz.1.1.3.dylib.
Very good. So the strategy I am proposing in my shared libraries messages
At 22:59 Uhr +0100 02.02.2002, Max Horn wrote:
>>Here is my question, though. Do you know why the library got listed as
>>libz.1.dylib before, but now it is getting listed at libz.1.1.3.dylib?
>>It seems to me that it is more robust, for possible future upgrades,
>>if the otool listing gives libf
At 16:08 Uhr -0500 02.02.2002, David R. Morrison wrote:
>Hi Max. I'm testing your new zlib, and it works great. In both of the
>packages I depended which depend on zlib, at the outset, otool -L gave
> /sw/lib/libz.1.dylib (compat. 1.1.3, current 1.1.3)
>
>Then I installed the new zlib and ever
Hi Max. I'm testing your new zlib, and it works great. In both of the
packages I depended which depend on zlib, at the outset, otool -L gave
/sw/lib/libz.1.dylib (compat. 1.1.3, current 1.1.3)
Then I installed the new zlib and everything still ran.
Then I recompiled my packages; now otill -L
