Re: 8209520: Build fails when native code coverage is enabled

[Igor Ignatev]

Hi Leonid,

We have never supported native code coverage builds with warnings enabled as 
errors. There are bugs in gcc which cause false positive warnings, so it was 
decided to ignore all warnings from instrumented builds. It’d be much better 
and reliable to fix makefiles to always use ‘disable-warning-as-errors’ when 
‘enable-native-coverage’ is used. It should be pretty straightforward to do.

cc’ing build alias.  

Cheers,
— Igor

> On Aug 23, 2018, at 2:37 PM, Vladimir Kozlov  
> wrote:
> 
> macroassembler changes are good.
> 
> Thanks,
> Vladimir
> 
>> On 8/23/18 1:51 PM, Leonid Mesnik wrote:
>> Hi
>> Could you please review following fix which fix code so gcc doesn't complain 
>> when JDK is build with enabled native code coverage.
>> webrev: http://cr.openjdk.java.net/~lmesnik/8209520/webrev.00/ 
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8209520
>> These warning appeared because of change optimization settings used for 
>> getting code coverage.
>> 1) src/hotspot/cpu/x86/macroAssembler_x86.cpp, 
>> src/hotspot/share/gc/shared/genCollectedHeap.cpp
>> gcc complained about uninitialized variables, like
>> * For target hotspot_variant-server_libjvm_objs_macroAssembler_x86.o:
>> /home/lmesnik/ws/jdk-8209520/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:
>>  In member function 'void ControlWord::print() const':
>> /home/lmesnik/ws/jdk-8209520/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:5769:11:
>>  error: 'pc' may be used uninitialized in this function 
>> [-Werror=maybe-uninitialized]
>>  printf("%04x  masks = %s, %s, %s", _value & 0x, f, rc, pc);
>>  ~~^~~~
>> /home/lmesnik/ws/jdk-8209520/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:5769:11:
>>  error: 'rc' may be used uninitialized in this function 
>> [-Werror=maybe-uninitialized]
>> So I just fixed codepath to show more explicitly that variables are 
>> initialized before usage.
>> 2) src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:
>> The changes to prevent waning about clobbering in splashscreen_png.c are 
>> similar to fix in:
>> 1. JDK-8080695 
>>splashscreen_png.c compile error with gcc 4.9.2
>> The another approach would be to fix build to ignore these warnings for code 
>> coverage build. While I think it makes build system even more complicated.
>> Leonid

Re: RFR 8208183: update HSDIS plugin license to UPL

[joe darcy]

Hello,

A general comment on CSR filing, writing a CSR and getting it reviewed 
and approved is not necessarily a large amount of work or high-latency. 
Many small requests are approved the same day they are finalized.


I'm happy to answer questions about CSRs, including on whether or not 
one needs to be filed.


Cheers,

-Joe


On 8/22/2018 9:46 AM, mark.reinh...@oracle.com wrote:

2018/8/21 7:25:58 -0700, volker.simo...@gmail.com:

On Tue, Aug 21, 2018 at 12:14 PM, magnus.ihse.bur...@oracle.com wrote:

...

I can easily add a new make target to build hsdis.

Adding a new binary to the OpenJDK images will require a CSR.

Do we really need a CSR for hsdis? hsdis is a shared library/DLL and
not a "binary" which can be called by the user or executed
stand-alone. The functionality offered by hsdis is only accessible by
already existing command line parameters (like -XX:+PrintAssembly).

The CSR FAQ [1] only mentions (among others):

- Adding or removing a command in $JDK/bin
- Adding, removing, or changing a command line option

which both don't seem to be applicable to hsdis.

The mere addition or removal of a shared library within the JDK image
does not, of itself, require a CSR -- unless it’s a shared library that
external code is expected to link against, which isn’t the case here.

If we wind up building hsdis by default, however, and thus including it
in the JDK image, then we’d effectively modify the behavior of the
existing -XX:+PrintAssembly option.  It’s a change to diagnostic
information, and so strictly speaking a CSR is not required, but it
would be both visible to and of potential interest to many developers,
so a CSR (and a release note) would be helpful.

If we wind up not building hsdis by default then it’s even more of a
borderline case.  If we think that many implementors would enable it
in their builds then a CSR would be helpful; if not, then I wouldn’t
bother.

