Re: (urgent) RFR: JDK-8218084: Revert JDK-8218057

[Christian Tornqvist]

Looks good, thanks for dealing with this so quickly

Thanks,
Christian

> On Jan 30, 2019, at 12:47 PM, Erik Joelsson  wrote:
> 
> The addition of new build profiles in jib-profiles.js caused our internal 
> build and test system to break down. While we fix the resilience of that 
> system, we need to back this change out. This patch is the result of:
> 
> $ hg backout 8830bb9587c2
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8218084
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8218084/webrev.01/
> 
> /Erik
> 

Re: (urgent) RFR: JDK-8218084: Revert JDK-8218057

[Joe Darcy]

+1

-Joe

On 1/30/2019 12:47 PM, Erik Joelsson wrote:
The addition of new build profiles in jib-profiles.js caused our 
internal build and test system to break down. While we fix the 
resilience of that system, we need to back this change out. This patch 
is the result of:


$ hg backout 8830bb9587c2

Bug: https://bugs.openjdk.java.net/browse/JDK-8218084

Webrev: http://cr.openjdk.java.net/~erikj/8218084/webrev.01/

/Erik

(urgent) RFR: JDK-8218084: Revert JDK-8218057

[Erik Joelsson]

The addition of new build profiles in jib-profiles.js caused our 
internal build and test system to break down. While we fix the 
resilience of that system, we need to back this change out. This patch 
is the result of:


$ hg backout 8830bb9587c2

Bug: https://bugs.openjdk.java.net/browse/JDK-8218084

Webrev: http://cr.openjdk.java.net/~erikj/8218084/webrev.01/

/Erik

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

[Martin Buchholz]

I agree with Andrew Hughes.

On Wed, Jan 30, 2019 at 9:27 AM Andrew Hughes  wrote:

>
> I'm aware of the benefits of using gold, and also occasional issues with
> it, but that's not the debate here. It's already perfectly possible to
> build with gold by using --with-ldflags="-fuse-ld=gold", as I've been
> doing for quite a while, or setting the system ld to be gold. What you're
> asking is that this option should be forced onto every build.
>
> My experience suggests that compiler flags should be kept to a minimum,
> and tested for where possible. One of the great benefits of OpenJDK finally
> having a configure system is that we can now check whether flags work
> before enabling them (e.g. my own changes to support GCC 6). What seems
> to work wonderfully on one's local machine often breaks in a variety
> of different
> ways when exposed to the variety of build environments out there.
>
> I guess you could add this with an --enable-gold option (on by default) and
> testing that the flag works in configure. I do have to wonder though if it
> is worth the effort and possible risks.
>

It's not!

Re: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails

[Erik Joelsson]

Here is a new webrev:

http://cr.openjdk.java.net/~erikj/8204564/webrev.02/

/Erik

On 2019-01-30 08:52, Erik Joelsson wrote:

Hello,

On 2019-01-30 01:51, Magnus Ihse Bursie wrote:

On 2019-01-30 02:18, Erik Joelsson wrote:

Hello,

Some recent build failures reminded me of this issue and increased 
the need to fix it ASAP to be able to diagnose them. 
GenerateLinkOptData.gmk runs a java tool to generate data which is 
later used to optimize the JDK image with jlink. The problem here is 
that the tool needs to print some of that data on stdout, which the 
build captures as one build artifact, and will print some "garbage" 
on stderr if things go well. So currently we just hide all that 
output from the build log. Because of this, if something goes wrong, 
we won't see the error.


This patch tries to capture the stderr output and only print it 
(along with stdout) if the java command fails.


Bug: https://bugs.openjdk.java.net/browse/JDK-8204564

Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/


Good idea, but could you please include some more information in the 
case of failure? The classlist data generation gets a lot of blame 
when the real cause is that the JDK is stillborn.


Something like:

    || ( exitcode=$$? && $(ECHO) "ERROR: Classlist file 
generation failed. This is typically a sign that the newly built JDK 
is broken, and not of an error in the Classlist generation." && 
$(ECHO) "Classlist stderr: " &&
$(CAT) $(LINK_OPT_DIR)/stderr && $(ECHO) "Classlist trace file:" && 
$(CAT) $(JLI_TRACE_FILE) \

 && exit $$exitcode )

but with better line breaks :)

Sure, but please note that this is not the first time we are running 
the newly built JVM in the build. To run the classlist generation, we 
must first create a couple of jmods and jlink them together into the 
interim image, so the newly built JVM/JDK cannot be completely broken 
for this to happen.


/Erik


/Magnus


/Erik

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

[Andrew Hughes]

On Thu, 24 Jan 2019 at 13:12, Magnus Ihse Bursie
 wrote:
>
> The default binutils linker used by gcc, the bfd linker, is slow. The
> new replacement, gold, has been distributed alongside gcc for several
> years now, and is a well mature, and much faster, replacement.
>
> This issue is about replacing ld.bfd with ld.gold for our gcc toolchain.
> In general, this cuts linking times by half or more.
>
> As a future improvement, gold also allows for incremental linking.
> Turning on that is outside the scope of this issue.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217723
> Patch inline:
> diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
> --- a/make/autoconf/flags-ldflags.m4
> +++ b/make/autoconf/flags-ldflags.m4
> @@ -70,7 +70,7 @@
>   fi
>
>   # Add -z defs, to forbid undefined symbols in object files.
> -BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs"
> +BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -fuse-ld=gold"
>
>   BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro"
>
> /Magnus

