Status of 1.7
Andrew John Hughes
gnu_andrew at member.fsf.org
Mon Jan 11 06:11:39 PST 2010
2010/1/11 Matthias Klose <doko at ubuntu.com>:
> On 08.01.2010 20:20, Andrew John Hughes wrote:
>> Dear all,
>> We've done some testing of the upcoming 1.7 release within Red Hat and
>> don't see any regressions in JTreg. Deepak also now believes the new
>> plugin to be of a quality suitable for an alpha release as part of
>> I have a few minor fixes to add (bumping the hs16 option to the latest
>> revision and fixing a very minor issue with --with-parallel-jobs not
>> working if used without an argument). I'd like to aim for a release
>> on Wednesday.
>> Does this sound suitable to everyone?
> seen two issues:
> - 1.7 doesn't build on sparc64, at least on Debian. Asked if it does
> build on Fedora currently, but didn't get a reply yet.
I guess there aren't that many people running sparc64 GNU/Linux boxes
and building OpenJDK; I know I don't have any way of testing this If
it's been packaged for Fedora sparc64 though, I would have thought it
was built automatically.
Is this a regression from 1.6? Or an existing problem?
> - the jpeg7 patch probably needs to be reverted/changed. It seems
> to be wrong to use another libjpeg than what was used for the
> build. See http://bugs.debian.org/563999.
> "sun.awt.image.ImageFormatException: Wrong JPEG library version:
> library is 70, caller expects 62.
> I can't even build using jpeg7 because of conflicting build
> So either revert this patch, or stick to the jpeg version which
> was used for the build.
Well, we can't revert it without breaking all the new systems now
The version check occurs from these calls:
jpegcreatedecompress(&cinfo, JPEG_LIB_VERSION, (size_t) sizeof(struct
jpegcreatedecompress(cinfo, JPEG_LIB_VERSION, (size_t) sizeof(struct
jpegcreatecompress(cinfo, JPEG_LIB_VERSION, (size_t) sizeof(struct
which are hardcoded with the build libjpeg version when compiled.
Changing the lib selection to:
#if JPEG_LIB_VERSION >= 70
void *handle = dlopen("libjpeg.so.7", RTLD_LAZY | RTLD_GLOBAL);
void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL);
should thus fix the problem by making the dlopen line match the later
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