RFR: JDK-8033210: Intermittent build failure: jdk8 fails on win_i586 in jdk/make (p11_convert.c(67) : Cannot open 'sun_security_pkcs11_wrapper_PKCS11.h)
Tim Bell
tim.bell at oracle.com
Wed Feb 5 15:32:06 UTC 2014
Hi Erik
Looks good to me as well.
Tim
> Looks good to me.
>
> /Magnus
>
> On 2014-02-05 11:35, Erik Joelsson wrote:
>> Hello,
>>
>> This change is intended for jdk8u (and jdk9).
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8033210/webrev.root.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8033210
>>
>>
>> Background:
>> In make/common/JavaCompilation.gmk, in the macro
>> SetupJavaCompilation, we use the (new) -h feature in javac, which
>> makes javac automatically run javah on classes with native methods. A
>> problem is that javac will always print these headers, regardless of
>> if they are there already or if they changed. To only cause
>> recompilation of native code when something actually changed, there
>> is logic in the macro to generate the headers to a temporary
>> directory and then compare the output to any existing header files in
>> the actual headers directory, and then only copy it over if it has
>> changed. The temporary directory is then deleted.
>>
>> What I suspect is happening here is that, since the name of the
>> temporary directory is only a function of the name of the actual
>> header files directory, each call to SetupJavaCompilation, which
>> points to a common header files directory, will use the same
>> temporary directory. There is potential for a race if these execute
>> in parallel. On windows, there are a couple of extra calls to
>> SetupJavaCompilation that will execute in parallel, which is why this
>> happens there and not on any other platforms.
>>
>> The fix is pretty simple. Make sure the temporary directory name is
>> unique for each call to SetupJavaCompilation.
>>
>> /Erik
>
More information about the build-dev
mailing list