I'm aware of the benefits of using gold, and also occasional issues with
it, but that's not the debate here. It's already perfectly possible to
build with gold by using --with-ldflags="-fuse-ld=gold", as I've been
doing for quite a while, or setting the system ld to be gold. What you're
asking is that this option should be forced onto every build.

My experience suggests that compiler flags should be kept to a minimum,
and tested for where possible. One of the great benefits of OpenJDK finally
having a configure system is that we can now check whether flags work
before enabling them (e.g. my own changes to support GCC 6). What seems
to work wonderfully on one's local machine often breaks in a variety
of different
ways when exposed to the variety of build environments out there.

I guess you could add this with an --enable-gold option (on by default) and
testing that the flag works in configure. I do have to wonder though if it
is worth the effort and possible risks.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Re: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov

[Magnus Ihse Bursie]

On 2019-01-30 17:55, Alexandre (Shura) Iline wrote:



On Jan 30, 2019, at 8:53 AM, Erik Joelsson  wrote:


On 2019-01-30 06:48, Magnus Ihse Bursie wrote:


On 2019-01-29 17:55, Erik Joelsson wrote:

Hello,

On 2019-01-29 03:12, Magnus Ihse Bursie wrote:

If you are going down this road, you'll need to verify that JCOV_IMAGE_DIR is 
not empty in RunTests. So keep the ifneq statement, but with an $(error ...) 
instead. Otherwise we'll just fail spectacularly and incomprehensible later on.

This has already gone in with my blessing, but to address your concern.

I don't see why we need to check that it's set in RunTest.gmk? In the local 
case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be set,

... but only if we configure with --with-jcov.

I'd just like the system to present a comprehensible error message if the user does 
something like this: "make test TEST=tier1 TEST_OPTS=JCOV=true", but has not 
configured using --with-jcov. Prior to this patch, we ran the tests but without coverage. 
This is probably not what was intended, but it didn't crash. Now we're going to get a 
malformed command line.

"Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful error 
message.

When I test now, something is odd with the "jcov-image" target as well. Even if 
you have not run configure with --with-jcov, the target seemingly runs and succeeds, but 
no jcov image is generated. Expected behavior would be an error message stating that you 
need to use --with-jcov.


Ah I see, but the previously existing conditional only checked if the variable 
JCOV_IMAGE_DIR was set, not if the directory it pointed to existed, so it 
wasn't any better. We set the variable JCOV_IMAGE_DIR unconditionally in 
spec.gmk, so that check would always be true anyway.

What you are asking for is adding a new check that JCOV_HOME is set (this is a 
consequence of setting --with-jcov) and that JCOV_IMAGE_DIR actually points to 
something valid (this is the result of building jcov-image). It would also be 
nice if the jcov-image target failed with a reasonable error if JCOV_HOME 
wasn't set. I agree that these checks would be useful.

Yes, I think this pretty much sums up what I'm asking for.

I will fix that, unless somebody else really wants to take it.


Thanks Shura!

Re: the "Error: Unable to access jarfile /lib/jcov.jar" error message; I 
got that by running configure without --with-jcov (note that you 
automatically get --with-jcov if running using jib), and then running 
"make jcov-test TEST=tier1" (or whatever test). This tried to start the 
jcov reporter, but JCOV_HOME was not set.


Possibly all jcov operations should be checked that the value of 
JCOV_HOME is non-empty, and fail with an error message otherwise. And 
the testing should verify that the value of JCOV_IMAGE_DIR is non-empty 
and contains bin/java$(EXE_SUFFIX).


/Magnus


Shura.


/Erik


/Magnus


and in the prebuilt case, it's the responsibility of RunTestPrebuilt.gmk to 
adjust things for the lack of a proper spec.gmk and in RunTestPrebuilt.gmk we 
already check that JDK_IMAGE_DIR points to an existing directory.

/Erik


/Magnus


28 jan. 2019 kl. 18:47 skrev Erik Joelsson :

Hello Shura,

In RunTest.gmk, you removed the conditional, but the comment still implies that 
it's there. Please update the comment. Otherwise this looks good!

/Erik


On 2019-01-25 15:20, Alexandre (Shura) Iline wrote:
Hi,

Please take a look on a change to allow JCov test execution through jib.

Please notice that this fix also changes behavior of RunTest.gmk when 
conflicting combination of options is used. JCOV_IMAGE_DIR  is now expected to 
be set when TEST_OPTS_JCOV is true.

Shura

Bug: https://bugs.openjdk.java.net/browse/JDK-8217761
Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/

Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX

[Magnus Ihse Bursie]

On 2019-01-30 17:37, Andrew Leonard wrote:

Thanks David,
I just found the reference you mention, it is a little vague, but says
maybe as you said. I've reworked and tested the following which seems
better:
   NUM_CORES=`lparstat -m | grep -o "lcpu=[[0-9]]*" | cut -d "=" -f 2`
I'll create a new webrev with this.
Note that you should use $GREP and $CUT; in theory we should also check 
for lparstat, but we've been sloppy with that for the other cpu checking 
methods so maybe we can be that for AIX here as well.


/Magnus

Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com




From:   David Holmes 
To: Erik Joelsson , Andrew Leonard
, build-dev@openjdk.java.net
Date:   30/01/2019 02:25
Subject:Re: Proposal: JDK-8217896: Make better use of LCPUs when
building on AIX



