For users of --with-openjdk

Sat Aug 14 11:08:57 PDT 2010

On 08/13/2010 02:57 PM, Dr Andrew John Hughes wrote:
> On 20:34 Thu 12 Aug     , DJ Lucas wrote:
>> On 08/12/2010 07:41 PM, Dr Andrew John Hughes wrote:
>>> On 18:33 Thu 12 Aug     , DJ Lucas wrote:
>>>> On 08/11/2010 07:08 PM, DJ Lucas wrote:
>>>>
>>>>>
>>>
>>> With regard to your previous e-mail, I think you're right that the sun.awt.Toolkit
>>> fix is insufficent.  It was the result of only considering the two existing configurations;
>>> gcj+bootstrap, icedtea+no-bootstrap, with the intent of speeding up the no-bootstrap
>>> case.  In the no-bootstrap case, the built rt files aren't used so it was a waste of
>>> time building them.  So instead of removing the conditional altogether, I'd go for
>>> changing it to a BOOTSTRAPPING conditional.
>>>
>>
>> OK, will do.
>>
> 
> I've pushed this.

Got it locally now.  Thanks.

>>>>
>>>> The correct fix is to include $(SHARE)/javax/swing/plaf in
>>>> ICEDTEA_BOOTSTRAP_DIRS (as I am still using the 1.8.1 nimbus classes in
>>>> this particular case).  Again, given the larger target of possible
>>>> system JDKs, I wonder if it would be best to build rt.jar from scratch
>>>> rather than copying from the system version and updating selectively
>>>> (for similar reason to rebuilding tools.jar unconditionally as mentioned
>>>> earlier in this thread).  
>>>
>>> I've been thinking about this a bit.  It's quite a weird one.  The failure
>>> is due to a hack needed for backporting Nimbus to JDK6.  The SynthLookAndFeel
>>> class has to know about a possible subclass, NimbusLookAndFeel, because we can't
>>> add the needed method to the appropriate interface/superclass, as was done in
>>> 7.  So the synth look and feel now depends on the nimbus one being built before.
>>>
>>> In 1.8.1, you have an older version of NimbusLookAndFeel which is what causes the
>>> complaint.  In icedtea-no-bootstrap mode (and straight OpenJDK builds), we fixed
>>> this by building Nimbus first.  However, gcj can't generate Nimbus; so in bootstrap
>>> mode, you'll see that we pass DISABLE_NIMBUS=true in the Makefile and the files
>>> are instead compiled from pre-generated versions in the rt.stamp stage.
>>>
>>> I'm guessing this doesn't work for the icedtea-bootstrap mode because it doesn't
>>> pull in as many classes to rebuild as gcj does (presumably because Sun classes which
>>> are built when using gcj are found in rt.jar when using IcedTea).  Your fix seems
>>> correct, though for IcedTea, removing the DISABLE_NIMBUS line would also work.
>>
>> No, my proposed fix is not correct.  Disabling Nimbus in the stage1
>> build is the only working fix for both targets.  Will do locally.
> 
> I don't understand.  It already is disabled and bootstrapping with gcj works fine.

No, it was me who did not understand.  I misread your previous comments.
 Sorry for the confusion.  I was referring to including
$(SHARE)/javax/swing/plaf/synth in ICETEA_BOOTSTRAP_DIRS on a gcj build.
 IIUC, this will not work with a gcj bootstrap (though I haven't tried
it yet).  If that is true, then it has to be conditional.  Also, I did
not remove DISABLE_NIMBUS="true", but rather changed it to false
conditionally, and that resulted in the same error, so I went back to
the extra classes refresh in rt.jar.  Attached patch works for me, but
there is probably already a way to determine what the host JDK is, but
it escapes me at the moment if it is there already.  As of now, I am
basically working from tip with the exception of OpenType font support,
but I'll go back and build tip with the result of tonight's build to
verify anyway.

<Snip>

> 
> If someone wants to test a JDK as a bootstrap JDK, and they find
> issues, we'll try to fix them where appropriate.  There aren't really
> any specific versions, it's more a case of what people are willing to
> actively maintain.  If someone is willing to step up and keep doing
> regular builds with a certain system JDK, it'll be supported.

I'll be happy to continue down my current path whenever I am able to.
I'm always going to want to keep up with the current closed JDK.

<Snip>

>> BTW, 1.8 worked well enough with the -2 patch I posted a link to earlier
>> for my target (1.8.1->1.8.1)
> 
> Yeah I guessed it would without the OpenGL change.  It's probably worth
> fixing that on the 1.9 branch too so we don't regress from 1.8.

Attached patch will have to be moved appropriately for 1.9 branch (if
accepted) and could be done in the same location for 1.10 in FIND_JAVAC.

> 
> With regard to your patch for that, I don't think testing the VM is
> correct; it may get fixed in later versions of gcj and other VMs than
> gcj use that javah. I think (part of) the issue is
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40188 again, which there
> is already a configure test for in IcedTea7.  So I'll backport that.
> The other part of the issue is that gjavah doesn't seem to handle
> inner classes implicitly.

