RFC: Support for libjpeg7
Andrew John Hughes
gnu_andrew at member.fsf.org
Mon Oct 26 15:24:59 PDT 2009
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
>> 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.
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the distro-pkg-dev