On 30/01/2019 3:05 am, Erik Joelsson wrote:

Hello,

I'm OK with this, but since I can't verify it at all, I would be more
comfortable if one of the other AIX users would review this as well.

Ditto. I did some googling on this and pmcycles is flagged as maybe
being deprecated in the future and may require privileges to execute.
lparstat -i seems to be more commonly used.

David
-


/Erik

On 2019-01-29 05:08, Andrew Leonard wrote:

Hi,
Please can I get a sponsor for this build performance enhancement on

AIX,

by better determining the number of LCPUs on smt AIX machines:
  

https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.java.net_-7Ealeonard_8217896_webrev.00_=DwIDaQ=jf_iaSHvJObTbx-siA1ZOg=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ=FpNeQfFJBut0AAVlbC0w7o0urDCArfDb4PY1TtMVW4I=8vmPiiNU5P6MnXKdE-eyyBm48kgCssjH5VyWHAt5zcM=


My testing shows up to 30% improved build times when leveraging the
available LCPUs.
Many thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with

number

741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFR: JDK-8218057 Add ppc64le and s390x profiles to jib-profiles.js

[Erik Joelsson]

Looks good.

/Erik

On 2019-01-30 05:41, Magnus Ihse Bursie wrote:
With Volker's fix in JDK-8213698, creating devkits for cross-compiling 
on linux to various other platforms was made trivial.


This patch uses this functionality to add new cross-compilation 
targets for ppc64le and s390x to jib-profiles.js


As usual; this implies no commitment from Oracle to neither build nor 
test on these platforms.


Bug: https://bugs.openjdk.java.net/browse/JDK-8218057
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8218057-add-ppc64le-and-s390x-devkits/webrev.01


/Magnus

Re: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov

[Alexandre (Shura) Iline]

> On Jan 30, 2019, at 6:48 AM, Magnus Ihse Bursie 
>  wrote:
> 
> 
> 
> On 2019-01-29 17:55, Erik Joelsson wrote:
>> Hello,
>> 
>> On 2019-01-29 03:12, Magnus Ihse Bursie wrote:
>>> If you are going down this road, you'll need to verify that JCOV_IMAGE_DIR 
>>> is not empty in RunTests. So keep the ifneq statement, but with an $(error 
>>> ...) instead. Otherwise we'll just fail spectacularly and incomprehensible 
>>> later on.
>> 
>> This has already gone in with my blessing, but to address your concern.
>> 
>> I don't see why we need to check that it's set in RunTest.gmk? In the local 
>> case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be set, 
> 
> ... but only if we configure with --with-jcov.
> 
> I'd just like the system to present a comprehensible error message if the 
> user does something like this: "make test TEST=tier1 TEST_OPTS=JCOV=true", 
> but has not configured using --with-jcov. Prior to this patch, we ran the 
> tests but without coverage. This is probably not what was intended, but it 
> didn't crash. Now we're going to get a malformed command line.
> 
> "Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful error 
> message.
> 
> When I test now, something is odd with the "jcov-image" target as well. Even 
> if you have not run configure with --with-jcov, the target seemingly runs and 
> succeeds, but no jcov image is generated. Expected behavior would be an error 
> message stating that you need to use --with-jcov.

Do you have the exact command to reproduce that?

> 
> /Magnus
> 
>> and in the prebuilt case, it's the responsibility of RunTestPrebuilt.gmk to 
>> adjust things for the lack of a proper spec.gmk and in RunTestPrebuilt.gmk 
>> we already check that JDK_IMAGE_DIR points to an existing directory.
>> 
>> /Erik
>> 
>>> /Magnus
>>> 
 28 jan. 2019 kl. 18:47 skrev Erik Joelsson :
 
 Hello Shura,
 
 In RunTest.gmk, you removed the conditional, but the comment still implies 
 that it's there. Please update the comment. Otherwise this looks good!
 
 /Erik
 
> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote:
> Hi,
> 
> Please take a look on a change to allow JCov test execution through jib.
> 
> Please notice that this fix also changes behavior of RunTest.gmk when 
> conflicting combination of options is used. JCOV_IMAGE_DIR  is now 
> expected to be set when TEST_OPTS_JCOV is true.
> 
> Shura
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761
> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/
> 

Re: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov

[Alexandre (Shura) Iline]

> On Jan 30, 2019, at 8:53 AM, Erik Joelsson  wrote:
> 
> 
> On 2019-01-30 06:48, Magnus Ihse Bursie wrote:
>> 
>> 
>> On 2019-01-29 17:55, Erik Joelsson wrote:
>>> Hello,
>>> 
>>> On 2019-01-29 03:12, Magnus Ihse Bursie wrote:
 If you are going down this road, you'll need to verify that JCOV_IMAGE_DIR 
 is not empty in RunTests. So keep the ifneq statement, but with an $(error 
 ...) instead. Otherwise we'll just fail spectacularly and incomprehensible 
 later on.
