RFC: Support for libjpeg7

[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