Native zlib libraries (original) (raw)

Andrew Hughes ahughes at redhat.com
Mon Jul 30 12:35:24 UTC 2012

----- 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 (USESYSTEMZLIB=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

#else -typedef unsigned long uLong;

(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

More information about the core-libs-dev mailing list