>>> 
>>> This has already gone in with my blessing, but to address your concern.
>>> 
>>> I don't see why we need to check that it's set in RunTest.gmk? In the local 
>>> case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be set, 
>> 
>> ... but only if we configure with --with-jcov.
>> 
>> I'd just like the system to present a comprehensible error message if the 
>> user does something like this: "make test TEST=tier1 TEST_OPTS=JCOV=true", 
>> but has not configured using --with-jcov. Prior to this patch, we ran the 
>> tests but without coverage. This is probably not what was intended, but it 
>> didn't crash. Now we're going to get a malformed command line.
>> 
>> "Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful error 
>> message.
>> 
>> When I test now, something is odd with the "jcov-image" target as well. Even 
>> if you have not run configure with --with-jcov, the target seemingly runs 
>> and succeeds, but no jcov image is generated. Expected behavior would be an 
>> error message stating that you need to use --with-jcov.
>> 
> Ah I see, but the previously existing conditional only checked if the 
> variable JCOV_IMAGE_DIR was set, not if the directory it pointed to existed, 
> so it wasn't any better. We set the variable JCOV_IMAGE_DIR unconditionally 
> in spec.gmk, so that check would always be true anyway.
> 
> What you are asking for is adding a new check that JCOV_HOME is set (this is 
> a consequence of setting --with-jcov) and that JCOV_IMAGE_DIR actually points 
> to something valid (this is the result of building jcov-image). It would also 
> be nice if the jcov-image target failed with a reasonable error if JCOV_HOME 
> wasn't set. I agree that these checks would be useful.

I will fix that, unless somebody else really wants to take it.

Shura.

> 
> /Erik
> 
>> /Magnus
>> 
>>> and in the prebuilt case, it's the responsibility of RunTestPrebuilt.gmk to 
>>> adjust things for the lack of a proper spec.gmk and in RunTestPrebuilt.gmk 
>>> we already check that JDK_IMAGE_DIR points to an existing directory.
>>> 
>>> /Erik
>>> 
 /Magnus
 
> 28 jan. 2019 kl. 18:47 skrev Erik Joelsson :
> 
> Hello Shura,
> 
> In RunTest.gmk, you removed the conditional, but the comment still 
> implies that it's there. Please update the comment. Otherwise this looks 
> good!
> 
> /Erik
> 
>> On 2019-01-25 15:20, Alexandre (Shura) Iline wrote:
>> Hi,
>> 
>> Please take a look on a change to allow JCov test execution through jib.
>> 
>> Please notice that this fix also changes behavior of RunTest.gmk when 
>> conflicting combination of options is used. JCOV_IMAGE_DIR  is now 
>> expected to be set when TEST_OPTS_JCOV is true.
>> 
>> Shura
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217761
>> Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/
>> 

Re: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov

[Erik Joelsson]

On 2019-01-30 06:48, Magnus Ihse Bursie wrote:



On 2019-01-29 17:55, Erik Joelsson wrote:

Hello,

On 2019-01-29 03:12, Magnus Ihse Bursie wrote:
If you are going down this road, you'll need to verify that 
JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq 
statement, but with an $(error ...) instead. Otherwise we'll just 
fail spectacularly and incomprehensible later on.


This has already gone in with my blessing, but to address your concern.

I don't see why we need to check that it's set in RunTest.gmk? In the 
local case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to 
be set, 


... but only if we configure with --with-jcov.

I'd just like the system to present a comprehensible error message if 
the user does something like this: "make test TEST=tier1 
TEST_OPTS=JCOV=true", but has not configured using --with-jcov. Prior 
to this patch, we ran the tests but without coverage. This is probably 
not what was intended, but it didn't crash. Now we're going to get a 
malformed command line.


"Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful 
error message.


When I test now, something is odd with the "jcov-image" target as 
well. Even if you have not run configure with --with-jcov, the target 
seemingly runs and succeeds, but no jcov image is generated. Expected 
behavior would be an error message stating that you need to use 
--with-jcov.


Ah I see, but the previously existing conditional only checked if the 
variable JCOV_IMAGE_DIR was set, not if the directory it pointed to 
existed, so it wasn't any better. We set the variable JCOV_IMAGE_DIR 
unconditionally in spec.gmk, so that check would always be true anyway.


What you are asking for is adding a new check that JCOV_HOME is set 
(this is a consequence of setting --with-jcov) and that JCOV_IMAGE_DIR 
actually points to something valid (this is the result of building 
jcov-image). It would also be nice if the jcov-image target failed with 
a reasonable error if JCOV_HOME wasn't set. I agree that these checks 
would be useful.


/Erik


/Magnus

and in the prebuilt case, it's the responsibility of 
RunTestPrebuilt.gmk to adjust things for the lack of a proper 
spec.gmk and in RunTestPrebuilt.gmk we already check that 
JDK_IMAGE_DIR points to an existing directory.


/Erik


/Magnus


28 jan. 2019 kl. 18:47 skrev Erik Joelsson :

Hello Shura,

In RunTest.gmk, you removed the conditional, but the comment still 
implies that it's there. Please update the comment. Otherwise this 
looks good!


/Erik


On 2019-01-25 15:20, Alexandre (Shura) Iline wrote:
Hi,

Please take a look on a change to allow JCov test execution 
through jib.


Please notice that this fix also changes behavior of RunTest.gmk 
when conflicting combination of options is used. JCOV_IMAGE_DIR  
is now expected to be set when TEST_OPTS_JCOV is true.


Shura

Bug: https://bugs.openjdk.java.net/browse/JDK-8217761
Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/

Re: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails

[Erik Joelsson]

Hello,

On 2019-01-30 01:51, Magnus Ihse Bursie wrote:

On 2019-01-30 02:18, Erik Joelsson wrote:

