Native zlib libraries

[Andrew Hughes]

----- Original Message -----
> Two other obvious candidates are the bundled jpeg and gif libraries.
> Please suggest a patch for build-infra/jdk8!
> 
> Backporting the new build system for jdk7/jdk6 is not even on the
> horizon. It
> would be nice though, and probably not impossible.
> 
> //Fredrik
> 
> 9 jul 2012 kl. 01:52 skrev Andrew Hughes:
> 
> > 
> > 
> > ----- Original Message -----
> >> The new build system offers a convenient option to the configure
> >> script:
> >> --with-zlib=system
> >> this will pickup the zlib libraries from the system.
> >> 
> >> The default behavior is: --with-zlib=bundled
> >> 
> > 
> > Have you done any others?  And is this available from the old bug
> > system?
> > 
> > This is the first I've heard of this being done and we need it in 6
> > & 7 too.
> > 
> >> //Fredrik
> >> 
> >> 2012/7/5 Andrew Hughes <ahughes at redhat.com>:
> >>> 
> >>> 
> >>> ----- Original Message -----
> >>>> Is there a way to get the native zlib libraries to get picked up
> >>>> instead of the hardcoded version within the JVM?
> >>>> 
> >>>> --
> >>>> Azeem Jiva
> >>>> @javawithjiva
> >>> 
> >>> We have this in IcedTea (USE_SYSTEM_ZLIB=true) and intend to get
> >>> it
> >>> upstream.
> >>> 
> >>> However, I don't see how this is related to HotSpot, as the zlib
> >>> usage
> >>> is in the jdk tree.
> >>> --
> >>> Andrew :)
> >>> 
> >>> Free Java Software Engineer
> >>> Red Hat, Inc. (http://www.redhat.com)
> >>> 
> >>> PGP Key: 248BDC07 (https://keys.indymedia.org/)
> >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
> >>> 
> >> 
> > 

It looks like most of our zlib work has already been reproduced by your good
self.  Saves me a job! :-D (for 8 anyway)

The main differences seem to be a minor naming one (USE_SYSTEM_ZLIB/SYSTEM_ZLIB) and
the hardcoding of -lz over ZLIB_CFLAGS/ZLIB_LIBS (I'll suggest a patch for this).

However, I'm not clear as to which version of zlib you used, because, in its current
form, SYSTEM_ZLIB doesn't work for me:

In file included from ../../../../../src/share/native/com/sun/java/util/jar/pack/bands.cpp:37:0:
../../../../../src/share/native/com/sun/java/util/jar/pack/defines.h:98:22: error: conflicting declaration 'typedef unsigned int uLong'
In file included from ../../../../../src/share/native/com/sun/java/util/jar/pack/defines.h:36:0,
                 from ../../../../../src/share/native/com/sun/java/util/jar/pack/bands.cpp:37:
/usr/include/zconf.h:368:24: error: 'uLong' has a previous declaration as 'typedef long unsigned int uLong'
../../../../../src/share/native/com/sun/java/util/jar/pack/bands.cpp:449:1: warning: missing initializer for member 'band_init::defc' [-Wmissing-field-initializers]
../../../../../src/share/native/com/sun/java/util/jar/pack/bands.cpp:449:1: warning: missing initializer for member 'band_init::index' [-Wmissing-field-initializers]

In our patch, we did:

-#ifdef _LP64
-typedef unsigned int uLong; // Historical zlib, should be 32-bit.
+#ifdef USE_SYSTEM_ZLIB
+ #include <zlib.h>
#else
-typedef unsigned long uLong;
+ #ifdef _LP64
+ typedef unsigned int uLong; // Historical zlib, should be 32-bit.
+ #else
+ typedef unsigned long uLong;
+ #endif 

(see http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/3a2014eddd87)

so that uLong was only defined locally if zlib was in-tree.  There is some odd logic in 8:

#if !defined(MACOSX) || (defined(MACOSX) && defined(NO_ZLIB))

Should this not just be #if defined(NO_ZLIB)?

It works for me if I change to that.

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07