RFR: 8010785: JDK 8 build on Linux fails with new build mechanism

Erik Joelsson erik.joelsson at oracle.com
Mon Jun 3 07:21:26 PDT 2013


Hi David,

Thanks for the comments, new webrev for jdk:

http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.03/

On 2013-06-03 06:22, David Holmes wrote:
> Hi Erik,
>
> In CreateJars.gmk I don't understand why you move the update to the 
> JARS variable inside the BUILD_CRYPTO conditional when the jar file is 
> a pre-req for a target defined outside of that conditional. What are 
> the allowed combinations:
>
> BUILD_CRYPTO=yes, OPENJDK=true  == OK (normal OpenJDK build)
> BUILD_CRYPTO=yes, OPENJDK=false == OK? (builds but doesn't use it?)
> BUILD_CRYPTO=no,  OPENJDK=true  == ILLEGAL? (missing re-req in rule?)
> BUILD_CRYPTO=no, OPENJDK=false  == OK (normal Oracle JDK build)
>
> This also seems to indicate that the earlier comment block:
>
> 469 
> ##########################################################################################
>  470 # For all security jars, always build the jar, but for closed, 
> install the prebuilt signed
>  471 # version instead of the newly built jar. Unsigned jars are 
> treated as intermediate targets
>  472 # and explicitly added to the JARS list. For open, signing is not 
> needed. See SignJars.gmk
>  473 # for more information.
>
> needs updating to account for this new condition. ("security" covers 
> these crypto jars).
>
This is true and I've updated the comment to point it out. 
BUILD_CRYPTO=false and OPENJDK=true is not a legal combination.
> ---
>
> In Setup.gmk, wouldn't this:
>
> 38 ifndef OPENJDK
>   39   # Some licensees do not get the Security Source bundles.  We will
>   40   # fall back on the prebuilt jce.jar so that we can do a best
>   41   # attempt at building.
>   42   ifeq ($(wildcard 
> $(JDK_TOPDIR)/src/share/classes/javax/crypto/Cipher.java),)
>   43     JCE_PATH := 
> $(PATH_SEP)$(JDK_TOPDIR)/make/closed/tools/crypto/jce/jce.jar
>   44   endif
>   45 endif
>
> be better handled by a configure check that the sources exist - as is 
> done for other potentially not-present components? Further I think 
> this kind of check belongs in a closed build file as it doesn't relate 
> to building the openjdk sources.
>
Also true. The condition is actually similar enough to that of 
BUILD_CRYPTO to be treated as the same. I moved this to a closed file.

/Erik
> Thanks,
> David
>
> On 31/05/2013 8:14 PM, Erik Joelsson wrote:
>> Finally getting back to this. Updated webrevs:
>>
>> http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.02/
>> http://cr.openjdk.java.net/~erikj/8010785/webrev.root.02/
>>
>> The javascript part is no longer needed since it has been removed.
>>
>> /Erik
>>
>> On 2013-04-11 12:53, Erik Joelsson wrote:
>>> Open part of this review.
>>>
>>> The licensee bundles aren't buildable with the new build for several
>>> reasons. I've tried to fix all the issues that I've found and have now
>>> successfully built them on linux, windows and solaris. Here is a list
>>> of the changes that I had to do to OpenJDK:
>>>
>>> * Filter out javascript src when the rhino source isn't available.
>>> Also do not copy rhino resource files when not available. This is
>>> controlled by a new variable, INCLUDE_JAVASCRIPT, which we control
>>> from closed configure and shouldn't affect the OpenJDK build. I also
>>> moved the copying of the resources to the correct makefile,
>>> CopyIntoClasses.gmk.
>>>
>>> * If javax/crypto isn't available, jce.jar needs to be added to the
>>> bootclasspath of the main java compilation. Also, a number of security
>>> jar files shouldn't be built at all. (Normally these are built just to
>>> exercise the logic, but not used.) The kerberos library is also
>>> excluded by this. Introduced the variable BUILD_CRYPTO, also set by
>>> closed configure to control this. I used the logic ifneq
>>> ($(BUILD_CRYPTO),no) to not change the behavior if the variable isn't
>>> set, which it won't be in the open case.
>>>
>>> * I removed the logic for setting the closed cacerts file in the open
>>> configure script.
>>>
>>> * Also fixing JDK-8005655 by adding logic for unzipping sec-bin (and
>>> friends) if available.
>>>
>>> http://cr.openjdk.java.net/~erikj/8010785/webrev.jdk.01/
>>> http://cr.openjdk.java.net/~erikj/8010785/webrev.root.01/
>>>
>>> /Erik


More information about the security-dev mailing list