Status of 1.7

[Andrew John Hughes]

2010/1/11 Matthias Klose <doko at ubuntu.com>:
> 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.
>

Neither do I.  What are you trying to build - zero or the native sparc
port?  And does it work when using precompiled headers?  And does it
succeed on 1.6?

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

Thanks.  Checked in to HEAD and 1.7.
-- 
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