Re: RFR: 8194493 test for release file checking needs to be tier1

[David Holmes]

Hi Randy,

The build team don't have anything to do with TEST.groups, this should 
be reviewed on core-libs-dev.


Thanks,
David

On 4/01/2018 2:26 AM, Randy Crihfield wrote:
I need to add the negative test created for JDK-8192837 to the 
TEST.groups file.


The related bug is https://bugs.openjdk.java.net/browse/JDK-8194493

The diff is very short and included below.

Any comments/suggestions are welcome, also I will need a sponsor for it 
at the end…


Randy


randyc@pollux -> hg diff TEST.groups
diff -r 3a52333a5e57 test/jdk/TEST.groups
--- a/test/jdk/TEST.groups
+++ b/test/jdk/TEST.groups
@@ -32,7 +32,8 @@
  java/nio/Buffer \
  com/sun/crypto/provider/Cipher \
  :jdk_math \
-    tools/pack200
+    tools/pack200 \
+    :build_sanity

  tier2 = \
  :jdk_io \
@@ -60,6 +61,10 @@
  # Other test definitions; generally smaller granularity than tiers
  #

+# Build source checking
+build_sanity = \
+    sanity/releaseFile
+
  # java.lang package and VM runtime support
  jdk_lang = \
  java/lang \
randyc@pollux ->

Re: RFR: JDK-8194141: Remove JDK9Wrappers

[Jonathan Gibbons]

Updated webrev, reverting unnecessary change to generated-configure.sh

http://cr.openjdk.java.net/~jjg/8194141/webrev.01/

-- Jon

On 01/03/2018 01:44 PM, Jonathan Gibbons wrote:
Please review this code to remove a "temporary" class from javac, to 
provide reflective access to JDK 9 API, so that javac itself could be 
built with JDK 8.  This temporary class is no longer required, now 
that the boot JDK for JDK 10 onwards is JDK 9.


This is primarily about replacing the use of a javac internal class 
with the underlying direct API calls. However, a minor change to the 
autoconf spec is also required, to grant compile-time access to some 
internal JDK API. Some comments from the jdk.compiler module-info are 
also updated.


The fix is proposed for JDK 11.

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

-- Jon

RFR: JDK-8194141: Remove JDK9Wrappers

[Jonathan Gibbons]

Please review this code to remove a "temporary" class from javac, to 
provide reflective access to JDK 9 API, so that javac itself could be 
built with JDK 8.  This temporary class is no longer required, now that 
the boot JDK for JDK 10 onwards is JDK 9.


This is primarily about replacing the use of a javac internal class with 
the underlying direct API calls. However, a minor change to the autoconf 
spec is also required, to grant compile-time access to some internal JDK 
API. Some comments from the jdk.compiler module-info are also updated.


The fix is proposed for JDK 11.

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

-- Jon

Re: bash configure fails on missing javah

[Jonathan Gibbons]

Note the corollary is that this impacts when javac can use recent 
language features.  i.e. in order to build the "interim javac", the  
javac source code must be compatible with the "boot JDK". There's 
nothing inherently new in that, but the new release schedule is 
definitely going to have an impact here.


-- Jon


On 1/3/18 12:12 AM, Erik Joelsson wrote:
The build hasn't used javah in a long time, so the configure check for 
it is just a left over that we forgot to clean up. It should certainly 
be removed and we will be forced to do it once we switch to JDK 10 as 
boot jdk for 11.


Note though that we will not switch to JDK 10 as boot for 11 until we 
have an actual release of 10. Until then, the boot JDK for the 
development of 11 will remain as 9. In the past, this interim 
situation was pretty limited in time so we rarely had to deal with it. 
With the new release schedule, we are going to be in this situation a 
lot more, so the build documentation needs to be updated to explain this.


/Erik


On 2018-01-03 05:05, Martin Buchholz wrote:

I agree configure should not fail if javah is not found.  A high quality
configure test would first check if javac -h works, then fall back to 
javah

if that works, regardless of the boot jdk's version.

On Tue, Jan 2, 2018 at 6:33 AM, Nir Lisker  wrote:


I'm trying to build OpenJDK 11 as instructed here:
http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html.