Hello,

Some recent build failures reminded me of this issue and increased 
the need to fix it ASAP to be able to diagnose them. 
GenerateLinkOptData.gmk runs a java tool to generate data which is 
later used to optimize the JDK image with jlink. The problem here is 
that the tool needs to print some of that data on stdout, which the 
build captures as one build artifact, and will print some "garbage" 
on stderr if things go well. So currently we just hide all that 
output from the build log. Because of this, if something goes wrong, 
we won't see the error.


This patch tries to capture the stderr output and only print it 
(along with stdout) if the java command fails.


Bug: https://bugs.openjdk.java.net/browse/JDK-8204564

Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/


Good idea, but could you please include some more information in the 
case of failure? The classlist data generation gets a lot of blame 
when the real cause is that the JDK is stillborn.


Something like:

    || ( exitcode=$$? && $(ECHO) "ERROR: Classlist file 
generation failed. This is typically a sign that the newly built JDK 
is broken, and not of an error in the Classlist generation." && 
$(ECHO) "Classlist stderr: " &&
$(CAT) $(LINK_OPT_DIR)/stderr && $(ECHO) "Classlist trace file:" && 
$(CAT) $(JLI_TRACE_FILE) \

 && exit $$exitcode )

but with better line breaks :)

Sure, but please note that this is not the first time we are running the 
newly built JVM in the build. To run the classlist generation, we must 
first create a couple of jmods and jlink them together into the interim 
image, so the newly built JVM/JDK cannot be completely broken for this 
to happen.


/Erik


/Magnus


/Erik

Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX

[Andrew Leonard]

Thanks David,
I just found the reference you mention, it is a little vague, but says 
maybe as you said. I've reworked and tested the following which seems 
better:
  NUM_CORES=`lparstat -m | grep -o "lcpu=[[0-9]]*" | cut -d "=" -f 2`
I'll create a new webrev with this.
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   David Holmes 
To: Erik Joelsson , Andrew Leonard 
, build-dev@openjdk.java.net
Date:   30/01/2019 02:25
Subject:Re: Proposal: JDK-8217896: Make better use of LCPUs when 
building on AIX



On 30/01/2019 3:05 am, Erik Joelsson wrote:
> Hello,
> 
> I'm OK with this, but since I can't verify it at all, I would be more 
> comfortable if one of the other AIX users would review this as well.

Ditto. I did some googling on this and pmcycles is flagged as maybe 
being deprecated in the future and may require privileges to execute. 
lparstat -i seems to be more commonly used.

David
-

> /Erik
> 
> On 2019-01-29 05:08, Andrew Leonard wrote:
>> Hi,
>> Please can I get a sponsor for this build performance enhancement on 
AIX,
>> by better determining the number of LCPUs on smt AIX machines:
>>  
https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.java.net_-7Ealeonard_8217896_webrev.00_=DwIDaQ=jf_iaSHvJObTbx-siA1ZOg=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ=FpNeQfFJBut0AAVlbC0w7o0urDCArfDb4PY1TtMVW4I=8vmPiiNU5P6MnXKdE-eyyBm48kgCssjH5VyWHAt5zcM=

>> My testing shows up to 30% improved build times when leveraging the
>> available LCPUs.
>> Many thanks
>> Andrew
>>
>> Andrew Leonard
>> Java Runtimes Development
>> IBM Hursley
>> IBM United Kingdom Ltd
>> Phone internal: 245913, external: 01962 815913
>> internet email: andrew_m_leon...@uk.ibm.com
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with 
number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
>> 3AU





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFR JDK-8217761: Enhance run-test-prebuilt jib profile to support running tests with JCov

[Magnus Ihse Bursie]

On 2019-01-29 17:55, Erik Joelsson wrote:

Hello,

On 2019-01-29 03:12, Magnus Ihse Bursie wrote:
If you are going down this road, you'll need to verify that 
JCOV_IMAGE_DIR is not empty in RunTests. So keep the ifneq statement, 
but with an $(error ...) instead. Otherwise we'll just fail 
spectacularly and incomprehensible later on.


This has already gone in with my blessing, but to address your concern.

I don't see why we need to check that it's set in RunTest.gmk? In the 
local case, we set JCOV_IMAGE_DIR in spec.gmk so it's guaranteed to be 
set, 


... but only if we configure with --with-jcov.

I'd just like the system to present a comprehensible error message if 
the user does something like this: "make test TEST=tier1 
TEST_OPTS=JCOV=true", but has not configured using --with-jcov. Prior to 
this patch, we ran the tests but without coverage. This is probably not 
what was intended, but it didn't crash. Now we're going to get a 
malformed command line.


"Error: Unable to access jarfile /lib/jcov.jar" is not a very helpful 
error message.


When I test now, something is odd with the "jcov-image" target as well. 
Even if you have not run configure with --with-jcov, the target 
seemingly runs and succeeds, but no jcov image is generated. Expected 
behavior would be an error message stating that you need to use --with-jcov.


/Magnus

and in the prebuilt case, it's the responsibility of 
RunTestPrebuilt.gmk to adjust things for the lack of a proper spec.gmk 
and in RunTestPrebuilt.gmk we already check that JDK_IMAGE_DIR points 
to an existing directory.


/Erik


/Magnus


28 jan. 2019 kl. 18:47 skrev Erik Joelsson :

Hello Shura,

