zlib1.2.3

[Martin Buchholz]

On Mon, Aug 24, 2009 at 11:06, Xueming Shen<Xueming.Shen at sun.com> wrote:
> Florian Weimer wrote:
>>
>> * Martin Buchholz:
>>
>>
>>>
>>>  45 +#ifdef _LP64
>>>  46 +typedef unsigned int  uLong;  /* 32 bits or more */
>>>  47 +#else
>>>  48  typedef unsigned long  uLong; /* 32 bits or more */
>>>  49 +#endif
>>>
>>
>> This is guaranteed to break interoperability with the system zlib.  If
>> you want to make such adjustments, you really have to rename all
>> functions to avoid name clashes.  Such clashes materialize if you load
>> a DSO which contains code linked to the system zlib (usually via JNI).
>>
>> Technically, this is not a regression because OpenJDK's existing zlib
>> 1.1 code is incompatible with 1.2 zlibs used on most systems, so the
>> same problem happens.
>>
>>
>
> None of the zlib functions/methods is exported from libzip.o as "glocal"
> symbol, we are using
> make/java/zip/mapfile_vers to make them "local". Those zlib methods are
> supposed to be
> only accessed by our "own" jar/zip jnis. So what is exactly the
> "interoperability with the system
> zlib" concern here?
>

Sherman: Running "nm" on jdk7 binaries suggests that you are right.

Florian: Do you have a test case demonstrating zlib failure due to
namespace contamination?

Martin