When executing `bash configure
--with-import-modules=jfx_path\rt\build\modular-sdk`
(I've build JavaFX) the build fails:

checking for java in Boot JDK... ok
checking for javac in Boot JDK... ok
checking for javah in Boot JDK... not found
configure: Your Boot JDK seems broken. This might be fixed by 
explicitly

setting --with-boot-jdk
configure: error: Could not find javah in the Boot JDK
configure exiting with result code 1

The boot JDK is 10, which does not have javah anymore, so it is no
surprise. I could point boot JDK to a previous version, but I don't 
think I

should need to. What I should do?

Nir

RFR: 8194493 test for release file checking needs to be tier1

[Randy Crihfield]

I need to add the negative test created for JDK-8192837 to the 
TEST.groups file.


The related bug is https://bugs.openjdk.java.net/browse/JDK-8194493

The diff is very short and included below.

Any comments/suggestions are welcome, also I will need a sponsor for it 
at the end…


Randy


randyc@pollux -> hg diff TEST.groups
diff -r 3a52333a5e57 test/jdk/TEST.groups
--- a/test/jdk/TEST.groups
+++ b/test/jdk/TEST.groups
@@ -32,7 +32,8 @@
 java/nio/Buffer \
 com/sun/crypto/provider/Cipher \
 :jdk_math \
-tools/pack200
+tools/pack200 \
+:build_sanity

 tier2 = \
 :jdk_io \
@@ -60,6 +61,10 @@
 # Other test definitions; generally smaller granularity than tiers
 #

+# Build source checking
+build_sanity = \
+sanity/releaseFile
+
 # java.lang package and VM runtime support
 jdk_lang = \
 java/lang \
randyc@pollux ->

Re: bash configure fails on missing VS tools dir

[Nir Lisker]

Hello Erik,

I installed autoconf 2.69-3 through cygwin (indeed it was listed as 2.5).
However, running "bash autogen.sh" still gives:

You need autoconf installed to be able to regenerate the configure script
Error: Cannot find autoconf

If I run "bash configure" I get

Configure source code has been updated, checking time stamps
Running generated-configure.sh

And that's it. I checked generated-configure.sh and it contains only
comments and no script.

In autogen.sh I tried adding a print to help with debugging:

AUTOCONF="`which autoconf 2> /dev/null | grep -v '^no autoconf in'`"
echo "AUTOCONF is ${AUTOCONF}"

which prints

AUTOCONF is

Apologies for the mess. How do I continue?

- Nir

On Wed, Jan 3, 2018 at 4:54 PM, Erik Joelsson 
wrote:

> Hello Nir,
> On 2018-01-03 15:34, Nir Lisker wrote:
>
> Thanks for the detailed reply.
>
> Iv'e changed the logic in toolchain_windows.m4 and got this message:
>
> Configure source code has been updated, checking time stamps
> Warning: The configure source files is newer than the generated files.
> Cannot locate autoconf, unable to correct situation.
> Please install autoconf and run 'bash autogen.sh' to update the generated
> files.
> Error: Cannot continue
>
> I downloaded autoconf 2.69. How do I point to it? There is no installation.
>
> If you downloaded the src distro, then you need to compile and install it
> with something like
>
> $ ./configure
> $ make
> $ make install
>
> On Windows it's probably easier to just get it through cygwin. Note that
> the cygwin installer probably still lists autoconf as an old version in the
> name, but last I checked it was 2.69 that they actually provided. On Linux,
> just use your favorite package installation tool (apt, yum etc).
>
> As long as it's on the path, autogen.sh will pick it up. Configure will
> also detect that you changed an .m4 file and run autogen.sh for you
> automatically, which is what happened to you above.
>
> /Erik
>
> On Wed, Jan 3, 2018 at 3:24 PM, Erik Joelsson 
> wrote:
>
>> Hello Nir,
>>
>> On 2018-01-03 13:05, Nir Lisker wrote:
>>
>>> When trying to build JDK 11 on Windows 10 with VS Express 2013 Update 4
>>> (as
>>> stated in the docs - the highest supported version) the build fails:
>>>
>> AFAIK, this should work, though I have only ever used VS 2013
>> Professional.
>>
>>> bash configure  --with-tools-dir='C:\Program Files (x86)\Microsoft Visual
>>> Studio 12.0\VC\bin'
>>>
>> If VS is properly installed in the default location, there should be no
>> need to specify --with-tools-dir. Configure will look in the default
>> location automatically.
>>
>>> ...
>>> configure: Found Visual Studio installation at /cygdrive/c/Program Files
>>> (x86)/Microsoft Visual Studio 12.0/ using --with-tools-dir
>>> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is
>>> probably
>>> Visual Studio Express. Ignoring
>>> configure: Found Visual Studio installation at /cygdrive/c/Program Files
>>> (x86)/ using --with-tools-dir
>>> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is
>>> probably
>>> Visual Studio Express. Ignoring
>>> configure: The path given by --with-tools-dir does not contain a valid
>>> configure: Visual Studio installation. Please point to the VC/bin or
>>> VC/bin/amd64
>>> configure: directory within the Visual Studio installation
>>> configure: error: Cannot locate a valid Visual Studio installation
>>> configure exiting with result code 1
>>>
>>> /Microsoft Visual Studio 12.0/VC/bin/ does not contain an /amd64 folder,
>>> instead it has /x86_amd64. Also, vcvars64.bat is located directly under
>>> /VC/bin.
>>>
>> This is strange. Looking at the configure source, we assume that the VS
>> installation should contain "vc/bin/amd64/vcvars64.bat". If that file isn't
>> found, configure doesn't recognize the VS installation. Unfortunately I
>> don't have an Express installation to look at, but my old professional
>> installation has that file. In VC/bin I only have vcvars32.bat.
>>
>> I'm pretty sure this layout was how the express edition used to look as
>> well. Otherwise Magnus wouldn't have written the build doc claiming it
>> would work.
>>
>> This means the file layout for Visual Studio 2013 has changed, or that
>> it's different on Windows 10 (our builds are on older versions of Windows
>> still).
>>
>> If you would like to try to fix this, the logic that needs updating is in
>> make/autoconf/toolchain_windows.m4, in the macro
>> TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT.
>>
>>> Iv'e made another attempt using /Microsoft Visual Studio 11.0/VC/bin/
>>> which
>>> resulted in the same error. This folder also has vcvars64.bat directly
>>> under it. It also contains an /amd64 folder with a couple of dlls inside.
>>>
>>> Since I'm specifying the path to the /VC/bin dir I don't understand why
>>> it's still complaining. What am I doing wrong?
>>>
>> Because of how different the versions of Visual Studio are, 