In RunTest.gmk, you removed the conditional, but the comment still 
implies that it's there. Please update the comment. Otherwise this 
looks good!


/Erik


On 2019-01-25 15:20, Alexandre (Shura) Iline wrote:
Hi,

Please take a look on a change to allow JCov test execution through 
jib.


Please notice that this fix also changes behavior of RunTest.gmk 
when conflicting combination of options is used. JCOV_IMAGE_DIR  is 
now expected to be set when TEST_OPTS_JCOV is true.


Shura

Bug: https://bugs.openjdk.java.net/browse/JDK-8217761
Webrev: http://cr.openjdk.java.net/~shurailine/8217761/webrev.02/

Re: RFR: JDK-8217916: Build compare script is not comparing jmods

[Magnus Ihse Bursie]

On 2019-01-29 01:34, Erik Joelsson wrote:
This patch enhances the build compare script to also look at the jmod 
files in the JDK image. This was triggered by JDK-8217826 (linked in 
issue) where we see a rare intermittent comparison failure on Windows 
when looking at file types. That seems to be caused by the file 
command not knowing about jmod files (at least not the versions of the 
command we have).


With this patch, I'm filtering out .jmod files from the file type 
comparison since it seems pointless. Instead I use the jmod tool to 
list the contents of each jmod file and verify that they contain the 
same file names. I don't think there is a point to comparing the 
contents of those files since all the same files will be in the JDK 
image and will be compared anyway. Doing it again would be a waste of 
time.


Tested manually introducing differences and running the script, as 
well as running the build with COMPARE_BUILD=PATCH= on all relevant 
platforms.


Bug: https://bugs.openjdk.java.net/browse/JDK-8217916

Webrev: http://cr.openjdk.java.net/~erikj/8217916/webrev.01/index.html

Looks good to me.

/Magnus


/Erik

Re: RFR : [XS] 8218046: use bundled freetype in the AIX build by default

[Magnus Ihse Bursie]

On 2019-01-30 14:59, Baesken, Matthias wrote:

Thanks Magnus !

May I get a second review please ?

For build changes a second reviewer is not needed; that's a hotspot rule.

/Magnus


Best regards, Matthias



-Original Message-
From: Magnus Ihse Bursie 
Sent: Mittwoch, 30. Januar 2019 14:42
To: Baesken, Matthias ; 'build-
d...@openjdk.java.net' 
Subject: Re: RFR : [XS] 8218046: use bundled freetype in the AIX build by
default

On 2019-01-30 11:08, Baesken, Matthias wrote:

Hello, please review this small  change .

It adjusts  the freetype default on AIX  to  "bundled"(means : use the

bundled freetype  if not configured otherwise) .


Currently only windows and macosx use the bundled freetype, the other

platforms by default use the system freetype (see lib-freetype.m4).

AIX would benefit from using the bundled as well, because even when

freetype is installed on the system configure runs sometimes into detection
issues.



Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8218046

http://cr.openjdk.java.net/~mbaesken/webrevs/8218046.0/

Looks good to me.

/Magnus


Best regards,
 Matthias

RE: RFR : [XS] 8218046: use bundled freetype in the AIX build by default

[Baesken, Matthias]

Thanks Magnus !

May I get a second review please ?

Best regards, Matthias


> -Original Message-
> From: Magnus Ihse Bursie 
> Sent: Mittwoch, 30. Januar 2019 14:42
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' 
> Subject: Re: RFR : [XS] 8218046: use bundled freetype in the AIX build by
> default
> 
> On 2019-01-30 11:08, Baesken, Matthias wrote:
> > Hello, please review this small  change .
> >
> > It adjusts  the freetype default on AIX  to  "bundled"(means : use the
> bundled freetype  if not configured otherwise) .
> >
> >
> > Currently only windows and macosx use the bundled freetype, the other
> platforms by default use the system freetype (see lib-freetype.m4).
> > AIX would benefit from using the bundled as well, because even when
> freetype is installed on the system configure runs sometimes into detection
> issues.
> >
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8218046
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8218046.0/
> Looks good to me.
> 
> /Magnus
> >
> >
> > Best regards,
> > Matthias

Re: RFR : [XS] 8218046: use bundled freetype in the AIX build by default

[Magnus Ihse Bursie]

On 2019-01-30 11:08, Baesken, Matthias wrote:

Hello, please review this small  change .

It adjusts  the freetype default on AIX  to  "bundled"(means : use the 
bundled freetype  if not configured otherwise) .


Currently only windows and macosx use the bundled freetype, the other platforms 
by default use the system freetype (see lib-freetype.m4).
AIX would benefit from using the bundled as well, because even when freetype is 
installed on the system configure runs sometimes into detection issues.



Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8218046

http://cr.openjdk.java.net/~mbaesken/webrevs/8218046.0/

Looks good to me.

/Magnus



Best regards,
Matthias

RFR: JDK-8218057 Add ppc64le and s390x profiles to jib-profiles.js

[Magnus Ihse Bursie]

With Volker's fix in JDK-8213698, creating devkits for cross-compiling 
on linux to various other platforms was made trivial.


This patch uses this functionality to add new cross-compilation targets 
for ppc64le and s390x to jib-profiles.js


As usual; this implies no commitment from Oracle to neither build nor 
test on these platforms.


Bug: https://bugs.openjdk.java.net/browse/JDK-8218057
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8218057-add-ppc64le-and-s390x-devkits/webrev.01


