zlib 1.2.3 -> 1.2.5
xueming.shen at oracle.com
Wed Nov 30 17:30:36 UTC 2011
There is a > 2/4G support issue we will need to address when using the
platform bundled zlib.
The total_in/total_out variables of z_stream_s is "long", which is not "big"
enough (32 bit) for ZIP64 support on a 32-bit platform. The zlib code
bundled with JDK has been updated to use "long long", as the (4)(5)(6)
in ChangeLog_java at
The Deflater/Inflater.getgetByteRead/Written() now use
"directly", so it will not be able to report the correct
if the value > 2G/4G, though it might be rare to deflate/inflate a >2/4G
A possible solution is to accumulate the "totalRead/Written" at java
as long as you don't pass in data > 2g/4g in one invocation, it should
On 11/30/2011 02:09 AM, Chris Hegarty wrote:
> On 30/11/2011 09:50, David Holmes wrote:
>> On 30/11/2011 7:43 PM, Alan Bateman wrote:
>>> On 30/11/2011 01:31, Dr Andrew John Hughes wrote:
>>>> On 10:23 Tue 29 Nov , Alan Bateman wrote:
>>>>> When we talked about the zlib version here (I think back in
>>>>> February) we
>>>>> talked about having the option to use the system's zip library where
>>>>> appropriate. Have you given this any thought recently?
>>>> We have changes for this (and other libraries) in IcedTea that we'd
>>>> to upstream. I'll look at posting a webrev soon.
>>> That would be great. If I remember correctly then the IcedTea patches
>>> remove the zlib code completely but we can't do that of course because
>>> of Windows. So I think a USE_SYSTEM_ZLIB as you suggest would be best.
>> FYI the macosx port is also adding a SYSTEM_ZLIB option:
> So this is a compile time decision, if you are targeting a platform
> that is known to have a system zip library you simply link against
> that. Nice!
> I've also been looking at the possibility ( for a different reason )
> of using supporting the system version of a library (if one is
> available) instead of the bundled version. This is to allow support of
> more recent versions of the system library to be used, rather than
> what may be an older bundled version, and targets platforms where a
> system library may or may not be available.
> Is this something that may be relevant here, or are we always
> guaranteed that the system will have a zip library available on our
> targeted OS-ARCH binaries?
More information about the core-libs-dev