Re: bash configure fails on missing VS tools dir

[Erik Joelsson]

Hello Nir,

On 2018-01-03 15:34, Nir Lisker wrote:

Thanks for the detailed reply.

Iv'e changed the logic in toolchain_windows.m4 and got this message:

Configure source code has been updated, checking time stamps
Warning: The configure source files is newer than the generated files.
Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the 
generated files.

Error: Cannot continue

I downloaded autoconf 2.69. How do I point to it? There is no 
installation.


If you downloaded the src distro, then you need to compile and install 
it with something like


$ ./configure
$ make
$ make install

On Windows it's probably easier to just get it through cygwin. Note that 
the cygwin installer probably still lists autoconf as an old version in 
the name, but last I checked it was 2.69 that they actually provided. On 
Linux, just use your favorite package installation tool (apt, yum etc).


As long as it's on the path, autogen.sh will pick it up. Configure will 
also detect that you changed an .m4 file and run autogen.sh for you 
automatically, which is what happened to you above.


/Erik
On Wed, Jan 3, 2018 at 3:24 PM, Erik Joelsson 
> wrote:


Hello Nir,

On 2018-01-03 13:05, Nir Lisker wrote:

When trying to build JDK 11 on Windows 10 with VS Express 2013
Update 4 (as
stated in the docs - the highest supported version) the build
fails:

AFAIK, this should work, though I have only ever used VS 2013
Professional.

bash configure  --with-tools-dir='C:\Program Files
(x86)\Microsoft Visual
Studio 12.0\VC\bin'

If VS is properly installed in the default location, there should
be no need to specify --with-tools-dir. Configure will look in the
default location automatically.

...
configure: Found Visual Studio installation at
/cygdrive/c/Program Files
(x86)/Microsoft Visual Studio 12.0/ using --with-tools-dir
configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this
is probably
Visual Studio Express. Ignoring
configure: Found Visual Studio installation at
/cygdrive/c/Program Files
(x86)/ using --with-tools-dir
configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this
is probably
Visual Studio Express. Ignoring
configure: The path given by --with-tools-dir does not contain
a valid
configure: Visual Studio installation. Please point to the
VC/bin or
VC/bin/amd64
configure: directory within the Visual Studio installation
configure: error: Cannot locate a valid Visual Studio installation
configure exiting with result code 1

/Microsoft Visual Studio 12.0/VC/bin/ does not contain an
/amd64 folder,
instead it has /x86_amd64. Also, vcvars64.bat is located
directly under
/VC/bin.

