Hi,
This is my first review request so apologies for any missteps or
inconsistencies.
JBS: https://bugs.openjdk.java.net/browse/JDK-8244966
Webrev: http://cr.openjdk.java.net/~phh/8244966/webrev.01/
Please review this change that adds the .vscode directory to .hgignore, similar
to the .idea di
Hi, Erik
Thanks for test/review.
On 5/15/20 1:48 PM, Erik Joelsson wrote:
I tried a variant of this patch with a 32 bit intel build (server only
to get the cds archive generation enabled). It makes the build work as
expected.
The conditions on line 120 and 125 are unnecessary and just add
Hi Magnus,
I can confirm that this version of the file successfully builds on ARM32 (can’t
speak for other platforms):
https://pici.beachhub.io/#/jdk-marchof/20200515-213321
Thanks for the quick fix!
-marc
> On 15. May 2020, at 17:05, Magnus Ihse Bursie
> wrote:
>
>
I tried a variant of this patch with a 32 bit intel build (server only
to get the cds archive generation enabled). It makes the build work as
expected.
The conditions on line 120 and 125 are unnecessary and just add clutter
IMO. Otherwise good.
/Erik
On 2020-05-15 11:29, Yumin Qi wrote:
M
Looks good.
/Erik
On 2020-05-15 11:16, Magnus Ihse Bursie wrote:
After JDK-8239450 (Overhaul JVM feature handling in configure), the
Hotspot Visual Studio project creator did not properly pick up
compiler defines.
This turned out to be due to it hard-coding JVM_VARIANT to client
(which is m
Magnus,
Thanks. Let's wait for the result of your patch.
I updated my webrev as your suggestion.
Thanks
Yumin
On 5/15/20 11:19 AM, Magnus Ihse Bursie wrote:
On 2020-05-15 19:49, Yumin Qi wrote:
Hi,
Please review the xsmall change for
bug: 8245070: https://bugs.openjdk.java.net/brows
On 2020-05-15 19:49, Yumin Qi wrote:
Hi,
Please review the xsmall change for
bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070
webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/
The change of 8245070 broke build for 32 bits, since no compressed
oops on 32 bi
There is a copy/paste caused mismatch:
On 5/15/20 10:49 AM, Yumin Qi wrote:
Hi,
Please review the xsmall change for
bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070
webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/
The change of 8245070 broke build for 32
After JDK-8239450 (Overhaul JVM feature handling in configure), the
Hotspot Visual Studio project creator did not properly pick up compiler
defines.
This turned out to be due to it hard-coding JVM_VARIANT to client (which
is most often not built), and thus it got not JVM features for client,
Hi,
Please review the xsmall change for
bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070
webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/
The change of 8245070 broke build for 32 bits, since no compressed
oops on 32 bits. Guard the change for 64 bits only.
Dear all,
Thank you very much for your comments.
I would like to be able to upgrade from my outdated Java 7u91 (x86 32-bit)
to at least Java 12, but I have some device driver libraries that are x86
32-bit only and I can not instantiate them anymore via JNI with the x86
64-bit version.
Regards,
A
Looks good.
/Erik
On 2020-05-15 09:24, Magnus Ihse Bursie wrote:
Unfortunately JDK-8245046 was not enough to be able to produce the
Hotspot VS project file. With this patch, the generation has been
tested and verified by one of our Windows developers.
Bug: https://bugs.openjdk.java.net/brows
Unfortunately JDK-8245046 was not enough to be able to produce the
Hotspot VS project file. With this patch, the generation has been tested
and verified by one of our Windows developers.
Bug: https://bugs.openjdk.java.net/browse/JDK-8245119
Patch inline:
diff --git a/make/Main.gmk b/make/Main.g
I think you are right. I don't remember even JDK 7 having a 32 bit version.
There may have been some unused partial support to create one, but we
never shipped such a thing - nor were there internal 32 bit builds.
Also macOS 10.15 doesn't support 32 bit applications.
So when 10.14 goes EOSL in ab
On 2020-05-15 17:33, Erik Joelsson wrote:
Hello Andre,
As far as I'm aware, support for 32 bit on Macosx has not been
supported by anyone for a very long time. I would assume it far from
trivial to get it to work.
In fact, I wonder if there *ever* have been 32-bit macOS support in
OpenJDK. I
Hello Andre,
As far as I'm aware, support for 32 bit on Macosx has not been supported
by anyone for a very long time. I would assume it far from trivial to
get it to work.
/Erik
On 2020-05-14 17:17, Andre Kovacs wrote:
Dear members,
For compatibility reasons with older 32bit i386 architect
Dear members,
For compatibility reasons with older 32bit i386 architecture dylibs via
JNI, I'm trying to build a 32bit version of jdk12u on Mac OS X.
I'm using the following configure command:
"bash configure
--with-boot-jdk=/Library/Java/JavaVirtualMachines/openjdk12/Contents/Home
--with-target-
Dear Magnus,
sure. But for whatever reason the patch does not work for me.
Can you please send me the full file?
Sry,
-marc
> On 15. May 2020, at 13:58, Magnus Ihse Bursie
> wrote:
>
> In theory, this patch should work, but I cannot verify it. Marc, can you try
> it out?
>
> diff --git a/
Looks good.
/Erik
On 2020-05-15 04:39, Magnus Ihse Bursie wrote:
Unfortunately, the fixes for WSL changed the behavior so the
autodetection of toolchain does not work on cygwin (but providing
devkit does work, that's why I did not discover this).
Windows and unix emulation environments are r
Looks good. Nice change.
/Erik
On 2020-05-15 04:13, Magnus Ihse Bursie wrote:
Unify and clean up windows environment output in configure
Bug: https://bugs.openjdk.java.net/browse/JDK-8245096
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8245096-better-windows-version/webrev.01
/Magnus
In theory, this patch should work, but I cannot verify it. Marc, can you
try it out?
diff --git a/make/Images.gmk b/make/Images.gmk
--- a/make/Images.gmk
+++ b/make/Images.gmk
@@ -147,31 +147,33 @@
JRE_TARGETS += $(gen_cds_archive_jre)
- $(eval $(call SetupExecute, gen_cds_nocoops_archive_
Unfortunately, the fixes for WSL changed the behavior so the
autodetection of toolchain does not work on cygwin (but providing devkit
does work, that's why I did not discover this).
Windows and unix emulation environments are really a whack-a-mole... :(
Bug: https://bugs.openjdk.java.net/brows
Unify and clean up windows environment output in configure
Bug: https://bugs.openjdk.java.net/browse/JDK-8245096
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8245096-better-windows-version/webrev.01
/Magnus
Thanks Marc!
On 15/05/2020 07:18, David Holmes wrote:
https://bugs.openjdk.java.net/browse/JDK-8245070
David
On 15/05/2020 4:10 pm, David Holmes wrote:
Hi Marc,
I will file a bug for this. Thanks for the report.
David
On 15/05/2020 4:04 pm, Marc Hoffmann wrote:
Dear Rory, dear all,
JaCoC
Yeah, it definitely is an issue with path conversion on WSL. jtreg is
jumping back and forth between the Windows and the Linux world. For
instance, it sets
TESTSRC=C:/localdata/hg/sandbox-ALT/open/test/jdk/java/lang/Class/forName
using Windows paths, but then calls
wsl.exe \
sh
/mnt
On 2020-05-14 19:00, Jonathan Gibbons wrote:
Separate from this RFR, jtreg supports WSL (or is supposed to!) and so
I wonder if you have looked at using WSL in the run-tests framework.
I just did "make test-tier1", and got this:
==
Test summary
==
26 matches
Mail list logo