RFC: Support for libjpeg7

[Andrew John Hughes]

2009/10/26  <jon.vanalten at redhat.com>:
>
> ----- "Andrew John Hughes" <gnu_andrew at member.fsf.org> wrote:
>
>> 2009/10/26  <jon.vanalten at redhat.com>:
>> > Hi all,
>> >
>> > After chasing red herrings (my own fault, as apparently using the
>> more generic libjpeg.so symlink, which according to
>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=98 shouldn't be
>> done anyways, caused dlopen to look in a jdk-internal .so file for
>> symbols that weren't there), I've found that simply explicitly
>> dlopen-ing libjpeg.so.7 seems to work just fine.  This addresses
>>  http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=367.  I've
>> tried opening and displaying .jpeg images, changing ColorSpace via
>> ColorConvertOp and writing out the result, rescaling via RescaleOp and
>> writing out the result, seems okay.  The application noted in the bug
>> report launches.
>> >
>> > Attached is patch which adds this support.  If this looks good I'll
>> also edit the INSTALL file to indicate the supported library.  The
>> version 7 .so is checked first, as it is newer; if it is not present,
>> it falls back to 6b.  Is this the best strategy?  Any other comments,
>> or suggestions for Java programs that might give good coverage of the
>> use of libjpeg.so in openjdk would be appreciated.
>> >
>> > Thx,
>> >
>> > jon
>>
>> I'm glad this is a simple fix.  It seemed strange that the new
>> libjpeg, which is supposed to be ABI compatible and builds fine
>> against numerous other packages, would be the cause of the breakage.
>>
>
> Indeed.  What threw me off: the backtrace generated with a bad .so was very nearly exactly the same as when it tried to open a .so.62 that simply wasn't there.  Go figure.
>
>> The fix looks good to me.  I do wonder if we should check for NULL a
>> second time and fail more cleanly -- is that even possible from this
>> point in the code?
>
> Hmm, it's called within a static instantiator.  I'm honestly not sure how we can indicate failure at that point.  Perhaps it fails silently and the JNI hooks do better checking for null function pointers?
> But if we are considering this, we should also have better error checking (thus more graceful failures) for the dlsym calls.  The segfault is actually coming when we dlclose a handle that has already been dlclosed (it fails gracefully at dlsym calls with a bad handle, but not the dlclose).  The only way (besides throwing in a goto which I couldn't abide by) I can think of is to put the symbol names into a char**, and have a corresponding array of the function pointers, and put the dlsym calls into a loop.  This does, however, get complicated by the fact that the function pointers are each typed differently.
> Considering that this is a pretty common library (ie it is likely to be installed and intact on systems), this seems not quite worth it.  Thoughts?
>
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>

Yeah, don't worry about it too much.  The chance of it failing is
going to be as rare as a libjpeg release I guess... ;)

It's also safe to say that if the build is from an RPM/deb/etc. or was
built on the same system, then libjpeg must be installed due either to
dependency management or the configure check for it.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8