- Mark

Re: Where to find the 3rd party libraries used by --with-graalunit-lib

[Erik Joelsson]

I believe this contains the information you seek: 
http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/test/hotspot/jtreg/compiler/graalunit/README.md


/Erik


On 2018-08-21 03:56, Zhongwei Yao wrote:

Hi, all,

To run Graal unit test included in OpenJDK's jtreg tests, I need to add 
"-with-graalunit-lib" to specify the graalunit-lib path. But I can't find where 
I can get such libs. Could you point me to where or how to get them? Thanks!

--
Best regards,
Zhongwei

Re: custom extension for make/SourceRevision.gmk

[Erik Joelsson]

On 2018-08-20 04:27, Christian Thalinger wrote:



On Jul 19, 2018, at 9:17 PM, Christian Thalinger 
mailto:cthalin...@twitter.com>> wrote:




On Jul 19, 2018, at 2:31 PM, Erik Joelsson > wrote:


I can do that. Do you have a bug?


No.


Sorry, was on vacation… I don’t see the change in the repo. Did you 
file one?


I left for vacation too, still am for a few more days. I don't think I 
got around to this before that.


/Erik


/Erik


On 2018-07-19 10:57, Christian Thalinger wrote:



On Thu, Jul 19, 2018 at 1:11 PM Erik Joelsson 
mailto:erik.joels...@oracle.com>> wrote:


This looks good to me, but will need coordination when pushed
as I said earlier.


Do you want to push it so it’s easier?

/Erik


On 2018-07-19 10:04, Christian Thalinger wrote:




On Jul 19, 2018, at 12:57 PM, Erik Joelsson
mailto:erik.joels...@oracle.com>>
wrote:



On 2018-07-19 09:54, Christian Thalinger wrote:




On Jul 19, 2018, at 12:44 PM, Erik Joelsson
mailto:erik.joels...@oracle.com>> wrote:


On 2018-07-19 09:16, Christian Thalinger wrote:



Well, the issue is this:

exploded-image: exploded-image-base release-file

  release-file: create-source-revision-tracker

store-source-revision:
+($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f
SourceRevision.gmk store-source-revision)

create-source-revision-tracker:
+($(CD) $(TOPDIR)/make && $(MAKE) $(MAKE_ARGS) -f
SourceRevision.gmk create-source-revision-tracker)

We need these targets because all isn’t really used.


Ah, the all target is tricking me and should be removed if
not called from anywhere. Then your suggested patch is good
(except for missing the :=).


Do you want me to remove the all: target?


Yes, that would be a good cleanup to avoid confusion.


How about this:

diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk
index 10dd943..6d4a706 100644
--- a/make/SourceRevision.gmk
+++ b/make/SourceRevision.gmk
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2016, Oracle and/or its affiliates. All
rights reserved.
+# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All
rights reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or
modify it
@@ -23,12 +23,10 @@
 # questions.
 #

-default: all
-
 include $(SPEC)
 include MakeBase.gmk

-$(eval $(call IncludeCustomExtension, SourceRevision.gmk))
+$(eval $(call IncludeCustomExtension, SourceRevision-pre.gmk))

 

 # Keep track of what source revision is used to create the
build, by creating
@@ -94,11 +92,14 @@ifneq ($(and $(HG), $(wildcard
$(TOPDIR)/.hg)), )

   $(eval $(call CreateSourceRevisionFile,
$(STORED_SOURCE_REVISION)))

- store-source-revision: $(STORED_SOURCE_REVISION)
+ hg-store-source-revision: $(STORED_SOURCE_REVISION)

   $(eval $(call CreateSourceRevisionFile,
$(SOURCE_REVISION_TRACKER)))

- create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+ hg-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+
+ STORE_SOURCE_REVISION_TARGET := hg-store-source-revision
+ CREATE_SOURCE_REVISION_TRACKER_TARGET :=
hg-create-source-revision-tracker

 else
   # Not using HG
@@ -106,28 +107,39 @@else
   ifneq ($(wildcard $(STORED_SOURCE_REVISION)), )
     # We have a stored source revision (.src-rev)

- store-source-revision:
+ src-store-source-revision:
        $(call LogInfo, No mercurial configuration
present$(COMMA) not updating .src-rev)