Excellent! That's one more done.  Applied locally.  So now, I have
nothing in my 1.9 that is not in 1.10 except the attached patch which
gets me a 1.9 build to completion (ignore the 1.9 in the name, is for
1.10).  I will try tip in a few moments, but don't expect a confirmation
until tomorrow.  BTW, for reference, machine is x86_64 with only 32bit
toolchain.  Not so sure I like the unattended testsuite results, so I
reran them without the screen saver active, and the results still are
not looking so good to me.  Are there some test suite changes that need
to come back with the Xrender changes?

--------------- jtreg console summary for hotspot ---------------
Test results: passed: 86
--------------- jtreg console summary for langtools ---------------
Error:  tools/javac/processing/6499119/ClassProcessor.java
FAILED: tools/javac/InterfaceAssert.java
Test results: passed: 1,377; failed: 1; error: 1
--------------- jtreg console summary for jdk ---------------
FAILED: com/sun/net/httpserver/bugs/B6361557.java
FAILED:
java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java
FAILED: java/awt/Focus/TranserFocusToWindow/TranserFocusToWindow.java
FAILED: java/awt/font/TextLayout/TextLayoutBounds.java
FAILED: java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java
FAILED:
java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java
FAILED:
java/awt/FullScreen/UninitializedDisplayModeChangeTest/UninitializedDisplayModeChangeTest.java
FAILED: java/awt/Graphics2D/DrawString/RotTransText.java
FAILED: java/awt/GraphicsDevice/CloneConfigsTest.java
FAILED: java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html
FAILED: java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html
FAILED: java/awt/print/PrinterJob/ExceptionTest.java
FAILED: java/awt/xembed/server/RunTestXEmbed.java
FAILED: java/beans/XMLEncoder/javax_swing_tree_TreePath.java
FAILED: java/net/MulticastSocket/NoLoopbackPackets.java
FAILED: java/net/URL/TestHttps.java
FAILED: java/nio/charset/Charset/NIOCharsetAvailabilityTest.java
FAILED: java/rmi/transport/pinLastArguments/PinLastArguments.java
MyDeflater had end() called
MyInflater had end() called
FAILED: javax/swing/plaf/synth/Test6933784.java
FAILED: sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java
FAILED: sun/java2d/cmm/ColorConvertOp/ColConvDCMTest.java
FAILED: sun/java2d/cmm/ColorConvertOp/MTColConvTest.java
FAILED: sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java
FAILED: sun/java2d/DirectX/AccelPaintsTest/AccelPaintsTest.java
FAILED:
sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
FAILED: sun/java2d/DirectX/OverriddenInsetsTest/OverriddenInsetsTest.java
FAILED:
sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java
FAILED: sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java
FAILED: sun/java2d/OpenGL/DrawBufImgOp.java
FAILED: sun/java2d/OpenGL/GradientPaints.java
FAILED: sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java
FAILED: sun/java2d/pipe/MutableColorTest/MutableColorTest.java
FAILED: sun/java2d/SunGraphics2D/DrawImageBilinear.java
FAILED: sun/java2d/SunGraphics2D/PolyVertTest.java
FAILED: sun/java2d/SunGraphics2D/SimplePrimQuality.java
FAILED: sun/nio/cs/Test4200310.sh
FAILED: sun/nio/cs/TestSJIS0213.java
Test results: passed: 3,287; failed: 37
: # kill testsuite processes still hanging
nothing to cleanup
make[1]: Leaving directory `/home/dj/icedtea6-1-9-7816c6d7a641'

DirectX?  I'm fairly sure those are expected to fail at least. :-)

<Snip>

> 
> The JCK only applies to binaries.  So it would only allow you to test
> a binary that you built and provided to users.  Anyone using the
> script (just like anyone using a Gentoo source ebuild) would have to
> license the JCK and test it themselves.
> 
> If binaries aren't your primary target, I wouldn't put too much weight
> on it.  The Free JTreg test suite is already integrated with IcedTea
> (try 'make check') and can be used to check the sanity of your
> builds. Others
> (http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html)
> already run the JCK on binaries built from the same sources.

Getting OT for this part of the discussion, but I just want it to verify
that the book instructions work as I expect them to.  As far as
providing a 'compatible' binary version, I could probably just piggy
back off of the RedHat RPM with rpm2tgz or similar.  That is the other
reason for wanting to use icedtea to bootstrap icedtea--historically,
building JDK from scratch has always been optional (and was dropped
shortly after OpenJDK was announced as the JRL source releases were
lagging behind quite a bit at that time), but there has always been an
upstream jdk*{arch}*.bin to install from, whereas there currently is not
(or not that I'm aware of) for IcedTea6.

-- DJ Lucas

-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: icedtea6-1.9-bootstrap_nimbus-1.patch
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20100814/9353f75e/icedtea6-1.9-bootstrap_nimbus-1.patch 