This is strange. Looking at the configure source, we assume that
the VS installation should contain "vc/bin/amd64/vcvars64.bat". If
that file isn't found, configure doesn't recognize the VS
installation. Unfortunately I don't have an Express installation
to look at, but my old professional installation has that file. In
VC/bin I only have vcvars32.bat.

I'm pretty sure this layout was how the express edition used to
look as well. Otherwise Magnus wouldn't have written the build doc
claiming it would work.

This means the file layout for Visual Studio 2013 has changed, or
that it's different on Windows 10 (our builds are on older
versions of Windows still).

If you would like to try to fix this, the logic that needs
updating is in make/autoconf/toolchain_windows.m4, in the macro
TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT.

Iv'e made another attempt using /Microsoft Visual Studio
11.0/VC/bin/ which
resulted in the same error. This folder also has vcvars64.bat
directly
under it. It also contains an /amd64 folder with a couple of
dlls inside.

Since I'm specifying the path to the /VC/bin dir I don't
understand why
it's still complaining. What am I doing wrong?

Because of how different the versions of Visual Studio are,
configure will not automatically assume or try a different version
than the default without being told to. If you want to try 2012,
you need to tell configure using --with-toolchain-version=2012. No
need to specify tools dir as long as it's installed in the default
location.

On a related note, is it possible to update the build
requirements to work
with VS 2017? OpenJFX already uses this version.

This will likely happen in JDK 11 time frame. Note though that
changing compilers is usually a pretty big effort so it will take
a while.

  

Re: bash configure fails on missing VS tools dir

[Nir Lisker]

Thanks for the detailed reply.

Iv'e changed the logic in toolchain_windows.m4 and got this message:

Configure source code has been updated, checking time stamps
Warning: The configure source files is newer than the generated files.
Cannot locate autoconf, unable to correct situation.
Please install autoconf and run 'bash autogen.sh' to update the generated
files.
Error: Cannot continue

I downloaded autoconf 2.69. How do I point to it? There is no installation.

On Wed, Jan 3, 2018 at 3:24 PM, Erik Joelsson 
wrote:

> Hello Nir,
>
> On 2018-01-03 13:05, Nir Lisker wrote:
>
>> When trying to build JDK 11 on Windows 10 with VS Express 2013 Update 4
>> (as
>> stated in the docs - the highest supported version) the build fails:
>>
> AFAIK, this should work, though I have only ever used VS 2013 Professional.
>
>> bash configure  --with-tools-dir='C:\Program Files (x86)\Microsoft Visual
>> Studio 12.0\VC\bin'
>>
> If VS is properly installed in the default location, there should be no
> need to specify --with-tools-dir. Configure will look in the default
> location automatically.
>
>> ...
>> configure: Found Visual Studio installation at /cygdrive/c/Program Files
>> (x86)/Microsoft Visual Studio 12.0/ using --with-tools-dir
>> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably
>> Visual Studio Express. Ignoring
>> configure: Found Visual Studio installation at /cygdrive/c/Program Files
>> (x86)/ using --with-tools-dir
>> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably
>> Visual Studio Express. Ignoring
>> configure: The path given by --with-tools-dir does not contain a valid
>> configure: Visual Studio installation. Please point to the VC/bin or
>> VC/bin/amd64
>> configure: directory within the Visual Studio installation
>> configure: error: Cannot locate a valid Visual Studio installation
>> configure exiting with result code 1
>>
>> /Microsoft Visual Studio 12.0/VC/bin/ does not contain an /amd64 folder,
>> instead it has /x86_amd64. Also, vcvars64.bat is located directly under
>> /VC/bin.
>>
> This is strange. Looking at the configure source, we assume that the VS
> installation should contain "vc/bin/amd64/vcvars64.bat". If that file isn't
> found, configure doesn't recognize the VS installation. Unfortunately I
> don't have an Express installation to look at, but my old professional
> installation has that file. In VC/bin I only have vcvars32.bat.
>
> I'm pretty sure this layout was how the express edition used to look as
> well. Otherwise Magnus wouldn't have written the build doc claiming it
> would work.
>
> This means the file layout for Visual Studio 2013 has changed, or that
> it's different on Windows 10 (our builds are on older versions of Windows
> still).
>
> If you would like to try to fix this, the logic that needs updating is in
> make/autoconf/toolchain_windows.m4, in the macro
> TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT.
>
>> Iv'e made another attempt using /Microsoft Visual Studio 11.0/VC/bin/
>> which
>> resulted in the same error. This folder also has vcvars64.bat directly
>> under it. It also contains an /amd64 folder with a couple of dlls inside.
>>
>> Since I'm specifying the path to the /VC/bin dir I don't understand why
>> it's still complaining. What am I doing wrong?
>>
> Because of how different the versions of Visual Studio are, configure will
> not automatically assume or try a different version than the default
> without being told to. If you want to try 2012, you need to tell configure
> using --with-toolchain-version=2012. No need to specify tools dir as long
> as it's installed in the default location.
>
>> On a related note, is it possible to update the build requirements to work
>> with VS 2017? OpenJFX already uses this version.
>>
> This will likely happen in JDK 11 time frame. Note though that changing
> compilers is usually a pretty big effort so it will take a while.
>
> /Erik
>
>> - Nir
>>
>
>

Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