$(SOURCE_REVISION_TRACKER): $(STORED_SOURCE_REVISION)
        $(install-file)

- create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
+ src-create-source-revision-tracker: $(SOURCE_REVISION_TRACKER)
   else
     # We don't have a stored source revision. Can't do
anything, really.

- store-source-revision:
+ src-store-source-revision:
        $(call LogWarn, Error: No mercurial configuration
present$(COMMA) cannot create .src-rev)
        exit 2

- create-source-revision-tracker:
+ src-create-source-revision-tracker:
        $(call LogWarn, Warning: No mercurial configuration
present and no .src-rev)
   endif

+ STORE_SOURCE_REVISION_TARGET := src-store-source-revision
+ CREATE_SOURCE_REVISION_TRACKER_TARGET :=
src-create-source-revision-tracker
+
 endif

-all: store-source-revision create-source-revision-tracker

+
+
+$(eval $(call IncludeCustomExtension, SourceRevision-post.gmk))
+

+
+

Re: Windows toolchain parse problems

[Erik Joelsson]

Hello Artur,

We would certainly like to not be dependent on locale settings at build 
time, but it's hard to squash out all the instances. This one seems 
especially server though as it completely prevents building. On non 
Windows platforms, you can always get around it with "LC_ALL=C make ..." 
but I don't know of any equivalent on Windows.


/Erik


On 2018-08-11 10:11, Artur Khusainov wrote:

Hi,

I'm currently trying to build openjdk11 from on my Windows 7 with VS2017
installed. I discovered the issue which cause "bash configure" to fail.

+ configure: The C compiler (located as
/cygdrive/c/progra~2/mib055~1/2017/commun~1/vc/tools/msvc/1414~1.264/bin/hostx86/x64/cl)
does not seem to be the required microsoft compiler.
+ configure: error: A microsoft compiler is required. Try setting
--with-tools-dir.
+ configure: The result from running it was: "▒▒?▒▒? ▒▒
Microsoft (R)
C/C++ ▒▒▒? 19.14.26433 ▒▒▒ x64"
+ configure exiting with result code 1

I think the problem is that configuration relies on en-US locale output. It
is actually valid, but cannot be parsed because my Windows installation
uses ru-RU locale by default. Latest cl.exe returns the following line:
+ Оптимизирующий компилятор Microsoft (R) C/C++ версии 19.14.26433 для x64

I think that would be a problem for anyone who doesn't use en-US locale.
I managed to avoid this issue by replacing line 434 in
make/autoconf/toolchain.m4:
+ $ECHO "$COMPILER_VERSION_OUTPUT" | $GREP "Microsoft.*C/C++" > /dev/null

But still, COMPILER_VERSION_NUMBER is not parsed properly and configure
prints a warning:
+ WARNING: You are using microsoft older than 16.00.30319.01. This is not a
supported configuration.

After that compilation ran smoothly.

Re: How to build hotspot jtreg test JNI with specific CFLAGS?

[Erik Joelsson]

Hello Severin,

This does indeed look like the correct fix and I agree that the 
OPTIMIZATION level should be customizeable like this for test libraries.


/Erik


On 2018-08-06 03:29, Severin Gehwolf wrote:

Hi,

On Mon, 2018-08-06 at 09:52 +0200, Severin Gehwolf wrote:

I'm trying to get a JNI library used for testing to be compiled with
certain CFLAGS. In particular, I'm trying to get it compiled on a GCC
platform with '-fomit-frame-pointer' and/or '-fomit-frame-pointer -O3'.
The patch currently looks like this:

diff --git a/make/test/JtregNativeHotspot.gmk b/make/test/JtregNativeHotspot.gmk
--- a/make/test/JtregNativeHotspot.gmk
+++ b/make/test/JtregNativeHotspot.gmk
@@ -139,6 +139,13 @@
   -I$(VM_TESTBASE_DIR)/nsk/share/native \
   -I$(VM_TESTBASE_DIR)/nsk/share/jni
   
+NO_FRAMEPOINTER_CFLAGS :=

+ifeq ($(OPENJDK_TARGET_OS),linux)
+   NO_FRAMEPOINTER_CFLAGS := -O3 -fomit-frame-pointer
+endif
+
+BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libNoFramePointer := 
$(NO_FRAMEPOINTER_CFLAGS)
+
   BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libProcessUtils := $(VM_SHARE_INCLUDES)
   
   BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libThreadController := $(NSK_MONITORING_INCLUDES)


