Thanks Magnus!
David
On 5/12/2017 5:41 PM, Magnus Ihse Bursie wrote:
On 2017-12-05 07:06, David Holmes wrote:
Bug is closed but problem is simply that in jprt.properties we only
utilise the test-image and set the -nativepath for a specific
configuration of tests. Using "-testset svc" we can h
On 2017-12-05 07:06, David Holmes wrote:
Bug is closed but problem is simply that in jprt.properties we only
utilise the test-image and set the -nativepath for a specific
configuration of tests. Using "-testset svc" we can hit failures
because it is not one of those configurations. This fix sim
On 2017-12-05 06:59, David Holmes wrote:
Magnus,
It seems these changes have broken all Windows builds:
Oh f*ck. :-(
I didn't test my re-addition of the Copy-jdk.accessibility.gmk file
properly. :(
I opened https://bugs.openjdk.java.net/browse/JDK-8193045.
/Magnus
Copying support/module
Bug is closed but problem is simply that in jprt.properties we only
utilise the test-image and set the -nativepath for a specific
configuration of tests. Using "-testset svc" we can hit failures because
it is not one of those configurations. This fix simply adds it:
webrev: http://cr.openjdk.j
Magnus,
It seems these changes have broken all Windows builds:
Copying support/modules_include/jdk.accessibility/win32/bridge
/usr/bin/cp -fP
'/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge'
'/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-
Erik
Looks good to me as well.
Tim
On 12/04/17 15:54, mandy chung wrote:
Looks good to me.
Mandy
On 12/4/17 3:48 PM, Erik Joelsson wrote:
We have a race when building jdk.rmic.interim. This is caused by
CompileInterimLangtools.gmk and CompileInterimRmic.gmk using the same
modular output dir
On 5/12/2017 9:59 AM, Magnus Ihse Bursie wrote:
On 2017-12-05 00:28, David Holmes wrote:
Hi Magnus,
There may be a further wart here to resolve.
But of course...
From the "bump the classfile version to 54" thread on jdk-dev:
---
Don't you also need to update:
jdk/src/java.b
+1
I tested this out with the class file version change patch and the build no
longer fails.
Thanks,
Paul.
> On 4 Dec 2017, at 15:21, Erik Joelsson wrote:
>
> To be able to bump the classfile version in JDK 10, we need to be able to
> build certain jar files using the newly built jar tool du
On 12/4/17 3:59 PM, Magnus Ihse Bursie wrote:
And classfile_constants.h is also distributed with the image. I am
unsure of the intent/history. To play it safe i will just bump the
number.
Hmmm - that seems wrong. jvm.h is not an exported external interface
AFAIK. And we just moved it so I do
On 2017-12-05 00:21, Erik Joelsson wrote:
To be able to bump the classfile version in JDK 10, we need to be able
to build certain jar files using the newly built jar tool during the
build. This patch enables overriding of the jar cmd in the build.
Bug: https://bugs.openjdk.java.net/browse/JDK-
On 2017-12-05 00:48, Erik Joelsson wrote:
We have a race when building jdk.rmic.interim. This is caused by
CompileInterimLangtools.gmk and CompileInterimRmic.gmk using the same
modular output directory ($(BUILDTOOLS_OUTPUTDIR)/interim_modules),
and then makefiles running javac from interim lang
On 2017-12-05 00:28, David Holmes wrote:
Hi Magnus,
There may be a further wart here to resolve.
But of course...
From the "bump the classfile version to 54" thread on jdk-dev:
---
Don't you also need to update:
jdk/src/java.base/share/native/include/classfile_constants.h
>>
Looks good to me.
Mandy
On 12/4/17 3:48 PM, Erik Joelsson wrote:
We have a race when building jdk.rmic.interim. This is caused by
CompileInterimLangtools.gmk and CompileInterimRmic.gmk using the same
modular output directory ($(BUILDTOOLS_OUTPUTDIR)/interim_modules),
and then makefiles runnin
We have a race when building jdk.rmic.interim. This is caused by
CompileInterimLangtools.gmk and CompileInterimRmic.gmk using the same
modular output directory ($(BUILDTOOLS_OUTPUTDIR)/interim_modules), and
then makefiles running javac from interim langtools at the same time as
CompileInterimRm
Hi Magnus,
There may be a further wart here to resolve. From the "bump the
classfile version to 54" thread on jdk-dev:
---
Don't you also need to update:
jdk/src/java.base/share/native/include/classfile_constants.h
#define JVM_CLASSFILE_MAJOR_VERSION 53
>>> I can
This looks fine to me.
Mandy
On 12/4/17 3:21 PM, Erik Joelsson wrote:
To be able to bump the classfile version in JDK 10, we need to be able
to build certain jar files using the newly built jar tool during the
build. This patch enables overriding of the jar cmd in the build.
Bug: https://bugs
To be able to bump the classfile version in JDK 10, we need to be able
to build certain jar files using the newly built jar tool during the
build. This patch enables overriding of the jar cmd in the build.
Bug: https://bugs.openjdk.java.net/browse/JDK-8192771
Webrev: http://cr.openjdk.java.net
Thanks, Magnus! That works for me.
Best regards,
Vladimir Ivanov
On 12/1/17 11:33 PM, Magnus Ihse Bursie wrote:
You cannot disable features. However, you can create your own complete
set of features. Use --with-jvm-variants=custom. The custom variant
starts out with a comletely empty set of fe
Looks good.
/Erik
On 2017-12-04 12:31, Magnus Ihse Bursie wrote:
There's a bunch of some loose odds and ends in the testing which has
not yet been supported by the run-test framework. These are:
* make test-make
* make test-hotspot-internal
* make test-failure-handler
This patch adds these a
Looks good.
/Erik
On 2017-12-04 12:40, Magnus Ihse Bursie wrote:
On 2017-12-04 19:17, mandy chung wrote:
On 12/4/17 9:33 AM, Erik Joelsson wrote:
Hello Magnus,
The -copy targets are currently only being generated for
modules that have make/copy/Copy-.gmk makefiles present. By
removing m
On 12/4/17 12:40 PM, Magnus Ihse Bursie wrote:
Technically, it's of course possible. But it does not fit very well
with the current DeclareRecipesForPhase. I agree with Erik, that for
now the reasonable approach is to have files that only include
CopyCommon. We can consider for future updates
On 2017-12-04 19:17, mandy chung wrote:
On 12/4/17 9:33 AM, Erik Joelsson wrote:
Hello Magnus,
The -copy targets are currently only being generated for
modules that have make/copy/Copy-.gmk makefiles present. By
removing make/copy/Copy-jdk.accessibility.gmk and
make/copy/Copy-jdk.jdwp.agen
There's a bunch of some loose odds and ends in the testing which has not
yet been supported by the run-test framework. These are:
* make test-make
* make test-hotspot-internal
* make test-failure-handler
This patch adds these as normal run-test test targets.
Bug: https://bugs.openjdk.java.net/b
OK .. approved.
-phil.
On 11/28/17, 2:11 PM, Sergey Bylokhov wrote:
On 28/11/2017 13:38, Phil Race wrote:
I see this opens was moved to platform-specific code ... 115 opens
com.sun.java.swing.plaf.windows to
116 jdk.jconsole;
So jdk.jconsole definitely accesses this only on Windows ?
Its
Looks good.
/Erik
On 2017-12-04 10:05, Magnus Ihse Bursie wrote:
The current implementation of gtest in run-test will use just the
server variant of gtest. This is different from the old test/Makefile
implementation, which used all available variants. (Or rather, those
of server, client and
On 12/4/17 9:33 AM, Erik Joelsson wrote:
Hello Magnus,
The -copy targets are currently only being generated for
modules that have make/copy/Copy-.gmk makefiles present. By
removing make/copy/Copy-jdk.accessibility.gmk and
make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer create
The current implementation of gtest in run-test will use just the server
variant of gtest. This is different from the old test/Makefile
implementation, which used all available variants. (Or rather, those of
server, client and minimal that were present.) The run-test
implementation should do th
Hello Magnus,
The -copy targets are currently only being generated for modules
that have make/copy/Copy-.gmk makefiles present. By removing
make/copy/Copy-jdk.accessibility.gmk and
make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer created
so the logic in CopyCommon will not be ex
Looks good.
/Erik
On 2017-12-04 03:45, Magnus Ihse Bursie wrote:
The output "Building configuration X (matching Y)" is not needed when
using the build system at the default log level because the build
system always writes "Building target 'Z' in configuration 'Y'", so
the user already knows
Looks good.
/Erik
On 2017-12-04 03:30, Magnus Ihse Bursie wrote:
On 2017-12-04 12:14, Magnus Ihse Bursie wrote:
I retract this review for now. The issue turned out to be not so
simple as this. We *are* able to build with older versions of zlib.
The dependency for inflateValidate arises from
+1
-phil.
On 12/04/2017 02:18 AM, Magnus Ihse Bursie wrote:
By oversight, when the external fontconfig was introduced in
JDK-8170681, spec.gmk.in was not updated to actually include
FONTCONFIG_CFLAGS (but it was properly exported from lib-fontconfig.m4
and included in the AWT makefile).
Bug
Looks good.
/Erik
On 2017-12-04 02:18, Magnus Ihse Bursie wrote:
By oversight, when the external fontconfig was introduced in
JDK-8170681, spec.gmk.in was not updated to actually include
FONTCONFIG_CFLAGS (but it was properly exported from lib-fontconfig.m4
and included in the AWT makefile).
On 2017-12-04 13:56, David Holmes wrote:
On 4/12/2017 10:44 PM, Magnus Ihse Bursie wrote:
On 2017-12-04 12:17, David Holmes wrote:
Hi Magnus,
On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
JDK-8190484 was created as a follow-up bug to the unification of
the duplicated jvm.h, jvm_md.h and jmm
On 4/12/2017 10:44 PM, Magnus Ihse Bursie wrote:
On 2017-12-04 12:17, David Holmes wrote:
Hi Magnus,
On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
JDK-8190484 was created as a follow-up bug to the unification of the
duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper
location of t
On 2017-12-04 12:17, David Holmes wrote:
Hi Magnus,
On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
JDK-8190484 was created as a follow-up bug to the unification of the
duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper
location of these files. This has now been decided to be
hots
The output "Building configuration X (matching Y)" is not needed when
using the build system at the default log level because the build system
always writes "Building target 'Z' in configuration 'Y'", so the user
already knows the configuration being used.
Bug: https://bugs.openjdk.java.net/br
On 2017-12-04 12:14, Magnus Ihse Bursie wrote:
I retract this review for now. The issue turned out to be not so
simple as this. We *are* able to build with older versions of zlib.
The dependency for inflateValidate arises from the bundled libpng; a
system libpng does not necessary have that iss
Hi Magnus,
On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
JDK-8190484 was created as a follow-up bug to the unification of the
duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location
of these files. This has now been decided to be hotspot/share/include
and hotspot/os/$OS/includ
I retract this review for now. The issue turned out to be not so simple
as this. We *are* able to build with older versions of zlib. The
dependency for inflateValidate arises from the bundled libpng; a system
libpng does not necessary have that issue.
/Magnus
On 2017-12-04 11:57, Magnus Ihse
JDK-8190484 was created as a follow-up bug to the unification of the
duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper location
of these files. This has now been decided to be hotspot/share/include
and hotspot/os/$OS/include, respectively.
This patch moves the relevant files there,
If we're using the system zlib instead of the bundled zlib, we should
verify that it includes all relevant functions. We now rely on the
inflateValidate() function, which was introduced in zlib 1.2.9 which is
very recent. This patch adds a test to the system zlib to verify this
and to fail fast
By oversight, when the external fontconfig was introduced in
JDK-8170681, spec.gmk.in was not updated to actually include
FONTCONFIG_CFLAGS (but it was properly exported from lib-fontconfig.m4
and included in the AWT makefile).
Bug: https://bugs.openjdk.java.net/browse/JDK-8192854
Patch inline
42 matches
Mail list logo