[Volker Simonis]

Hi Martin,

I'm afraid that's not easy to answer. The fix didn't made it into
8u162 which will be released in January 2018 [1]. It is targeted for
8u172 but there is no time-line for 8u172 yet [2].

The best you can do is to ask on the 8u-dev [3] mailing list or ask
the people at AdoptOpenJDK (adoption-disc...@openjdk.java.net [4]) to
merge the fix into their current builds. That would be actually a good
smoke test for their tool chain :)

Regards,
Volker

[1] http://openjdk.java.net/projects/jdk8u/releases/8u162.html
[2] http://openjdk.java.net/projects/jdk8u/
[3] http://mail.openjdk.java.net/mailman/listinfo/jdk8u-dev
[4] http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss

On Tue, Jan 2, 2018 at 6:55 PM, Evans, Martin
 wrote:
> Hi Volker,
>
> Happy new year!
>
> Do you have a rough idea as to when it will make it into the regular update?
>
> Kind regards,
>
> Martin
>
> -Original Message-
> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> Sent: 22 December 2017 16:25
> To: Evans, Martin 
> Cc: Baesken, Matthias ; 
> jdk8u-dev-requ...@openjdk.java.net; core-libs-...@openjdk.java.net; 
> ppc-aix-port-...@openjdk.java.net; Simonis, Volker ; 
> build-dev 
> Subject: Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by 
> providing empty basic implementations of getSystemCpuLoad and 
> getProcessCpuLoad
>
> Hi Martin,
>
> I've just pushed the fix to jdk8u/jdk8u-dev [1] so it should be in the next 
> regular 8u update (probably 8u172 ?).
>
> You can of course test it any time by building the tip of 
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev yourself :)
>
> Merry Christmas and a happy new year,
> Volker
>
> [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/def07b5ce3be
>
> On Wed, Dec 20, 2017 at 11:18 AM, Evans, Martin  
> wrote:
>> Many thanks guys, I look forward to testing.
>>
>> Regards,
>>
>> Martin
>>
>> -Original Message-
>> From: Volker Simonis [mailto:volker.simo...@gmail.com]
>> Sent: 20 December 2017 09:33
>> To: Baesken, Matthias 
>> Cc: jdk8u-dev-requ...@openjdk.java.net;
>> core-libs-...@openjdk.java.net; ppc-aix-port-...@openjdk.java.net;
>> Simonis, Volker ; Evans, Martin
>> ; build-dev 
>> Subject: Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by
>> providing empty basic implementations of getSystemCpuLoad and
>> getProcessCpuLoad
>>
>> Hi Matthias,
>>
>> the change looks good!
>> I can sponsor it once we get the approval.
>>
>> Also forwarded to buil-dev for the minimal build change.
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias 
>>  wrote:
>>> Hello  , Mark reported  this issue on AIX  with OpenJDK8 :
>>>

I'm getting an unsatisfied link error when using logstash on AIX but I 
suspect the issue is with AIX or the JRE, the exception is:

 java.lang.UnsatisfiedLinkError: 
 sun.management.OperatingSystemImpl.getProcessCpuLoad()D
  getProcessCpuLoad at 
 sun/management/OperatingSystemImpl.java:-2
  at 
 org/logstash/instrument/monitors/ProcessMonitor.java:40
 detect at 
 org/logstash/instrument/monitors/ProcessMonitor.java:79
   generate at
 org/logstash/instrument/reports/ProcessReport.java:15

 this is the line in logstash:

 this.cpuProcessPercent =
 scaleLoadToPercent(unixOsBean.getProcessCpuLoad());

 https://github.com/elastic/logstash/blob/master/logstash-core/src/ma
 i n/java/org/logstash/instrument/monitors/ProcessMonitor.java


 Could anybody help steer me in the right direction?

>>>
>>> This fix addresses  the missing  getSystemCpuLoad and getProcessCpuLoad  on 
>>> AIX  .
>>> JDK8 is only affected , JDK9 and higher is not affected .
>>>
>>> Could I get a  review for this change   ?
>>>
>>>
>>> Change :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8193807/
>>>
>>> Bug :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8193807
>>>
>>>
>>> Thanks, Matthias
>>  Kingfisher plc Registered Office: 3 Sheldon Square, Paddington, 
>> London W2 6PX Registered in England, Number 1664812 This e-mail is only 
>> intended for the person(s) to whom it is addressed and may contain 
>> confidential information. Unless stated to the contrary, any opinions or 
>> comments are personal to the writer and do not represent the official view 
>> of the company. If you have received this e-mail in error, please notify us 
>> immediately by reply e-mail and then delete this message from your system. 
>> Please do not copy it or use it for any purpose, or disclose its contents to 

Re: Building hsdis?

[Andrew Haley]

On 03/01/18 14:02, Florian Weimer wrote:
> On 01/03/2018 02:58 PM, Andrew Haley wrote:
>> On 03/01/18 13:35, Florian Weimer wrote:
>>> On 12/25/2017 11:58 PM, Andrew Haley wrote:
 IANAL, but AFAIK It would not help.  The incompatibility is because
 you can't link pure GPLv2 code (HotSpot) and pure GPLv3 code
 (binutils) together, even via dynamic linkage.  Changing the licences
 of hsdis.{c,h}) won't solve that problem.
