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
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,
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
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:
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
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
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
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
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,
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
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
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:
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
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,
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
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
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:
>
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
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:
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:
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
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 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,
JaCoCo project here. It looks like that OpenJDK build for jdk main dev branch
(Java 15) is broken for us on ARM32 since commit
changeset
Dear Rory, dear all,
JaCoCo project here. It looks like that OpenJDK build for jdk main dev branch
(Java 15) is broken for us on ARM32 since commit
changeset 59296:e25b21095e86
8242524: Use different default CDS archives depending on UseCompressOops
Reviewed-by: erikj, iklam,
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,
JaCoCo project here. It looks like that OpenJDK build for
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
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
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,
29 matches
Mail list logo