When I look at the compile command line this produces with 'make run-test', I 
see this:

$ cat 
./build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.o.cmdline
/usr/bin/gcc 
-I/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/modules_include/java.base
 
-I/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/modules_include/java.base/linux
 -I/disk/openjdk/upstream-sources/openjdk-head/src/java.base/share/native/libjava 
-I/disk/openjdk/upstream-sources/openjdk-head/src/java.base/unix/native/libjava 
-I/disk/openjdk/upstream-sources/openjdk-head/src/hotspot/share/include 
-I/disk/openjdk/upstream-sources/openjdk-head/src/hotspot/os/posix/include -pipe -D_GNU_SOURCE 
-D_REENTRANT -D_LARGEFILE64_SOURCE -DLINUX -DNDEBUG -Wall -Wextra -Wno-unused -Wno-unused-parameter 
-Wformat=2 -fno-strict-aliasing -m64 -D_LITTLE_ENDIAN -DARCH='"amd64"' -Damd64 -D_LP64=1 
-fno-omit-frame-pointer -fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC -O3 
-fomit-frame-pointer -g -O2 -DTHIS_FILE='""' -c -MMD -MF 
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.d
 -o 
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/libNoFramePointer/libNoFramePointer.o
 
/disk/openjdk/upstream-sources/openjdk-head/test/hotspot/jtreg/serviceability/sa/libNoFramePointer.c

The command line has '-O3 -fomit-frame-pointer -g -O2' in that order.
This screws things up since -O2 seems to override -fomit-frame-pointer.
My guess is that -O2 is from OPTIMIZATION == LOW, but not sure. How can
I get this -O2 flag removed which apparently gets added later?

It was indeed an issue with OPTIMIZATION. A value of LOW is hard-coded
in TestFilesCompilation. This patch fixes this by allowing one to
override OPTIMIZATION per library via something like this:

BUILD_HOTSPOT_JTREG_LIBRARIES_OPTIMIZATION_libNoFramePointer := HIGH

diff --git a/make/common/TestFilesCompilation.gmk 
b/make/common/TestFilesCompilation.gmk
--- a/make/common/TestFilesCompilation.gmk
+++ b/make/common/TestFilesCompilation.gmk
@@ -94,7 +94,7 @@
  CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$(name)), \
  LDFLAGS := $$($1_LDFLAGS) $$($1_LDFLAGS_$$(name)), \
  LIBS := $$($1_LIBS_$$(name)), \
-OPTIMIZATION := LOW, \
+OPTIMIZATION := $$(if 
$$($1_OPTIMIZATION_$$(name)),$$($1_OPTIMIZATION_$$(name)),LOW), \
  COPY_DEBUG_SYMBOLS := false, \
  STRIP_SYMBOLS := false, \
  )) \

Thanks,
Severin

Re: RFR 8209064: Make intellij support more robust after changes for 2018.2

[Maurizio Cimadamore]

On 21/08/18 10:31, Magnus Ihse Bursie wrote:

Hi Maurizio!

Even if this only incidentally relates to the build, please always 
include build-dev when making changes in the "make" directory.

I will - thanks


As far as I can understand, your changes looks good. One question: the 
build.xml was previously stored as a "template", and copied to the 
output directory. Now it's left in the source tree. I assume that 
there was no actual transformations or changes made to the template 
before? So that the scripts do not modify the source tree version, 
that is.
You are correct - the script is not meant to be modified; customized 
properties are injected by the runtime environment - such properties are 
defined in the ant.xml file and that is indeed a template file (so it 
can be customized).


Thanks
Maurizio


/Magnus

On 2018-08-07 13:21, Maurizio Cimadamore wrote:

Hi,
last week I submitted an 'emergency' patch to fix intellij project 
support after 2018.2 changes. The goal of these changes was to move 
the build.xml ant file out of the .idea folder, as the IDE no longer 
supported DOM indexing in such folders (as a result of 
https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I 
tweaked the scripts to copy build.xml in the build folder.


Thinking more about this issue, there's a more robust fix possible, 
which doesn't involve moving files to the build folder (which could 
be potentially unreliable, depending on how people build the JDK). In 
fact, the best solution is to leave build.xml where it is, and fix 
the remaining configuration files to point at it. This allows to 
revert all changes in the scripts that set up the project 
configuration (bin/idea.sh for JDK, and make/langtools/build.xml for 
langtools).