>>>
>>> But Hotspot links against libgcc and libstdc++, which are GPLv3 as well,
>>> so that issue isn't specific to hsdis.
>>
>> No, they are not.  They never have been.
> 
> The header file comments and the exception itself say otherwise.
> 
>> https://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html
> 
> The exception gives permission to ignore certain terms imposed by the 
> GPLv3 (“even if such propagation would otherwise violate the terms of 
> GPLv3”).  It does not give permission to violate the terms of the GPLv2, 
> and it could not, because the GPLv2 part of the overall conglomerate is 
> an unrelated project with a different copyright holder.

Of course not.  The question is nothing to do with that.  The problem
is that pure GPLv2 and pure GPLv3 are not compatible.  (AFAIK, IANAL,
etc.)  Nobody ever intended that libgcc, for example, should be
incompatible with pure GPLv2 programs.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Building hsdis?

[Florian Weimer]

On 01/03/2018 02:58 PM, Andrew Haley wrote:

On 03/01/18 13:35, Florian Weimer wrote:

On 12/25/2017 11:58 PM, Andrew Haley wrote:

IANAL, but AFAIK It would not help.  The incompatibility is because
you can't link pure GPLv2 code (HotSpot) and pure GPLv3 code
(binutils) together, even via dynamic linkage.  Changing the licences
of hsdis.{c,h}) won't solve that problem.


But Hotspot links against libgcc and libstdc++, which are GPLv3 as well,
so that issue isn't specific to hsdis.


No, they are not.  They never have been.


The header file comments and the exception itself say otherwise.


https://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html


The exception gives permission to ignore certain terms imposed by the 
GPLv3 (“even if such propagation would otherwise violate the terms of 
GPLv3”).  It does not give permission to violate the terms of the GPLv2, 
and it could not, because the GPLv2 part of the overall conglomerate is 
an unrelated project with a different copyright holder.


Thanks,
Florian

Re: Building hsdis?

[Florian Weimer]

On 12/25/2017 11:58 PM, Andrew Haley wrote:

IANAL, but AFAIK It would not help.  The incompatibility is because
you can't link pure GPLv2 code (HotSpot) and pure GPLv3 code
(binutils) together, even via dynamic linkage.  Changing the licences
of hsdis.{c,h}) won't solve that problem.


But Hotspot links against libgcc and libstdc++, which are GPLv3 as well, 
so that issue isn't specific to hsdis.  It obviously has not stopped 
anyone from distributing OpenJDK binaries (or Git binaries, for that 
matter).


Thanks,
Florian

Re: bash configure fails on missing VS tools dir

[Erik Joelsson]

Hello Nir,

On 2018-01-03 13:05, Nir Lisker wrote:

When trying to build JDK 11 on Windows 10 with VS Express 2013 Update 4 (as
stated in the docs - the highest supported version) the build fails:

AFAIK, this should work, though I have only ever used VS 2013 Professional.

