[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-build-dev
Subject:    Native zlib libraries
From:       ahughes () redhat ! com (Andrew Hughes)
Date:       2012-07-30 12:35:24
Message-ID: 1918842039.5121189.1343651724469.JavaMail.root () redhat ! com
[Download RAW message or body]

----- 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


[prev in list] [next in list] [prev in thread] [next in thread]