RFC: Support for libjpeg7

[Andrew John Hughes]

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.

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