RE: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects
Hi, Thanks, Volker for backporting this to JDK11 and thanks Andrew for reviewing it. > On 30/12/2019 20:18, Volker Simonis wrote: > > Hi, > > I'd like to downport the support for Visual Studio Code project > > creation to 11u. I think we will have to support 11u for quite some > > years and it makes sense to have as good as possible tool support in > > 11u as well. > > I just came across this proposal in the process of backporting > JDK-8232748: "Build static versions of certain JDK libraries". The only > hunk of that changeset which isn't a simple context difference is that > which applies to JdkNativeCompilation.gmk and the FindLib & > FindStaticLib rules it introduces. > > I was going to just drop this hunk, as I didn't see any reason to > backport JDK-8210459, but then I saw your existing RFR referenced on the > bug. If JDK-8210459 is to be backported, I thus need this in place > before posting JDK-8232748 for review. Thanks for waiting, Andrew. I'll approve JDK-8210459 now in order to get it pushed to unblock your work on JDK-8210459. > > Finally, I've added an additional fix to this last change, whch fixes > > the make tests (i.e. "make test-make"). These tests are currently > > broken in jdk11u. They have been broken by JDK-8212028 (which has > > already been downported to jdk11u) and fixed in jdk 12 as part of > > "8210958: Rename "make run-test" to "make test"" (which hasn't been > > downported yet and probably won't be donwported at all). Because the > > fix is trivial (that's why it was done as part of 8210958 without an > > extra bug ID) and because I wanted to run "make test-make" in jdk11u > > as well to verify my changes, I've decided to downport this fix as > > part of 8223678: > > > > diff -r 8599975f5b33 test/make/TestMakeBase.gmk > > --- a/test/make/TestMakeBase.gmkTue Feb 12 08:40:43 2019 +0100 > > +++ b/test/make/TestMakeBase.gmkMon Dec 23 22:10:46 2019 +0100 > > KWBASE := > APA=banan;GURKA=tomat;COUNT=1%202%203%204%205;SUM=1+2+3+4+5 > ;MANY_WORDS=I > > have the best words. > > > > $(eval $(call ParseKeywordVariable, KWBASE, \ > > -KEYWORDS := APA GURKA SUM, \ > > +SINGLE_KEYWORDS := APA GURKA SUM, \ > > STRING_KEYWORDS := COUNT MANY_WORDS, \ > > )) > > > > @@ -364,7 +376,7 @@ > > KWBASE_WEIRD := ;;APA=banan;;;GURKA=apelsin;APA=skansen;; > > > > $(eval $(call ParseKeywordVariable, KWBASE_WEIRD, \ > > -KEYWORDS := APA GURKA SUM, \ > > +SINGLE_KEYWORDS := APA GURKA SUM, \ > > STRING_KEYWORDS := COUNT, \ > > )) > > > > I agree it doesn't make sense to backport JDK-8210958, as that's a major > change to the test infrastructure. However, I think this warrants its > own 11u bug rather than being smuggled in under JDK-8223678. Otherwise, > you're just mirroring the same problem that was created by mixing this > in with JDK-8210958. An independent bug can describe the breakage and > link to the original issue that caused it. Hm, I think Volker's way of adding this trivial correction to the backport of 8223678 is okay. But, of course a separate bug could also be a good way to document this fix. Maybe we need a tiebreaker here? So I'll approve the series of backports now, except for JDK-8223678. Cheers Christoph
Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite
On 2020-02-21 17:26, Erik Joelsson wrote: Baring any component specific opinions on the suggested descriptions of each feature, the patch looks good to me. Ok, I'm sending a copy of this to hotspot-dev as well for the HS guys to bikeshed about the descriptions. I'll get back in a few days when the dust has settled... :-) /Magnus /Erik On 2020-02-21 07:05, Magnus Ihse Bursie wrote: The JVM feature rewrite was actually somewhat of a step backwards in terms of presenting information for the user what different configure arguments do. I've compensated for this by making it far better! :) Now we get a list like this: aot enable ahead of time compilation (AOT) cds enable class data sharing (CDS) compiler1 enable hotspot compiler C1 compiler2 enable hotspot compiler C2 dtrace enable dtrace support epsilongc include the epsilon (no-op) garbage collector g1gc include the G1 garbage collector graal enable Graal (jdk.internal.vm.compiler) jfr enable Java Flight Recorder (JFR) jni-check enable -Xcheck:jni support jvmci enable JVM Compiler Interface (JVMCI) jvmti enable Java Virtual Machine Tool Interface (JVM TI) link-time-opt enable link time optimization management enable java.lang.management API support minimal support building variant 'minimal' nmt include native memory tracking (NMT) parallelgc include the parallel garbage collector serialgc include the serial garbage collector services enable diagnostic services and client attaching shenandoahgc include the Shenandoah garbage collector static-build build static library instead of dynamic vm-structs export JVM structures to the Serviceablility Agent zero support building variant 'zero' zgc include the ZGC garbage collector Also, I missed using the recommended m4_ prefix on some m4 functions. This patch also corrects this. Bug: https://bugs.openjdk.java.net/browse/JDK-8239789 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239789-jvm-features-followup/webrev.01 /Magnus
Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite
On 2020-02-21 17:03, John Paul Adrian Glaubitz wrote: On 2/21/20 4:36 PM, Magnus Ihse Bursie wrote: On 2020-02-21 16:15, Erik Gahlin wrote: jfr should be JDK Flight Recorder. Thanks, I should have checked and not guessed. :) I updated the code but will not send out a new webrev. Shouldn't "deprecated-ports" be parts of that list as well? No, it's not handled as a JVM feature. Not all configure flags affecting the build are considered JVM features -- only the ones that affects what (and in certain cases how) the JVM is built. The configure flags all have different purposes. I'm thinking of them like roughly falling into these different buckets: 1) external dependencies/tools Examples are: native compiler, boot jdk, external libraries and header files -- stuff that we need to be able to build, and that we need to locate on the build system. 2) build behavior/performance Examples are: setting default make target or number of jobs, support for precompiled headers, ccache, debug symbol output, 3) customization Examples are: version string, vendor name, macOS bundle base name, copyright year, cacerts 4) testing and other non-build settings Examples are: hotspot gtest, jtreg, etc 5) product features Examples are: JVM features (dtrace, jvmti, jfr, etc), static build, unlimited crypto, etc Bypassing the check for deprecated ports belongs to bucket 2. JVM features belong to bucket 5. /Magnus
Re: RFR: JDK-8239794 Move -Os from JVM feature 'minimal' to new feature 'opt-size'
Looks good to me. /Erik On 2020-02-21 08:13, Magnus Ihse Bursie wrote: Prior to JDK-8239450, it was possible to explicitly set the JVM feature 'minimal', even when building variant server. The reason for doing this was to get the code in JvmFeatures.gmk that sets JVM_OPTIMIZATION := SIZE (except for a handful of files). Since this functionality is important in itself (and it has been requested by users in the community), it should be controlled by a separate feature, instead of just as a part of the 'minimal' feature, which signals that the minimal JVM variant is being built. However, when looking into it, I noticed several aspects of the old code that I wanted to address. First of all, the old code had the size optimization silently ignored, if also 'link-time-opt' was enabled. This does not make any sense, since it is completely possible to do both. This code was written in the new Hotspot build system as a way to mimick the old Hotspot build system. I'm guessing that this was initially introduced as a way to enable the size optimization when building minimal, except for arm-32 systems, which were the only system to have link-time-opt enabled. After some head scratching, I implemented the logic in the following way: * If opt-size is enabled, the JVM_OPTIMIZATION := SIZE is always performed, regardless of any other features. * And contrary, link-time-opt can be enabled/disabled independent on opt-size * When building minimal on arm-32, opt-size is not enabled by default, but link-time-opt is (as it was before) * When building minimal on any other platform, opt-size is enabled by default, but link-time-opt is not (as it was before) * When building any other variant, opt-size is disabled by default This makes standard builds of minimal with no extra features enabled/disabled behave the same as before, while giving the maximum of flexibility to change this. But I'd like to get input from someone in the Hotspot team that this is a sound approach. Also, this has apparently never been tested by any other compiler than gcc and/or clang, since we explicitly add the compiler flag -fno-optimize-sibling-calls. I wrapped this in a compiler check. Note that this patch is based on JDK-8239789 (Follow-up on JVM feature rewrite). Bug: https://bugs.openjdk.java.net/browse/JDK-8239794 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239794-create-opt-size-jvm-feature/webrev.01 /Magnus
Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite
Hi, I would suggest "Java Flight Recorder" instead of "JDK Flight Recorder" Regards, Roger On 2/21/20 10:36 AM, Magnus Ihse Bursie wrote: On 2020-02-21 16:15, Erik Gahlin wrote: jfr should be JDK Flight Recorder. Thanks, I should have checked and not guessed. :) I updated the code but will not send out a new webrev. /Magnus Erik On 2020-02-21 16:05, Magnus Ihse Bursie wrote: The JVM feature rewrite was actually somewhat of a step backwards in terms of presenting information for the user what different configure arguments do. I've compensated for this by making it far better! :) Now we get a list like this: aot enable ahead of time compilation (AOT) cds enable class data sharing (CDS) compiler1 enable hotspot compiler C1 compiler2 enable hotspot compiler C2 dtrace enable dtrace support epsilongc include the epsilon (no-op) garbage collector g1gc include the G1 garbage collector graal enable Graal (jdk.internal.vm.compiler) jfr enable Java Flight Recorder (JFR) jni-check enable -Xcheck:jni support jvmci enable JVM Compiler Interface (JVMCI) jvmti enable Java Virtual Machine Tool Interface (JVM TI) link-time-opt enable link time optimization management enable java.lang.management API support minimal support building variant 'minimal' nmt include native memory tracking (NMT) parallelgc include the parallel garbage collector serialgc include the serial garbage collector services enable diagnostic services and client attaching shenandoahgc include the Shenandoah garbage collector static-build build static library instead of dynamic vm-structs export JVM structures to the Serviceablility Agent zero support building variant 'zero' zgc include the ZGC garbage collector Also, I missed using the recommended m4_ prefix on some m4 functions. This patch also corrects this. Bug: https://bugs.openjdk.java.net/browse/JDK-8239789 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239789-jvm-features-followup/webrev.01 /Magnus
Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite
Baring any component specific opinions on the suggested descriptions of each feature, the patch looks good to me. /Erik On 2020-02-21 07:05, Magnus Ihse Bursie wrote: The JVM feature rewrite was actually somewhat of a step backwards in terms of presenting information for the user what different configure arguments do. I've compensated for this by making it far better! :) Now we get a list like this: aot enable ahead of time compilation (AOT) cds enable class data sharing (CDS) compiler1 enable hotspot compiler C1 compiler2 enable hotspot compiler C2 dtrace enable dtrace support epsilongc include the epsilon (no-op) garbage collector g1gc include the G1 garbage collector graal enable Graal (jdk.internal.vm.compiler) jfr enable Java Flight Recorder (JFR) jni-check enable -Xcheck:jni support jvmci enable JVM Compiler Interface (JVMCI) jvmti enable Java Virtual Machine Tool Interface (JVM TI) link-time-opt enable link time optimization management enable java.lang.management API support minimal support building variant 'minimal' nmt include native memory tracking (NMT) parallelgc include the parallel garbage collector serialgc include the serial garbage collector services enable diagnostic services and client attaching shenandoahgc include the Shenandoah garbage collector static-build build static library instead of dynamic vm-structs export JVM structures to the Serviceablility Agent zero support building variant 'zero' zgc include the ZGC garbage collector Also, I missed using the recommended m4_ prefix on some m4 functions. This patch also corrects this. Bug: https://bugs.openjdk.java.net/browse/JDK-8239789 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239789-jvm-features-followup/webrev.01 /Magnus
Re: RFR: JDK-8239708 Split basics.m4 into basic.m4 and util.m4
Looks good, nice restructure! /Erik On 2020-02-21 02:39, Magnus Ihse Bursie wrote: The file basics.m4 in make/autoconf is mixing two different concerns: 1) Providing utility/helper functions to the rest of the autoconf files 2) Doing basic or initial setup that does not belong elsewhere. It should be split into two parts, so these different concerns are clearly separated. Furthermore, the naming has not followed our standards. The functions are prefixed "BASIC_" but the file is named "basics.m4". I propose to keep the prefix and drop the plural "s" from the file name. Bug: https://bugs.openjdk.java.net/browse/JDK-8239708 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239708-split-out-util-m4/webrev.01 /Magnus
RFR: JDK-8239794 Move -Os from JVM feature 'minimal' to new feature 'opt-size'
Prior to JDK-8239450, it was possible to explicitly set the JVM feature 'minimal', even when building variant server. The reason for doing this was to get the code in JvmFeatures.gmk that sets JVM_OPTIMIZATION := SIZE (except for a handful of files). Since this functionality is important in itself (and it has been requested by users in the community), it should be controlled by a separate feature, instead of just as a part of the 'minimal' feature, which signals that the minimal JVM variant is being built. However, when looking into it, I noticed several aspects of the old code that I wanted to address. First of all, the old code had the size optimization silently ignored, if also 'link-time-opt' was enabled. This does not make any sense, since it is completely possible to do both. This code was written in the new Hotspot build system as a way to mimick the old Hotspot build system. I'm guessing that this was initially introduced as a way to enable the size optimization when building minimal, except for arm-32 systems, which were the only system to have link-time-opt enabled. After some head scratching, I implemented the logic in the following way: * If opt-size is enabled, the JVM_OPTIMIZATION := SIZE is always performed, regardless of any other features. * And contrary, link-time-opt can be enabled/disabled independent on opt-size * When building minimal on arm-32, opt-size is not enabled by default, but link-time-opt is (as it was before) * When building minimal on any other platform, opt-size is enabled by default, but link-time-opt is not (as it was before) * When building any other variant, opt-size is disabled by default This makes standard builds of minimal with no extra features enabled/disabled behave the same as before, while giving the maximum of flexibility to change this. But I'd like to get input from someone in the Hotspot team that this is a sound approach. Also, this has apparently never been tested by any other compiler than gcc and/or clang, since we explicitly add the compiler flag -fno-optimize-sibling-calls. I wrapped this in a compiler check. Note that this patch is based on JDK-8239789 (Follow-up on JVM feature rewrite). Bug: https://bugs.openjdk.java.net/browse/JDK-8239794 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239794-create-opt-size-jvm-feature/webrev.01 /Magnus
Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite
On 2/21/20 4:36 PM, Magnus Ihse Bursie wrote: > On 2020-02-21 16:15, Erik Gahlin wrote: >> jfr should be JDK Flight Recorder. > Thanks, I should have checked and not guessed. :) > > I updated the code but will not send out a new webrev. Shouldn't "deprecated-ports" be parts of that list as well? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFR [jdk11]: 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3
Looks good! Thanks, Volker On Fri, Feb 21, 2020 at 2:50 PM Baesken, Matthias wrote: > > Hello, please review this small downport of 8201349 . > Reason is that we run into warnings as errors, when building jdk11 on Linux > with gcc-7.X and with-zlib=bundled . > This adds the compiler options > > -Wno-unused-function -Wno-implicit-fallthrough > > To some compilations e.g. zlib-files ; these 2 flags are at least supported > with gcc-4.7 , gcc-4.8 ,gcc-7 and gcc-8 . > > > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8201349 > > jdk/jdk webrev : > > https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084 > > > adjusted Jdk11 webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201349.0_jdk11/ > > > Thanks, Matthias
Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite
On 2020-02-21 16:15, Erik Gahlin wrote: jfr should be JDK Flight Recorder. Thanks, I should have checked and not guessed. :) I updated the code but will not send out a new webrev. /Magnus Erik On 2020-02-21 16:05, Magnus Ihse Bursie wrote: The JVM feature rewrite was actually somewhat of a step backwards in terms of presenting information for the user what different configure arguments do. I've compensated for this by making it far better! :) Now we get a list like this: aot enable ahead of time compilation (AOT) cds enable class data sharing (CDS) compiler1 enable hotspot compiler C1 compiler2 enable hotspot compiler C2 dtrace enable dtrace support epsilongc include the epsilon (no-op) garbage collector g1gc include the G1 garbage collector graal enable Graal (jdk.internal.vm.compiler) jfr enable Java Flight Recorder (JFR) jni-check enable -Xcheck:jni support jvmci enable JVM Compiler Interface (JVMCI) jvmti enable Java Virtual Machine Tool Interface (JVM TI) link-time-opt enable link time optimization management enable java.lang.management API support minimal support building variant 'minimal' nmt include native memory tracking (NMT) parallelgc include the parallel garbage collector serialgc include the serial garbage collector services enable diagnostic services and client attaching shenandoahgc include the Shenandoah garbage collector static-build build static library instead of dynamic vm-structs export JVM structures to the Serviceablility Agent zero support building variant 'zero' zgc include the ZGC garbage collector Also, I missed using the recommended m4_ prefix on some m4 functions. This patch also corrects this. Bug: https://bugs.openjdk.java.net/browse/JDK-8239789 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239789-jvm-features-followup/webrev.01 /Magnus
Re: RFR: JDK-8239789 Follow-up on JVM feature rewrite
jfr should be JDK Flight Recorder. Erik On 2020-02-21 16:05, Magnus Ihse Bursie wrote: The JVM feature rewrite was actually somewhat of a step backwards in terms of presenting information for the user what different configure arguments do. I've compensated for this by making it far better! :) Now we get a list like this: aot enable ahead of time compilation (AOT) cds enable class data sharing (CDS) compiler1 enable hotspot compiler C1 compiler2 enable hotspot compiler C2 dtrace enable dtrace support epsilongc include the epsilon (no-op) garbage collector g1gc include the G1 garbage collector graal enable Graal (jdk.internal.vm.compiler) jfr enable Java Flight Recorder (JFR) jni-check enable -Xcheck:jni support jvmci enable JVM Compiler Interface (JVMCI) jvmti enable Java Virtual Machine Tool Interface (JVM TI) link-time-opt enable link time optimization management enable java.lang.management API support minimal support building variant 'minimal' nmt include native memory tracking (NMT) parallelgc include the parallel garbage collector serialgc include the serial garbage collector services enable diagnostic services and client attaching shenandoahgc include the Shenandoah garbage collector static-build build static library instead of dynamic vm-structs export JVM structures to the Serviceablility Agent zero support building variant 'zero' zgc include the ZGC garbage collector Also, I missed using the recommended m4_ prefix on some m4 functions. This patch also corrects this. Bug: https://bugs.openjdk.java.net/browse/JDK-8239789 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239789-jvm-features-followup/webrev.01 /Magnus
RFR: JDK-8239789 Follow-up on JVM feature rewrite
The JVM feature rewrite was actually somewhat of a step backwards in terms of presenting information for the user what different configure arguments do. I've compensated for this by making it far better! :) Now we get a list like this: aot enable ahead of time compilation (AOT) cds enable class data sharing (CDS) compiler1 enable hotspot compiler C1 compiler2 enable hotspot compiler C2 dtrace enable dtrace support epsilongc include the epsilon (no-op) garbage collector g1gc include the G1 garbage collector graal enable Graal (jdk.internal.vm.compiler) jfr enable Java Flight Recorder (JFR) jni-check enable -Xcheck:jni support jvmci enable JVM Compiler Interface (JVMCI) jvmti enable Java Virtual Machine Tool Interface (JVM TI) link-time-opt enable link time optimization management enable java.lang.management API support minimal support building variant 'minimal' nmt include native memory tracking (NMT) parallelgc include the parallel garbage collector serialgc include the serial garbage collector services enable diagnostic services and client attaching shenandoahgc include the Shenandoah garbage collector static-build build static library instead of dynamic vm-structs export JVM structures to the Serviceablility Agent zero support building variant 'zero' zgc include the ZGC garbage collector Also, I missed using the recommended m4_ prefix on some m4 functions. This patch also corrects this. Bug: https://bugs.openjdk.java.net/browse/JDK-8239789 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239789-jvm-features-followup/webrev.01 /Magnus
RFR [jdk11]: 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3
Hello, please review this small downport of 8201349 . Reason is that we run into warnings as errors, when building jdk11 on Linux with gcc-7.X and with-zlib=bundled . This adds the compiler options -Wno-unused-function -Wno-implicit-fallthrough To some compilations e.g. zlib-files ; these 2 flags are at least supported with gcc-4.7 , gcc-4.8 ,gcc-7 and gcc-8 . Bug : https://bugs.openjdk.java.net/browse/JDK-8201349 jdk/jdk webrev : https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084 adjusted Jdk11 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8201349.0_jdk11/ Thanks, Matthias
jdk11 LIBZIP build and 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3
Hello, we were running into build errors recently when using gcc-7 and with-zlib=bundledin jdk11u-dev . This combination worked nicely in jdk/jdk . Reason is that in jdk11 we do not have : 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084 which unfortunately has a predecessor 8211029: Have a common set of enabled warnings for all native libraries https://hg.openjdk.java.net/jdk/jdk/rev/ec62d6cab037 I'd like to have the gcc - warning disablements for LIBJLI / LIBZIP , but taking over the large patch 8211029to 11 looks a bit too much . Should I just post a separate patch for jdk11u-dev with the gcc warning disablements for LIBJLI / LIBZIP : DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \ ? This fixes our build issues and sounds reasonable and small . Thanks, Matthias
Re: Is anyone still building multiple JVMs?
Hello, in the combination minimal+server , you can jlink smaller target images using "minimal" because of the much smaller libjvm.so . Just an example , target image size is sometimes important too . Best regards, Matthias > I am just wondering, what are the practical reasons for including two > libjvms in the same JDK? > > We had server/client VMs in the past so we can use the same JDK for > running "throughput" jobs vs "desktop/interactive" jobs. But that's no > longer needed with advances in tier compilation, etc. > > Thanks > - Ioi >
RFR: JDK-8239708 Split basics.m4 into basic.m4 and util.m4
The file basics.m4 in make/autoconf is mixing two different concerns: 1) Providing utility/helper functions to the rest of the autoconf files 2) Doing basic or initial setup that does not belong elsewhere. It should be split into two parts, so these different concerns are clearly separated. Furthermore, the naming has not followed our standards. The functions are prefixed "BASIC_" but the file is named "basics.m4". I propose to keep the prefix and drop the plural "s" from the file name. Bug: https://bugs.openjdk.java.net/browse/JDK-8239708 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239708-split-out-util-m4/webrev.01 /Magnus
Re: [urgent] RFR: JDK-8239566 gtest/GTestWrapper.java fails due to "libstlport.so.1: open failed: No such file or directory"
On 2020-02-21 09:50, Claes Redestad wrote: Looks good to me, Magnus! Thanks Claes. Fix pushed. /Magnus /Claes On 2020-02-21 09:44, Magnus Ihse Bursie wrote: Running gtest on Solaris broke with JDK-8239450, with a message like: ld.so.1: gtestLauncher: fatal: libstlport.so.1: open failed: No such file or directory This breaks our CI builds. The problem is that the code checking for the presence of libstlport.so.1 only tried to do so if gtest was enabled, but the check for gtest was moved to after the library setup. Apparently, the tests I ran for JDK-8239450 did not include running gtest on Solaris. :-( Bug: https://bugs.openjdk.java.net/browse/JDK-8239566 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239566-fix-gtest-solaris/webrev.01 /Magnus
Re: [urgent] RFR: JDK-8239566 gtest/GTestWrapper.java fails due to "libstlport.so.1: open failed: No such file or directory"
Looks good to me, Magnus! /Claes On 2020-02-21 09:44, Magnus Ihse Bursie wrote: Running gtest on Solaris broke with JDK-8239450, with a message like: ld.so.1: gtestLauncher: fatal: libstlport.so.1: open failed: No such file or directory This breaks our CI builds. The problem is that the code checking for the presence of libstlport.so.1 only tried to do so if gtest was enabled, but the check for gtest was moved to after the library setup. Apparently, the tests I ran for JDK-8239450 did not include running gtest on Solaris. :-( Bug: https://bugs.openjdk.java.net/browse/JDK-8239566 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239566-fix-gtest-solaris/webrev.01 /Magnus
[urgent] RFR: JDK-8239566 gtest/GTestWrapper.java fails due to "libstlport.so.1: open failed: No such file or directory"
Running gtest on Solaris broke with JDK-8239450, with a message like: ld.so.1: gtestLauncher: fatal: libstlport.so.1: open failed: No such file or directory This breaks our CI builds. The problem is that the code checking for the presence of libstlport.so.1 only tried to do so if gtest was enabled, but the check for gtest was moved to after the library setup. Apparently, the tests I ran for JDK-8239450 did not include running gtest on Solaris. :-( Bug: https://bugs.openjdk.java.net/browse/JDK-8239566 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8239566-fix-gtest-solaris/webrev.01 /Magnus
