Status of 1.7

[Matthias Klose]

On 11.01.2010 15:11, Andrew John Hughes wrote:
> 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
>>> 1.7.
>>>
>>> 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?

I don't know about the status of the Fedora builds. I just saw that it doesn't 
build on sparc64, while it does on sparc. Debian currently tries to bootstrap a 
sparc64 port.

>>   - 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
>>    dependencies.
>>    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
> using libjpeg7.
>
> The version check occurs from these calls:
>
> jdk/src/share/native/sun/awt/image/jpeg/jpegdecoder.c:
> jpegcreatedecompress(&cinfo, JPEG_LIB_VERSION, (size_t) sizeof(struct
> jpeg_decompress_struct));
> jdk/src/share/native/sun/awt/image/jpeg/imageioJPEG.c:
> jpegcreatedecompress(cinfo, JPEG_LIB_VERSION, (size_t) sizeof(struct
> jpeg_decompress_struct));
> jdk/src/share/native/sun/awt/image/jpeg/imageioJPEG.c:
> jpegcreatecompress(cinfo, JPEG_LIB_VERSION, (size_t) sizeof(struct
> jpeg_compress_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);
> #else
>      void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL);
> #endif
>
> should thus fix the problem by making the dlopen line match the later
> version check.

yes, this looks appropriate.