----- 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 <ahug...@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
