Status of 1.7

[Andrew John Hughes]

2010/1/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> 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
>

I'm still working on hs16; Shark needs a patch to build against the
latest b13.  As hs16 is non-default, I'd rather we shipped with the
version that will be in b18 rather than an earlier version.  That
should allow testing of hs16 with 1.7 to be comparable with the
eventual b18 version.  Other than that, there are a few configure
issues I'd like to fix before release (just some output cleanup and
the issue with --with-parallel-jobs i mentioned before).

I don't think sparc64 support is worth holding back on 1.7 for,
especially as it's not a regression from 1.6.

So let's go for a release on Friday, all being well.
-- 
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