[PATCH] Allow usage of external zlib copy

[Phil Race]

Diego 'Flameeyes' Pettenò wrote:
> 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 ?
>   
yes
> 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.
>   

umm so you are stll installing the JDK version .. in that case I am not 
sure what you did to ensure
that those JNI methods invoke the symbols in the gentoo version. Symbol 
resolution will first
look in the same .so. You'd need to not include those .. I don't doubt 
this can be made to
work  to a degree but since I expect the OpenJDK libjpeg version to have 
additional stuff than the
gentoo version its not ideal.

>> 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.
>   
OK that makes sense.
I guess I see this in your ZLIB changes but not for JPEG I assume that's 
a TBD



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

An option to build libsplashscreen so that it grabs jpeg, gif and png 
support from platform
libs rather than compiling in its own seems fine to me.  They don't need 
the extra stuff
in the JDK version
The fact that the splashscreen stuff builds its own JPEG *is* an 
annoying anomaly.
I can't  remember  or don't know why exactly AWT did this but  I've  had 
in the  back of my mind
to  make it point to the libjpeg in the JDK for this.

 BTW the approach of deferring to the installed version of the library 
most certainly
is something that we do when it makes sense and will do for libfreetype, 
for example

-phil.