Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled

[Vladimir Kozlov]

+1

Thanks
Vladimir

> On Jan 18, 2019, at 5:29 PM, Igor Ignatev  wrote:
> 
> Still looks good to me. 
> 
> — Igor
> 
>> On Jan 18, 2019, at 5:26 PM, Vladimir Ivanov  
>> wrote:
>> 
>> Updated webrev:
>> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.01
>> 
>> Verified that it works as expected on Linux, Windows, MacOS, and Solaris.
>> 
>> Best regards,
>> Vladimir Ivanov
>> 
 On 18/01/2019 16:39, Vladimir Ivanov wrote:
 Thanks, Igor.
 overall your fix looks reasonable, but w/ it we can get unintentionally 
 disabled features (b/c grep doesn't do full word match). although this 
 problem wasn't really introduced by your fix, I think it's be better to 
 fix it as a part of your patch. I see two possible solutions:
>>> I was aware of such drawback, but decided to leave it as is, since it 
>>> doesn't affect existing features.
  -  add "-w" to grep, but I am not sure if "-w" is supported by all grep 
 implementations
  - use $XARGS instead of $ECHO when we get DISABLE_X. in this case you 
 will need to revert your changes in 'if test ...' lines
>>> I'm in favor of using "-w" and I see different grep flags being used 
>>> already, but would like somebody from Build team confirm they are OK with 
>>> such solution.
>>> Best regards,
>>> Vladimir Ivanov
> On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov 
>  wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8217404
> 
> --with-jvm-features doesn't work properly when multiple features are 
> explicitly disabled:
> 
> $ bash configure --with-jvm-features="-aot -jvmci -graal"
> ...
> checking if jvmci module jdk.internal.vm.ci should be built... yes
> checking if graal module jdk.internal.vm.compiler should be built... yes
> checking if aot should be enabled... yes
> ...
> 
> The problem in the following code:
> 
>  DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
>  if test "x$DISABLE_AOT" = "xaot"; then
>ENABLE_AOT="false"
>  fi
> 
> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of 
> explicitly disabled features, grep over it returns the whole list when 
> there's a match. The subsequent check fails because there's no exact 
> match, though DISABLE_AOT contains "aot" .
> 
> Proposed fix is to check there's no match instead.
> 
> After the fix it works as expected:
> 
> $ bash configure --with-jvm-features="-aot -jvmci -graal"
> ...
> checking if jvmci module jdk.internal.vm.ci should be built... no, forced
> checking if graal module jdk.internal.vm.compiler should be built... no, 
> forced
> checking if aot should be enabled... no, forced
> ...
> 
> (The fix doesn't address the case when one feature has a name which is a 
> proper substring of another feature, but there are no such cases at the 
> moment.)
> 
> Best regards,
> Vladimir Ivanov
 
> 

Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled

[Igor Ignatev]

Still looks good to me. 

— Igor

> On Jan 18, 2019, at 5:26 PM, Vladimir Ivanov  
> wrote:
> 
> Updated webrev:
>  http://cr.openjdk.java.net/~vlivanov/8217404/webrev.01
> 
> Verified that it works as expected on Linux, Windows, MacOS, and Solaris.
> 
> Best regards,
> Vladimir Ivanov
> 
>> On 18/01/2019 16:39, Vladimir Ivanov wrote:
>> Thanks, Igor.
>>> overall your fix looks reasonable, but w/ it we can get unintentionally 
>>> disabled features (b/c grep doesn't do full word match). although this 
>>> problem wasn't really introduced by your fix, I think it's be better to fix 
>>> it as a part of your patch. I see two possible solutions:
>> I was aware of such drawback, but decided to leave it as is, since it 
>> doesn't affect existing features.
>>>   -  add "-w" to grep, but I am not sure if "-w" is supported by all grep 
>>> implementations
>>>   - use $XARGS instead of $ECHO when we get DISABLE_X. in this case you 
>>> will need to revert your changes in 'if test ...' lines
>> I'm in favor of using "-w" and I see different grep flags being used 
>> already, but would like somebody from Build team confirm they are OK with 
>> such solution.
>> Best regards,
>> Vladimir Ivanov
 On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov 
  wrote:
 
 http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
 https://bugs.openjdk.java.net/browse/JDK-8217404
 
 --with-jvm-features doesn't work properly when multiple features are 
 explicitly disabled:
 
 $ bash configure --with-jvm-features="-aot -jvmci -graal"
 ...
 checking if jvmci module jdk.internal.vm.ci should be built... yes
 checking if graal module jdk.internal.vm.compiler should be built... yes
 checking if aot should be enabled... yes
 ...
 
 The problem in the following code:
 
   DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
   if test "x$DISABLE_AOT" = "xaot"; then
 ENABLE_AOT="false"
   fi
 
 Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of 
 explicitly disabled features, grep over it returns the whole list when 
 there's a match. The subsequent check fails because there's no exact 
 match, though DISABLE_AOT contains "aot" .
 
 Proposed fix is to check there's no match instead.
 
 After the fix it works as expected:
 
 $ bash configure --with-jvm-features="-aot -jvmci -graal"
 ...
 checking if jvmci module jdk.internal.vm.ci should be built... no, forced
 checking if graal module jdk.internal.vm.compiler should be built... no, 
 forced
 checking if aot should be enabled... no, forced
 ...
 
 (The fix doesn't address the case when one feature has a name which is a 
 proper substring of another feature, but there are no such cases at the 
 moment.)
 
 Best regards,
 Vladimir Ivanov
>>> 

Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled

[Vladimir Ivanov]

Updated webrev:
  http://cr.openjdk.java.net/~vlivanov/8217404/webrev.01

Verified that it works as expected on Linux, Windows, MacOS, and Solaris.

Best regards,
Vladimir Ivanov

On 18/01/2019 16:39, Vladimir Ivanov wrote:

Thanks, Igor.

overall your fix looks reasonable, but w/ it we can get 
unintentionally disabled features (b/c grep doesn't do full word 
match). although this problem wasn't really introduced by your fix, I 
think it's be better to fix it as a part of your patch. I see two 
possible solutions:


I was aware of such drawback, but decided to leave it as is, since it 
doesn't affect existing features.


  -  add "-w" to grep, but I am not sure if "-w" is supported by all 
grep implementations
  - use $XARGS instead of $ECHO when we get DISABLE_X. in this case 
you will need to revert your changes in 'if test ...' lines


I'm in favor of using "-w" and I see different grep flags being used 
already, but would like somebody from Build team confirm they are OK 
with such solution.


Best regards,
Vladimir Ivanov

On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov 
 wrote:


http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404

--with-jvm-features doesn't work properly when multiple features are 
explicitly disabled:


$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...

The problem in the following code:

  DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
  if test "x$DISABLE_AOT" = "xaot"; then
    ENABLE_AOT="false"
  fi

Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of 
explicitly disabled features, grep over it returns the whole list 
when there's a match. The subsequent check fails because there's no 
exact match, though DISABLE_AOT contains "aot" .


Proposed fix is to check there's no match instead.

After the fix it works as expected:

$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no, 
forced
checking if graal module jdk.internal.vm.compiler should be built... 
no, forced

checking if aot should be enabled... no, forced
...

(The fix doesn't address the case when one feature has a name which 
is a proper substring of another feature, but there are no such cases 
at the moment.)


Best regards,
Vladimir Ivanov

Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled

[Vladimir Ivanov]

Thanks, Igor.


overall your fix looks reasonable, but w/ it we can get unintentionally 
disabled features (b/c grep doesn't do full word match). although this problem 
wasn't really introduced by your fix, I think it's be better to fix it as a 
part of your patch. I see two possible solutions:


I was aware of such drawback, but decided to leave it as is, since it 
doesn't affect existing features.



  -  add "-w" to grep, but I am not sure if "-w" is supported by all grep 
implementations
  - use $XARGS instead of $ECHO when we get DISABLE_X. in this case you will 
need to revert your changes in 'if test ...' lines


I'm in favor of using "-w" and I see different grep flags being used 
already, but would like somebody from Build team confirm they are OK 
with such solution.


Best regards,
Vladimir Ivanov


On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov  
wrote:

http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404

--with-jvm-features doesn't work properly when multiple features are explicitly 
disabled:

$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...

The problem in the following code:

  DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
  if test "x$DISABLE_AOT" = "xaot"; then
ENABLE_AOT="false"
  fi

Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled 
features, grep over it returns the whole list when there's a match. The subsequent check fails 
because there's no exact match, though DISABLE_AOT contains "aot" .

Proposed fix is to check there's no match instead.

After the fix it works as expected:

$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no, forced
checking if graal module jdk.internal.vm.compiler should be built... no, forced
checking if aot should be enabled... no, forced
...

(The fix doesn't address the case when one feature has a name which is a proper 
substring of another feature, but there are no such cases at the moment.)

Best regards,
Vladimir Ivanov

Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled

[Vladimir Ivanov]

Thanks, Vladimir.


I usually used --with-jvm-features=-aot,-jvmci,-graal

Did not work in this case too?


I didn't know it supports comma-separated list, but it doesn't work as 
well:


$ bash configure --with-jvm-features="-aot,-jvmci,-graal"

checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes

Best regards,
Vladimir Ivanov


On 1/18/19 3:33 PM, Vladimir Ivanov wrote:

http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404

--with-jvm-features doesn't work properly when multiple features are 
explicitly disabled:


$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...

The problem in the following code:

   DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
   if test "x$DISABLE_AOT" = "xaot"; then
 ENABLE_AOT="false"
   fi

Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of 
explicitly disabled features, grep over it returns the whole list when 
there's a match. The subsequent check fails because there's no exact 
match, though DISABLE_AOT contains "aot" .


Proposed fix is to check there's no match instead.

After the fix it works as expected:

$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no, forced
checking if graal module jdk.internal.vm.compiler should be built... 
no, forced

checking if aot should be enabled... no, forced
...

(The fix doesn't address the case when one feature has a name which is 
a proper substring of another feature, but there are no such cases at 
the moment.)


Best regards,
Vladimir Ivanov

Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled

[Igor Ignatyev]

Hi Vladimir,

overall your fix looks reasonable, but w/ it we can get unintentionally 
disabled features (b/c grep doesn't do full word match). although this problem 
wasn't really introduced by your fix, I think it's be better to fix it as a 
part of your patch. I see two possible solutions:
 -  add "-w" to grep, but I am not sure if "-w" is supported by all grep 
implementations
 - use $XARGS instead of $ECHO when we get DISABLE_X. in this case you will 
need to revert your changes in 'if test ...' lines

Thanks,
-- Igor

> On Jan 18, 2019, at 3:33 PM, Vladimir Ivanov  
> wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8217404
> 
> --with-jvm-features doesn't work properly when multiple features are 
> explicitly disabled:
> 
> $ bash configure --with-jvm-features="-aot -jvmci -graal"
> ...
> checking if jvmci module jdk.internal.vm.ci should be built... yes
> checking if graal module jdk.internal.vm.compiler should be built... yes
> checking if aot should be enabled... yes
> ...
> 
> The problem in the following code:
> 
>  DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
>  if test "x$DISABLE_AOT" = "xaot"; then
>ENABLE_AOT="false"
>  fi
> 
> Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of 
> explicitly disabled features, grep over it returns the whole list when 
> there's a match. The subsequent check fails because there's no exact match, 
> though DISABLE_AOT contains "aot" .
> 
> Proposed fix is to check there's no match instead.
> 
> After the fix it works as expected:
> 
> $ bash configure --with-jvm-features="-aot -jvmci -graal"
> ...
> checking if jvmci module jdk.internal.vm.ci should be built... no, forced
> checking if graal module jdk.internal.vm.compiler should be built... no, 
> forced
> checking if aot should be enabled... no, forced
> ...
> 
> (The fix doesn't address the case when one feature has a name which is a 
> proper substring of another feature, but there are no such cases at the 
> moment.)
> 
> Best regards,
> Vladimir Ivanov

Re: [13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled

[Vladimir Kozlov]

I usually used --with-jvm-features=-aot,-jvmci,-graal

Did not work in this case too?

Anyway your fix is good.

Thanks,
Vladimir

On 1/18/19 3:33 PM, Vladimir Ivanov wrote:

http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404

--with-jvm-features doesn't work properly when multiple features are explicitly 
disabled:

$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...

The problem in the following code:

   DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
   if test "x$DISABLE_AOT" = "xaot"; then
     ENABLE_AOT="false"
   fi

Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of explicitly disabled features, grep over it returns 
the whole list when there's a match. The subsequent check fails because there's no exact match, though DISABLE_AOT 
contains "aot" .


Proposed fix is to check there's no match instead.

After the fix it works as expected:

$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no, forced
checking if graal module jdk.internal.vm.compiler should be built... no, forced
checking if aot should be enabled... no, forced
...

(The fix doesn't address the case when one feature has a name which is a proper substring of another feature, but there 
are no such cases at the moment.)


Best regards,
Vladimir Ivanov

[13] RFR (S): 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled

[Vladimir Ivanov]

http://cr.openjdk.java.net/~vlivanov/8217404/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8217404

--with-jvm-features doesn't work properly when multiple features are 
explicitly disabled:


$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... yes
checking if graal module jdk.internal.vm.compiler should be built... yes
checking if aot should be enabled... yes
...

The problem in the following code:

  DISABLE_AOT=`$ECHO $DISABLED_JVM_FEATURES | $GREP aot`
  if test "x$DISABLE_AOT" = "xaot"; then
ENABLE_AOT="false"
  fi

Since DISABLED_JVM_FEATURES ("aot jvmci graal") contains the list of 
explicitly disabled features, grep over it returns the whole list when 
there's a match. The subsequent check fails because there's no exact 
match, though DISABLE_AOT contains "aot" .


Proposed fix is to check there's no match instead.

After the fix it works as expected:

$ bash configure --with-jvm-features="-aot -jvmci -graal"
...
checking if jvmci module jdk.internal.vm.ci should be built... no, forced
checking if graal module jdk.internal.vm.compiler should be built... no, 
forced

checking if aot should be enabled... no, forced
...

(The fix doesn't address the case when one feature has a name which is a 
proper substring of another feature, but there are no such cases at the 
moment.)


Best regards,
Vladimir Ivanov

RFR 8217357: Implement JCov jib profiles

[Alexandre (Shura) Iline]

Hi.

Please take a look on a change which is adding new jib profiles to support make 
changes introduced by JDK-8214309.

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

Thank you.

Shura

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Erik Joelsson]

On 2019-01-18 10:17, Rob Petti wrote:

Thanks, Erik!

I tried the createSolarisDevkit12.4.sh 
 script, but none of the packages 
in that list exist in the package manager at those specific versions, 
so it just fails. I basically had to make my own list of packages from 
scratch using the existing one as a guideline.


Zones sound like a cleaner solution to me, but I don't know enough 
about them to know how to install a specific base OS version. All the 
docs I find just install the same version as the 'host'. I'll need to 
do a bunch more research, it seems...


I know there is a difference between zones running the same OS version 
and those that run a different. I believe you need what's called a 
kernel zone to run a different version.


/Erik

On Fri, Jan 18, 2019 at 5:17 PM Erik Joelsson 
mailto:erik.joels...@oracle.com>> wrote:


Hello Rob,

On 2019-01-17 13:57, 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?

I can't speak for all OpenJDK contributors, but Oracle has no current
plans for this. We are required to build on the oldest supported
Solaris
version to produce binaries that are compatible with that version.
We do
not produce different binaries for different versions of an OS.
Also, as
I understand it, Oracle is no longer involved in open support of 11u.
Perhaps the new maintainer will accept contributions for fixing
the issue.

> 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.
>

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Rob Petti]

Thanks, Erik!

I tried the createSolarisDevkit12.4.sh script, but none of the packages in
that list exist in the package manager at those specific versions, so it
just fails. I basically had to make my own list of packages from scratch
using the existing one as a guideline.

Zones sound like a cleaner solution to me, but I don't know enough about
them to know how to install a specific base OS version. All the docs I find
just install the same version as the 'host'. I'll need to do a bunch more
research, it seems...

On Fri, Jan 18, 2019 at 5:17 PM Erik Joelsson 
wrote:

> Hello Rob,
>
> On 2019-01-17 13:57, 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?
>
> I can't speak for all OpenJDK contributors, but Oracle has no current
> plans for this. We are required to build on the oldest supported Solaris
> version to produce binaries that are compatible with that version. We do
> not produce different binaries for different versions of an OS. Also, as
> I understand it, Oracle is no longer involved in open support of 11u.
> Perhaps the new maintainer will accept contributions for fixing the issue.
>
> > 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) 

Re: OpenJDK 11.0.2 cannot build on Solaris 11.4

[Erik Joelsson]

Hello Rob,

On 2019-01-17 13:57, 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?


I can't speak for all OpenJDK contributors, but Oracle has no current 
plans for this. We are required to build on the oldest supported Solaris 
version to produce binaries that are compatible with that version. We do 
not produce different binaries for different versions of an OS. Also, as 
I understand it, Oracle is no longer involved in open support of 11u. 
Perhaps the new maintainer will accept contributions for fixing the issue.



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.
We have tried to get sysroot working on Solaris, and we are using it 
internally, against the recommendation of the Solaris team. It's not 
working perfectly though. According to the Solaris team, Solaris Studio 
does not support the concept of a sysroot. Their recommendation is to 
create zones with the OS version you need and build in those, which I 
find 

Re: RFR(13): JDK-8216263: Add historical data for JDK 12

[Jan Lahoda]

Adding build-dev.

Jan

On 17.1.2019 19:53, Jan Lahoda wrote:

On 17.1.2019 17:58, Jonathan Gibbons wrote:

Re:

   36 #   The checkout must not have any local changes that could
interfere with the new data. In particular,
   37 #   there must be absolutely no changed, new or removed files
under the ${JDK_CHECKOUT}/make/data/symbols
   38 #   directory.

That seems like a simple check that could be incorporated into the
script itself.

But, it also seems reasonable to separate enhancements like that from
the specific issue here, to add historical data for 12.


Ok. Sent as:
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012879.html


And limited this patch to the historical data only:
http://cr.openjdk.java.net/~jlahoda/8216263/webrev.03/

Thanks,
Jan



-- Jon

On 1/17/19 8:51 AM, Jan Lahoda wrote:

Hi Joe,

On 17.1.2019 02:13, Joseph D. Darcy wrote:

Hi Jan,

On 1/8/2019 2:13 AM, Jan Lahoda wrote:

Hi Joe,

Thanks for the comments, some responses inline. Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8216263/webrev.01/

On 7.1.2019 23:51, Joseph D. Darcy wrote:

Hi Jan,

On 1/7/2019 4:48 AM, Jan Lahoda wrote:

Hi,

To make --release 12 work, we need to add historical data for JDK
12.
The current historical data is based on:
$ javac  -fullversion
javac full version "12-ea+26"

We may need to update the data once JDK 12 is out to cover any
changes
to the APIs that might happen.

The patch also adds a simple (shell) script to generate the data, so
all that was needed to generate the data was:
$ cd make/data/symbols
$ sh generate-data 

JBS: https://bugs.openjdk.java.net/browse/JDK-8216263
Webrev: http://cr.openjdk.java.net/~jlahoda/8216263/webrev.00/

How does this look?


If the overhead is small enough and we don't mind a few updates to
the
JDK N+1 data, than perhaps the generation of this information
could be
included as part of the start of JDK N+1 activities.


That would be perfect!



I suggest a more extensive description of how to
make/data/symbols/generate-data. For example, this builds the data
for
the current release independent of whether or not the current release
has already had its data generated, correct?


Yes.



Concretely, if JDK N+1 has already forked, what is the proper way
to get
data for JDK N? Likewise, how should a re-build of the data for JDK
N be
done?


What exactly should be there? To the existing description:
# to generate (add) data for JDK N, do:
# cd make/data/symbols
# sh generate-data 

I've added (in .01):
# to regenerate the data for JDK N, run the above commands again

What more should be there?



I'd appreciate somewhere to have a textual discussion of how
make/data/symbols/symbols should be updated, the A = 10, B = 11, etc.
convention, what else need to be done to generate the contents of this
changeset.

The  is the contents of the build directory?

In general, a description of how the data of JDK N should be added to
JDK (N+1).


I've added more textual description to the script, an updated webrev
is here:
http://cr.openjdk.java.net/~jlahoda/8216263/webrev.02/

Jan



Thanks,

-Joe

Re: RFR: JDK-8217335: Add a script to generate --release data

[Jan Lahoda]

Hi Magnus,

Thanks for the comments, an updated webrev:
http://cr.openjdk.java.net/~jlahoda/8217335/webrev.01/

(Includes changes suggested by Joe was well).

Jan

On 18.1.2019 13:59, Magnus Ihse Bursie wrote:

On 2019-01-17 19:51, Jan Lahoda wrote:

Hi,

As suggested here:
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html


This is a separate patch that adds a script to generate --release N data.

Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8217335

Jan

Hi Jan,

I would recommend that you place the generate-data script in
make/scripts; it's the default location for scripts -- make/data is
reserved for, eh, data. :) But a bit more descriptive name would be
suitable when moving it away from make/data/symbols -- perhaps
generate-symbol-data?

Also, the update to the README file does not seem correct. I assume you
want to point to the new generate-data script, but the path is wrong
(even for the location in your current patch).

Finally, we in the build team always appreciates if you cc build-dev for
changes in the make directory, even if it's not strictly part of the
build system.

/Magnus

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

[Magnus Ihse Bursie]

On 2019-01-17 16:06, Andy Herrick wrote:


If I remove the line -nologo from lib-jdk.jpackage.gmk:


   69 LDFLAGS_windows := -nologo, \

I get the logo during build (same with console andnon-console version):

Microsoft (R) Incremental Linker Version 14.12.25835.0
Copyright (C) Microsoft Corporation.  All rights reserved.
do I need something to include CXXFLAGS_JDKEXE into LDFLAGS ? (there 
is no other LDFLAGS line...)

Ah, good catch. You should add
LDFLAGS := $(LDFLAGS_JDKEXE), \

to your setup.

/Magnus


here's the non-console APPLAUNCHERWEXE case:


# Build non-console version of launcher
ifeq ($(OPENJDK_TARGET_OS), windows)

  $(eval $(call SetupJdkExecutable, BUILD_JPACKAGE_APPLAUNCHERWEXE, \
  NAME := jpackageapplauncherw, \
  OUTPUT_DIR := 
$(JDK_OUTPUTDIR)/modules/$(MODULE)/jdk/jpackage/internal/resources, \
  SYMBOLS_DIR := 
$(SUPPORT_OUTPUTDIR)/native/$(MODULE)/jpackageapplauncherw, \

  SRC := $(JPACKAGE_APPLAUNCHEREXE_SRC), \
  TOOLCHAIN := TOOLCHAIN_LINK_CXX, \
  OPTIMIZATION := LOW, \
  CFLAGS := $(CXXFLAGS_JDKEXE), \
  CFLAGS_windows := -EHsc -DUNICODE -D_UNICODE, \
  LDFLAGS_windows := -nologo, \ 
<-

  LIBS := $(LIBCXX), \
  LIBS_windows :=  user32.lib shell32.lib advapi32.lib, \
  ))

  TARGETS += $(BUILD_JPACKAGE_APPLAUNCHERWEXE)
endif


/Andy


On 1/15/2019 8:09 AM, Magnus Ihse Bursie wrote:

Hi Andy,

This is looking really sweet from a build perspective!

Just a few minor nits:

* In Launcher-jdk.jpackage.gmk, please indent the else clause 
("$(eval $(call SetupBuildLauncher, jpackage ") two spaces.


* In Lib-jdk.jpackage.gmk, I think there's still room to prune some 
more unnecessary compiler flags and parameters to SetupJdkExecutable:

   65 CFLAGS_linux := -fPIC, \
   66 CFLAGS_solaris := -KPIC, \
   67 CFLAGS_macosx := -fPIC, \
 I wonder if these really are needed. Normally, only shared libraries 
neeed PIC code. (And for those we set it automatically.)


   69 LDFLAGS_windows := -nologo, \
This should not be needed, it's incorporated in CXXFLAGS_JDKEXE. 
(Also in the second block, for jpackageapplauncherw).


   72 LIBS_solaris :=  -lc, \
Same here; this should not be needed. It's in GLOBAL_LIBS on Solaris, 
and is always included.


   75 VERSIONINFO_RESOURCE := $(GLOBAL_VERSION_INFO_RESOURCE), \
This is setup by default by SetupJdkExecutable, so you can remove it. 
(Also in the second block, for jpackageapplauncherw).


Finally, I do believe that the setups of jpackageapplauncher and 
jpackageapplauncherw should be done in Launcher-jdk.jpackage.gmk, not 
Lib-jdk.jpackage.gmk. Since they are to be shipped as resources, they 
are not "really" launchers in our normal sense, but they are at least 
more launchers than they are libraries.


As we've talked about privately, in the future I'd like to see 
Windows too use the SetupBuildLauncher method for creating the 
launcher, but this is clearly good enough for inclusion in the mainline.


I also have a question about 
test/jdk/tools/jpackage/resources/license.txt. What is it used for? 
And why the odd (incorrect?) spelling of license?


/Magnus

On 2019-01-11 20:41, Andy Herrick wrote:
This is the second update to the Request For Review of the 
implementation of the Java Packager Tool (jpackager) as described in 
JEP 343: Packaging Tool 




This webrev corresponds to the second EA build, Build 8 (2019/1/8), 
posted at http://jdk.java.net/jpackage/


This update renames the package used to "jdk.jpackage", removes the 
Single Instance Service (and CLI option --singleton), adds several 
other CLI options, adds more automated tests, and contains fixes to 
the following issues (since update 1 on 11/09/2018):


JDK-8212164 resolve jre.list and jre.module.list
JDK-8212936 Makefile and other improvements for jpackager
JDK-8213385 jpackager Command-Line Argument File.
JDK-8213392 Enhance --help and --version
JDK-8213425 Analyze output from Source code scanner and fix 
where needed.

JDK-8213747 Makefile Improvements to Lib-jdk.packager.gmk
JDK-8213748 jpackager native launcher for macosx, linux.
JDK-8213756 SingleInstance runtime improvements
JDK-8213962 JPackageCreateImageRuntimeModuleTest fails
JDK-8213963 Flatten out jpackager packages and resources.
JDK-8214021 Create additional automated tests for jpackager
JDK-8214051 rename jpackager tool to jpackage
JDK-8214070 Analyze and Fix issues reported by Parfait
JDK-8214143 Reduce Resource files
JDK-8214495 Change behavior of --license-file
JDK-8214575 Exe installers will install application over 
existing installation
JDK-8214899 rename papplauncher and it's library and move src to 
appropriate places
JDK-8214982 jpackage causes failures in existing HelpFlagsTest 
and VersionCheck tests
JDK-8215020 create-jre-installer exe fails when --runtime-image 

Re: RFR: JDK-8217335: Add a script to generate --release data

[Magnus Ihse Bursie]

On 2019-01-17 19:51, Jan Lahoda wrote:

Hi,

As suggested here:
https://mail.openjdk.java.net/pipermail/compiler-dev/2019-January/012876.html 



This is a separate patch that adds a script to generate --release N data.

Webrev: http://cr.openjdk.java.net/~jlahoda/8217335/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8217335

Jan

Hi Jan,

I would recommend that you place the generate-data script in 
make/scripts; it's the default location for scripts -- make/data is 
reserved for, eh, data. :) But a bit more descriptive name would be 
suitable when moving it away from make/data/symbols -- perhaps 
generate-symbol-data?


Also, the update to the README file does not seem correct. I assume you 
want to point to the new generate-data script, but the path is wrong 
(even for the location in your current patch).


Finally, we in the build team always appreciates if you cc build-dev for 
changes in the make directory, even if it's not strictly part of the 
build system.


/Magnus