For the langtools project a bit more changes were necessary, given 
that in langtools we did not have a 'template' folder - and all 
intellij files were dumped onto the same path. So I had to move the 
configuration langtools files (all but build.xml) under a new 
template folder (located under make/langtools/intellij/make) and 
place build.xml outside it. Then tweak the build.xml script to work 
off this new template folder. These are all small conceptual changes, 
but the impact on the webrev is quite biggie (because of file 
renaming etc.).


I also took the chance to fix some issues with the JDK project ANT 
configuration (see changes in make/idea/template/workspace.xml), as 
the last changes did not update the location of the ant file used 
here - as a result no ant target entries were showing up under the 
Build menu.


Webrev here:

http://cr.openjdk.java.net/~mcimadamore/8209064/

Cheers
Maurizio

Re: RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

[Andrew Haley]

On 08/14/2018 09:24 PM, John Paul Adrian Glaubitz wrote:
> With current versions of qemu (either from git or Debian unstable), you should
> even be able to build OpenJDK natively inside the emulated chroot.

Gosh. Does that mean that, after all these years, they've fixed
the bug that delivered segfault signals to the wrong thread?
:-)

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

Re: RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

[Aleksey Shipilev]

Hi,

Updated webrev, now with regenerated building.html (thanks Erik J.!):
  http://cr.openjdk.java.net/~shade/8208665/webrev.04/

There are also a few formatting changes to make it render correctly.


On 08/14/2018 10:24 PM, John Paul Adrian Glaubitz wrote:
> Thanks for this. This is actually a clever idea and should also work with
> Debian Ports, i.e. the non-release architectures in Debian such as sparc64,
> m68k and sh4. [...]
Yes, it also does not require you to mess with any virtualization during the 
actual build. For all I
know, we can package that chroot into the tarball and seed build machines with 
it. Or even share it
over NFS/CIFS?

> I should give this a shot and if it works, it might be a good idea to add
> the instructions for Debian Ports as well. Since I have some more patches
> for m68k and co in the pipeline, I can actually test it for that ;-).

Yup, please do. I left the placeholder mention that Debian Ports might work for 
other architectures.

> With current versions of qemu (either from git or Debian unstable), you should
> even be able to build OpenJDK natively inside the emulated chroot. In Debian
> Ports, we're heavily making use of qemu-user and qemu-system (for riscv64) to
> build packages which hashelped finding and fixing tons of bugs in qemu (I have
> alone reported countless bugs ;-)).

Oh yes, QEMU with OpenJDK was broken for a long time. Anyhow, people around me 
who used to build/run
OpenJDK in QEMU report substantial build performance losses. The trick with 
qemu-deboostrap
basically gives you native compilation performance, because you still use the 
build compiler to do
most of the compilation work.

-Aleksey

Re: how to install OpenJDK stuff for packaging - DESTDIR support

[pointo1d]

On Thu, 2018-08-23 at 09:48 +0200, Petr Sumbera wrote:


> 
> But not really sure whether following directory structure is
> good enough:
> 
> usr/jvm/openjdk-11
> usr/jvm/openjdk-11/bin
> usr/jvm/openjdk-11/demo
> usr/jvm/openjdk-11/lib
> usr/jvm/openjdk-11/include
> usr/jvm/openjdk-11/jmods
> usr/jvm/openjdk-11/conf
> usr/jvm/openjdk-11/man
> 
> In Solaris for JDK 8 we have:
> 
> usr/jdk/instances/jdk1.8.0
> 
> 


On UNIX/Linux, the conventional install location for such things
is /opt/

Best rgds,
Dave P

--
D.C. Pointon FIAP MBCS | Now I saw, tho' too late, the folly of
07810 645299   | beginning a work before we count the
cost
01782 514815   | and before we judge rightly of our
strength
01730 233886   | to go thro' with  it. Robinson Crusoe

Re: how to install OpenJDK stuff for packaging - DESTDIR support

[Petr Sumbera]

Hi Magnus,