/Magnus

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Andrew Watkins]

Thanks worked like a dream!

For reference to build on Solaris 11.4

# export 
PATH=/usr/local/openjdk/jdk11/bin:/opt/solarisstudio12.4/bin:/usr/bin:/usr/sbin:/usr/gnu/bin:/usr/sfw/bin

# hg clone http://hg.openjdk.java.net/jdk/jdk12
# bash configure  --prefix=/usr/local/openjdk/jdk12 
--with-devkit=/home/andrew/src/openjdk/jdk12/build/devkit 
--disable-hotspot-gtest --with-jvm-features=-shenandoahgc,-dtrace

# gmake
# gmake images

Cheers,

Andrew



On 01/30/19 09:35 AM, Ao Qi wrote:

Hi Andrew Watkins,

jdk12 can be built on Solaris 11.4 x86 solarisstudio12.4, but it needs
a EM_486 patch, and configure with --disable-hotspot-gtest
--with-jvm-features=-shenandoahgc,-dtrace

Cheers,
Ao Qi

On Wed, Jan 30, 2019 at 5:10 PM Andrew Watkins  wrote:



On 01/18/19 05:23 PM, Erik Joelsson wrote:

.

You could try the open/make/devkit/createSolarisDevkit12.4.sh script
and see if that helps you build something that works better. That's
what we use at Oracle.

/Erik

Is there any hope of getting OpenJDK 12 to build on the Free download
of  Solaris Studio 12.4 or 12.6, since for us Oracle Solaris 11 x86_64
shops we are unable to get Java 12 or above with out it.

OpenJDK 12 requires latest versions of solarisstudio-124 or
developerstudio-126

Of course this would not be a problem if Oracle supplied us with Solaris
11 x86_64 Java 11 or 12 and not just the SPARC version.

Cheers,

Andrew

--
Andrew Watkins * Birkbeck, University of London * Computer Science *
* http://notallmicrosoft.blogspot.com *
* UKOUG Systems SIG Chair *
* UKOUG Tech committee *
* tel: 020 7631 6720 *

::e-mails are only read & actioned between 0900 and 1800 hours (Monday - Friday)



--
Andrew Watkins * Birkbeck, University of London * Computer Science *
* http://notallmicrosoft.blogspot.com *
* UKOUG Systems SIG Chair *
* UKOUG Tech committee *
* tel: 020 7631 6720 *

::e-mails are only read & actioned between 0900 and 1800 hours (Monday - Friday)

RFR : [XS] 8218046: use bundled freetype in the AIX build by default

[Baesken, Matthias]

Hello, please review this small  change .

It adjusts  the freetype default on AIX  to  "bundled"(means : use the 
bundled freetype  if not configured otherwise) .


Currently only windows and macosx use the bundled freetype, the other platforms 
by default use the system freetype (see lib-freetype.m4).
AIX would benefit from using the bundled as well, because even when freetype is 
installed on the system configure runs sometimes into detection issues.



Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8218046

http://cr.openjdk.java.net/~mbaesken/webrevs/8218046.0/


Best regards,
   Matthias

Re: RFR: JDK-8204564: Need better error output when GenerateLinkOptData fails

[Magnus Ihse Bursie]

On 2019-01-30 02:18, Erik Joelsson wrote:

Hello,

Some recent build failures reminded me of this issue and increased the 
need to fix it ASAP to be able to diagnose them. 
GenerateLinkOptData.gmk runs a java tool to generate data which is 
later used to optimize the JDK image with jlink. The problem here is 
that the tool needs to print some of that data on stdout, which the 
build captures as one build artifact, and will print some "garbage" on 
stderr if things go well. So currently we just hide all that output 
from the build log. Because of this, if something goes wrong, we won't 
see the error.


This patch tries to capture the stderr output and only print it (along 
with stdout) if the java command fails.


Bug: https://bugs.openjdk.java.net/browse/JDK-8204564

Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/


Good idea, but could you please include some more information in the 
case of failure? The classlist data generation gets a lot of blame when 
the real cause is that the JDK is stillborn.


Something like:

    || ( exitcode=$$? && $(ECHO) "ERROR: Classlist file 
generation failed. This is typically a sign that the newly built JDK is 
broken, and not of an error in the Classlist generation." && $(ECHO) 
"Classlist stderr: " &&
$(CAT) $(LINK_OPT_DIR)/stderr && $(ECHO) "Classlist trace file:" && 
$(CAT) $(JLI_TRACE_FILE) \

 && exit $$exitcode )

but with better line breaks :)

/Magnus


/Erik

Re: Proposal: JDK-8217896: Make better use of LCPUs when building on AIX

[Magnus Ihse Bursie]

On 2019-01-29 18:05, Erik Joelsson wrote:

Hello,

I'm OK with this, but since I can't verify it at all, I would be more 
comfortable if one of the other AIX users would review this as well.
I'm also a bit surprised by the "wc -l | awk '{print $1}" construct. The 
point of sending -l to wc is to only get the line number count as 
output, yes? So why the awk part then?


/Magnus


/Erik

On 2019-01-29 05:08, Andrew Leonard wrote:

Hi,
Please can I get a sponsor for this build performance enhancement on 
AIX,

by better determining the number of LCPUs on smt AIX machines:
 https://cr.openjdk.java.net/~aleonard/8217896/webrev.00/
My testing shows up to 30% improved build times when leveraging the
available LCPUs.
Many thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Ao Qi]