bash configure  --with-tools-dir='C:\Program Files (x86)\Microsoft Visual
Studio 12.0\VC\bin'
If VS is properly installed in the default location, there should be no 
need to specify --with-tools-dir. Configure will look in the default 
location automatically.

...
configure: Found Visual Studio installation at /cygdrive/c/Program Files
(x86)/Microsoft Visual Studio 12.0/ using --with-tools-dir
configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably
Visual Studio Express. Ignoring
configure: Found Visual Studio installation at /cygdrive/c/Program Files
(x86)/ using --with-tools-dir
configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably
Visual Studio Express. Ignoring
configure: The path given by --with-tools-dir does not contain a valid
configure: Visual Studio installation. Please point to the VC/bin or
VC/bin/amd64
configure: directory within the Visual Studio installation
configure: error: Cannot locate a valid Visual Studio installation
configure exiting with result code 1

/Microsoft Visual Studio 12.0/VC/bin/ does not contain an /amd64 folder,
instead it has /x86_amd64. Also, vcvars64.bat is located directly under
/VC/bin.
This is strange. Looking at the configure source, we assume that the VS 
installation should contain "vc/bin/amd64/vcvars64.bat". If that file 
isn't found, configure doesn't recognize the VS installation. 
Unfortunately I don't have an Express installation to look at, but my 
old professional installation has that file. In VC/bin I only have 
vcvars32.bat.


I'm pretty sure this layout was how the express edition used to look as 
well. Otherwise Magnus wouldn't have written the build doc claiming it 
would work.


This means the file layout for Visual Studio 2013 has changed, or that 
it's different on Windows 10 (our builds are on older versions of 
Windows still).


If you would like to try to fix this, the logic that needs updating is 
in make/autoconf/toolchain_windows.m4, in the macro 
TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT.

Iv'e made another attempt using /Microsoft Visual Studio 11.0/VC/bin/ which
resulted in the same error. This folder also has vcvars64.bat directly
under it. It also contains an /amd64 folder with a couple of dlls inside.

Since I'm specifying the path to the /VC/bin dir I don't understand why
it's still complaining. What am I doing wrong?
Because of how different the versions of Visual Studio are, configure 
will not automatically assume or try a different version than the 
default without being told to. If you want to try 2012, you need to tell 
configure using --with-toolchain-version=2012. No need to specify tools 
dir as long as it's installed in the default location.

On a related note, is it possible to update the build requirements to work
with VS 2017? OpenJFX already uses this version.
This will likely happen in JDK 11 time frame. Note though that changing 
compilers is usually a pretty big effort so it will take a while.


/Erik

- Nir

bash configure fails on missing VS tools dir

[Nir Lisker]

When trying to build JDK 11 on Windows 10 with VS Express 2013 Update 4 (as
stated in the docs - the highest supported version) the build fails:

bash configure  --with-tools-dir='C:\Program Files (x86)\Microsoft Visual
Studio 12.0\VC\bin'

...
configure: Found Visual Studio installation at /cygdrive/c/Program Files
(x86)/Microsoft Visual Studio 12.0/ using --with-tools-dir
configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably
Visual Studio Express. Ignoring
configure: Found Visual Studio installation at /cygdrive/c/Program Files
(x86)/ using --with-tools-dir
configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is probably
Visual Studio Express. Ignoring
configure: The path given by --with-tools-dir does not contain a valid
configure: Visual Studio installation. Please point to the VC/bin or
VC/bin/amd64
configure: directory within the Visual Studio installation
configure: error: Cannot locate a valid Visual Studio installation
configure exiting with result code 1

/Microsoft Visual Studio 12.0/VC/bin/ does not contain an /amd64 folder,
instead it has /x86_amd64. Also, vcvars64.bat is located directly under
/VC/bin.

Iv'e made another attempt using /Microsoft Visual Studio 11.0/VC/bin/ which
resulted in the same error. This folder also has vcvars64.bat directly
under it. It also contains an /amd64 folder with a couple of dlls inside.

Since I'm specifying the path to the /VC/bin dir I don't understand why
it's still complaining. What am I doing wrong?

On a related note, is it possible to update the build requirements to work
with VS 2017? OpenJFX already uses this version.

- Nir

Re: bash configure fails on missing javah

[Nir Lisker]

Thanks, I used 9 as boot. It is definitely worthwhile to update the build
doc in this regard.

- Nir

On Wed, Jan 3, 2018 at 10:12 AM, Erik Joelsson 
wrote:

> The build hasn't used javah in a long time, so the configure check for it
> is just a left over that we forgot to clean up. It should certainly be
> removed and we will be forced to do it once we switch to JDK 10 as boot jdk
> for 11.
>
> Note though that we will not switch to JDK 10 as boot for 11 until we have
> an actual release of 10. Until then, the boot JDK for the development of 11
> will remain as 9. In the past, this interim situation was pretty limited in
> time so we rarely had to deal with it. With the new release schedule, we
> are going to be in this situation a lot more, so the build documentation
> needs to be updated to explain this.
>
> /Erik
>
>
>
> On 2018-01-03 05:05, Martin Buchholz wrote:
>
>> I agree configure should not fail if javah is not found.  A high quality
>> configure test would first check if javac -h works, then fall back to
>> javah
>> if that works, regardless of the boot jdk's version.
>>
>> On Tue, Jan 2, 2018 at 6:33 AM, Nir Lisker  wrote:
>>
>> I'm trying to build OpenJDK 11 as instructed here:
>>> http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html.
>>>
>>> When executing `bash configure
>>> --with-import-modules=jfx_path\rt\build\modular-sdk`
>>> (I've build JavaFX) the build fails:
>>>
>>> checking for java in Boot JDK... ok
>>> checking for javac in Boot JDK... ok
>>> checking for javah in Boot JDK... not found
>>> configure: Your Boot JDK seems broken. This might be fixed by explicitly
>>> setting --with-boot-jdk
>>> configure: error: Could not find javah in the Boot JDK
>>> configure exiting with result code 1
>>>
>>> The boot JDK is 10, which does not have javah anymore, so it is no
>>> surprise. I could point boot JDK to a previous version, but I don't
>>> think I
>>> should need to. What I should do?
>>>
>>> Nir
>>>
>>>
>

Re: [10] Review Request: 8193673 Regression manual Test javax/swing/JFileChooser/6515169/bug6515169.java fails

[Erik Joelsson]

Looks good.

/Erik


On 2018-01-02 22:46, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk10. The fix will be pushed to:
http://hg.openjdk.java.net/jdk/jdk10

Bug: https://bugs.openjdk.java.net/browse/JDK-8193673
Webrev can be found at: 
http://cr.openjdk.java.net/~serb/8193673/webrev.00


The fix for JDK-8189656[1] missed an update of Gensrc-java.desktop.gmk 
which compiles the property files for windows L


[1] https://bugs.openjdk.java.net/browse/JDK-8189656

Re: bash configure fails on missing javah

[Erik Joelsson]

The build hasn't used javah in a long time, so the configure check for 
it is just a left over that we forgot to clean up. It should certainly 
be removed and we will be forced to do it once we switch to JDK 10 as 
boot jdk for 11.


Note though that we will not switch to JDK 10 as boot for 11 until we 
have an actual release of 10. Until then, the boot JDK for the 
development of 11 will remain as 9. In the past, this interim situation 
was pretty limited in time so we rarely had to deal with it. With the 
new release schedule, we are going to be in this situation a lot more, 
so the build documentation needs to be updated to explain this.


/Erik


On 2018-01-03 05:05, Martin Buchholz wrote:

I agree configure should not fail if javah is not found.  A high quality
configure test would first check if javac -h works, then fall back to javah
if that works, regardless of the boot jdk's version.

On Tue, Jan 2, 2018 at 6:33 AM, Nir Lisker  wrote:


I'm trying to build OpenJDK 11 as instructed here:
http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html.

When executing `bash configure
--with-import-modules=jfx_path\rt\build\modular-sdk`
(I've build JavaFX) the build fails:

checking for java in Boot JDK... ok
checking for javac in Boot JDK... ok
checking for javah in Boot JDK... not found
configure: Your Boot JDK seems broken. This might be fixed by explicitly
setting --with-boot-jdk
configure: error: Could not find javah in the Boot JDK
configure exiting with result code 1

The boot JDK is 10, which does not have javah anymore, so it is no
surprise. I could point boot JDK to a previous version, but I don't think I
should need to. What I should do?

Nir

Re: bash configure fails on missing javah

[Alan Bateman]

On 03/01/2018 04:05, Martin Buchholz wrote:

I agree configure should not fail if javah is not found.  A high quality
configure test would first check if javac -h works, then fall back to javah
if that works, regardless of the boot jdk's version.

JDK-8193512 removes the check for javah from boot-jdk.m4 so I assume 
part of the issue is that this change is in jdk/jdk10 and just hasn't 
got to jdk/jdk yet.


In any case, I think David is right. We have to use JDK 9 as the boot 
JDK for now.


-Alan