On 23.08.2018 9:14, Magnus Ihse Bursie wrote:

On 2018-08-22 17:13, Petr Sumbera wrote:

Hi all,

I'm now able to build both OpenJDK 10 and 11 (thanks to all who helped 
me!). Now what is the correct way to install it for packaging? For now 
I use following patch (see below). But I wonder how should this be 
done properly.

Hi Petr,

The code path you've found out has not been tested since the early days 
of the current (then "brand new") build system. I've actually been 
thinking from time to time that we should remove it, since it's not 
ordinarily used.


Than I wonder what other distributions do? They probably just pick up 
files they need like here:


http://www.linuxfromscratch.org/blfs/view/cvs/general/openjdk.html

But I don't really know what is need it.


But if you see a point in keeping it, I'm happy to accept patches! :)


Good to know!


Does the installation work fine with the patch below?


It seems to. But I just installed it to build Java itself. Plus also 
tried to build Tomcat and run its test suite.


But not really sure whether following directory structure is good enough:

usr/jvm/openjdk-11
usr/jvm/openjdk-11/bin
usr/jvm/openjdk-11/demo
usr/jvm/openjdk-11/lib
usr/jvm/openjdk-11/include
usr/jvm/openjdk-11/jmods
usr/jvm/openjdk-11/conf
usr/jvm/openjdk-11/man

In Solaris for JDK 8 we have:

usr/jdk/instances/jdk1.8.0

I mean "jdk" is probably better than "jvm"? Maybe I should try to keep 
existing structure.


Thanks!

Petr

Re: how to install OpenJDK stuff for packaging - DESTDIR support

[Magnus Ihse Bursie]

On 2018-08-22 17:13, Petr Sumbera wrote:

Hi all,

I'm now able to build both OpenJDK 10 and 11 (thanks to all who helped 
me!). Now what is the correct way to install it for packaging? For now 
I use following patch (see below). But I wonder how should this be 
done properly.

Hi Petr,

The code path you've found out has not been tested since the early days 
of the current (then "brand new") build system. I've actually been 
thinking from time to time that we should remove it, since it's not 
ordinarily used.


But if you see a point in keeping it, I'm happy to accept patches! :)

Does the installation work fine with the patch below?

/Magnus



Thanks,

Petr

--- jdk/make/Install.gmk
+++ jdk/make/Install.gmk
@@ -35,9 +35,9 @@
 install:
    echo Installing jdk image into 
$(INSTALL_PREFIX)/jvm/$(INSTALLDIR)
    echo and creating $(words $(BINARIES)) links from 
$(INSTALL_PREFIX)/bin into the jdk.

-   $(MKDIR) -p $(INSTALL_PREFIX)/jvm/$(INSTALLDIR)
-   $(RM) -r $(INSTALL_PREFIX)/jvm/$(INSTALLDIR)/*
-   $(CP) -rp $(JDK_IMAGE_DIR)/* $(INSTALL_PREFIX)/jvm/$(INSTALLDIR)
-   $(MKDIR) -p $(INSTALL_PREFIX)/bin
-   $(RM) $(addprefix $(INSTALL_PREFIX)/bin/, $(BINARIES))
-   $(foreach b, $(BINARIES), $(LN) -s 
$(INSTALL_PREFIX)/jvm/$(INSTALLDIR)/bin/$b $(INSTALL_PREFIX)/bin/$b 
&&) true

+   $(MKDIR) -p $(DESTDIR)$(INSTALL_PREFIX)/jvm/$(INSTALLDIR)
+   $(RM) -r  $(DESTDIR)$(INSTALL_PREFIX)/jvm/$(INSTALLDIR)/*
+   $(CP) -rp  $(JDK_IMAGE_DIR)/* 
$(DESTDIR)$(INSTALL_PREFIX)/jvm/$(INSTALLDIR)

+   $(MKDIR) -p  $(DESTDIR)$(INSTALL_PREFIX)/bin
+   $(RM) $(addprefix  $(DESTDIR)$(INSTALL_PREFIX)/bin/, $(BINARIES))
+   $(foreach b, $(BINARIES), $(LN) -s 
$(INSTALL_PREFIX)/jvm/$(INSTALLDIR)/bin/$b 
$(DESTDIR)$(INSTALL_PREFIX)/bin/$b &&) true