Hi Andrew Watkins,

jdk12 can be built on Solaris 11.4 x86 solarisstudio12.4, but it needs
a EM_486 patch, and configure with --disable-hotspot-gtest
--with-jvm-features=-shenandoahgc,-dtrace

Cheers,
Ao Qi

On Wed, Jan 30, 2019 at 5:10 PM Andrew Watkins  wrote:
>
>
>
> On 01/18/19 05:23 PM, Erik Joelsson wrote:
> > .
> >
> > You could try the open/make/devkit/createSolarisDevkit12.4.sh script
> > and see if that helps you build something that works better. That's
> > what we use at Oracle.
> >
> > /Erik
>
> Is there any hope of getting OpenJDK 12 to build on the Free download
> of  Solaris Studio 12.4 or 12.6, since for us Oracle Solaris 11 x86_64
> shops we are unable to get Java 12 or above with out it.
>
> OpenJDK 12 requires latest versions of solarisstudio-124 or
> developerstudio-126
>
> Of course this would not be a problem if Oracle supplied us with Solaris
> 11 x86_64 Java 11 or 12 and not just the SPARC version.
>
> Cheers,
>
> Andrew
>
> --
> Andrew Watkins * Birkbeck, University of London * Computer Science *
> * http://notallmicrosoft.blogspot.com *
> * UKOUG Systems SIG Chair *
> * UKOUG Tech committee *
> * tel: 020 7631 6720 *
>
> ::e-mails are only read & actioned between 0900 and 1800 hours (Monday - 
> Friday)
>

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Ao Qi]

Hi Rob,

If I recall it correctly, maybe configure with --disable-hotspot-gtest
can solve your problem.

Cheer,
Ao Qi

On Fri, Jan 18, 2019 at 5:57 AM Rob Petti  wrote:
>
> Hey Folks,
>
> I've discovered that OpenJDK 11 cannot be built on Solaris 11.4. Normally
> we would just try to rebuild our system as 11.1, but that's not possible
> since media for that base release is no longer available.
>
> Are there plans to support compilation on Oracle's latest and greatest, or
> at least provide a proper method of building in such an environment?
>
> For the record, here are the errors I'm getting. This is with solarisstudio
> 12.4 (which BTW wouldn't install on Solaris 11.4 without unfreezing the
> python version):
>
> # bash configure --with-boot-jdk=
> --with-devkit=/opt/solarisstudio12.4
> # gmake bootcycle-images
> ...
> Compiling 163 files for jdk.jfr
> "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1580:
> Error: EM_486 is not defined.
> "/root/jdk11/jdk11u/src/hotspot/os/solaris/os_solaris.cpp", line 1618:
> Error: The type "const arch_t[]" is incomplete.
> 2 Error(s) detected.
> gmake[3]: *** [lib/CompileJvm.gmk:151:
> /root/jdk11/jdk11u/build/solaris-sparcv9-normal-server-release/hotspot/variant-server/libjvm/objs/os_solaris.o]
> Error 2
>
> After patching with http://robpetti.com/files/jdk11-sol114.patch to fix
> https://bugs.openjdk.java.net/browse/JDK-8182035, it gets a bit further,
> but still fails:
>
> Compiling 64 files for jdk.jconsole
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 161: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 163: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 165: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 165: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 167: Error: __pad is not a member of const __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 170: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 170: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 172: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 172: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 174: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 174: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 176: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 176: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 178: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 178: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 182: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 183: Error: __pad is not a member of __FILE.
> "/opt/solarisstudio12.4/lib/compilers/include/CC/stlport4/stl/_stdio_file.h",
> line 184: Error: __pad is not a member of __FILE.
> 18 Error(s) detected.
>
> It seems the "right" way to do this would be to create a sysroot with older
> 11.1 headers and libraries, and compile against that. Unfortunately the
> --with-sysroot configure option does not completely work correctly. The
> compiler still tries to include /usr/include instead of the sysroot
> headers, and that just results in more build errors. The only way it seems
> to truly get it to use the sysroot was to physically replace /usr/include
> on the machine with the version from the sysroot. This is obviously less
> than ideal.
>
> Is the --with-sysroot issue already known? Is there any other way around it
> aside from manually replacing headers in the system just to compile the JDK?
>
> --
> 
> Rob Petti
> about.me/robpetti
> 

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Andrew Watkins]

On 01/18/19 05:23 PM, Erik Joelsson wrote:

.

You could try the open/make/devkit/createSolarisDevkit12.4.sh script 
and see if that helps you build something that works better. That's 
what we use at Oracle.


/Erik


Is there any hope of getting OpenJDK 12 to build on the Free download 
of  Solaris Studio 12.4 or 12.6, since for us Oracle Solaris 11 x86_64 
shops we are unable to get Java 12 or above with out it.


OpenJDK 12 requires latest versions of solarisstudio-124 or 
developerstudio-126


Of course this would not be a problem if Oracle supplied us with Solaris 
11 x86_64 Java 11 or 12 and not just the SPARC version.


Cheers,

Andrew

--
Andrew Watkins * Birkbeck, University of London * Computer Science *
* http://notallmicrosoft.blogspot.com *
* UKOUG Systems SIG Chair *
* UKOUG Tech committee *
* tel: 020 7631 6720 *

::e-mails are only read & actioned between 0900 and 1800 hours (Monday - Friday)