zlib1.2.3

[Martin Buchholz]

On Mon, Aug 24, 2009 at 10:17, Xueming Shen<Xueming.Shen at sun.com> wrote:
> This is a different issue. I would prefer to separate the "to upgrade to
> zlib 1.2.3" and
> "to use host platform zlib on linux, if preferable" into two different
> tasks. We tend to
> try to put too many "similar" things into one project and end up missing the
> primary
> goal:-) Given the zlib is so "important", I would like to safe-land the
> zlib1.2.3 first,
> without touching too many other stuff.

Agreed.

> Personally I agree, there is good reason to use the zlib from native
> platform/resource,
> "depending on your perspective", as Joe said. However there is also good
> reason to
> stick with the approach of "using our own zlib, even there is a native
> zlib". The linux is
> an open platform and zlib itself is NOT a real "standard" library like libc,
> there is no
> guarantee that the zlib loaded on the platform is the one you want to use.
> Sure you
> can do your best try to "detect"...the reason I don't want to bundle this
> issue into the
> upgrade work.

Agreed.  Using the system zlib entails binary compatibility
risks of which I was not previously aware.

Martin

> Sherman
>
> Martin Buchholz wrote:
>>
>> It is reasonable for jni code to be built against the system zlib.
>> Such jni code should not accidentally invoke the jdk bundled zlib.
>> zlib includes support for symbol renaming (Z_PREFIX),
>> but better is to build the jdk so that jni does not have direct access
>> to the zlib functions under any name (but that might be a lot of work).
>>
>> Martin
>>
>> On Mon, Aug 24, 2009 at 00:20, Florian Weimer <fweimer at bfk.de
>> <mailto:fweimer at bfk.de>> 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.
>>
>>    --
>>    Florian Weimer                <fweimer at bfk.de <mailto:fweimer at bfk.de>>
>>    BFK edv-consulting GmbH       http://www.bfk.de/
>>    Kriegsstraße 100              tel: +49-721-96201-1
>>    D-76133 Karlsruhe             fax: +49-721-96201-99
>>
>>
>
>