[PATCH] Allow usage of external zlib copy

Fri May 11 18:11:28 UTC 2007

On Fri, 11 May 2007 10:54:52 -0700
Phil Race <Phil.Race at Sun.COM> wrote:

> Building isn't the problem, Running is. The exported symbols in the 
> JDK's libjpeg are accessed via JNI
> calls so until you get an UnsatisfiedLinkError at runtime when  some
> JDK component tries
> to use it you won't know there's a problem. 

I admit I don't know enough of how JNI works myself, but aren't those
like Java_com_sun_imageio_plugins_jpeg_JPEGImageReader_readImage ?
Those symbols are still present in libjpeg.so library installed by
OpenJDK, which links to /usr/lib64/libjpeg.so (in my case) to get the
symbols for libjpeg proper.

> At the very least you'd need to find somewhere else to put the JNI 
> native methods and then
> have them able to locate libjpeg.
> 

> Also our build process has to be on all platforms. We need JPEG
> sources in the JDK
> since you aren't likely to find it on windows ..
That's why my patches adds an EXTERNAL_$something variable, that needs
to be enabled explicitly to use the external copy. The default build
would be 100% identical to what it was before, I put this as my top
priority for any change I do.

> They are not, so far as I know modified, except to remove exraneous
> stuff. These are used by the AWT splashscreen API, and so only need
> reading capability,
Okay, an option would then be to use external jpeg only for the same
AWT splashscreen API as it is, and leave the JNI version alone, if that
is more feasible for you. What you think about this?

-- 
Diego "Flameeyes" Pettenò
http://farragut.flameeyes.is-a-geek.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20070511/65cf38f4/signature.asc>