Re: RFR: JDK-8248667 Need support for building native libraries located in the test/lib directory

On 2020-07-02 01:47, Jonathan Gibbons wrote: On 7/1/20 3:39 PM, Magnus Ihse Bursie wrote: This patch adds a simple lib. Since jtreg does not accept multiple roots for native libraries, This was a deliberate jtreg design choice, when support for native libraries was added, but IIRC this de

Re: RFR: JDK-8248667 Need support for building native libraries located in the test/lib directory

On 7/1/20 3:39 PM, Magnus Ihse Bursie wrote: This patch adds a simple lib. Since jtreg does not accept multiple roots for native libraries, This was a deliberate jtreg design choice, when support for native libraries was added, but IIRC this decision could reasonably be changed, if that b

Re: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers location

I sent this before but it seems it did not reach the mailing list..? Resending, apologies if this arrives twice. --- > On 2020-07-01 11:45, Vladimir Kempik wrote: > Hello > > Please take a look at updated webrev - > http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/ > > I decided to use A

RFR: JDK-8248667 Need support for building native libraries located in the test/lib directory

Chris has requested help to add native test code to the test lib. From the bug report: "As part of the work for JDK-8248194 I'm adding a native method to LingeredApp.c. The native method will be located in:    test/lib/jdk/test/lib/apps/libLingeredApp.c However, currently there is only suppo

Re: RFR: JDK-8248158 Configure fails with autoconf not found even though it's installed

On 2020-07-01 12:05, Galder Zamarreno wrote: Using `which` to check whether commands exist can result in confusing errors when `which` itself is not installed in the system. This is the case with `autoconf`, where if `autoconf` is present but `which` isn't, the build system says that `autoconf

Re: RFR: JDK-8248158 Configure fails with autoconf not found even though it's installed

On 2020-07-01 12:05, Galder Zamarreno wrote: Using `which` to check whether commands exist can result in confusing errors when `which` itself is not installed in the system. This is the case with `autoconf`, where if `autoconf` is present but `which` isn't, the build system says that `autoconf

Re: JDK 16 RFR of JDK-8247534: Update --release 15 symbol information for JDK 15 build 29

Thanks for the additional analysis Jan; I was wondering why the delta was so large. Cheers, -Joe On 7/1/2020 12:18 AM, Jan Lahoda wrote: Looks good to me. (A new innerclass entry was added for java/security/Provider$Service, and the current format sadly needs to restate the whole class heade

Re: RFR: JDK-8248610 Clean up handling of Windows RC files

Looks good. /Erik On 2020-06-30 17:27, Magnus Ihse Bursie wrote: The logic for handling .rc files in Windows has been quite messy. The variable RCFLAGS was incorrectly named RC_FLAGS. In it, we mixed tool-specific values with defines needed by version.rc. The contents of version.rc was needle

Re: RFR: JDK-8248158 Configure fails with autoconf not found even though it's installed

Looks good to me. /Erik On 2020-07-01 03:05, Galder Zamarreno wrote: Using `which` to check whether commands exist can result in confusing errors when `which` itself is not installed in the system. This is the case with `autoconf`, where if `autoconf` is present but `which` isn't, the build sys

Re: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers location

I think this looks ok, but would like Magnus' input as he is already involved in this review. /Erik On 2020-07-01 02:45, Vladimir Kempik wrote: Hello Please take a look at updated webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/

Re: JDK-8244763: Update --release 8 symbol information after JSR 337 MR3

+1 -- Jon On 6/26/20 6:13 AM, Jan Lahoda wrote: Hi, I propose to split the data update (for JDK 15 and for backports) and the tool/CreateSymbols update (for JDK 16+). So I've created: https://bugs.openjdk.java.net/browse/JDK-8248405 for the latter. Lets keep JDK-8244763 only for the former,

RFR: JDK-8248158 Configure fails with autoconf not found even though it's installed

Using `which` to check whether commands exist can result in confusing errors when `which` itself is not installed in the system. This is the case with `autoconf`, where if `autoconf` is present but `which` isn't, the build system says that `autoconf` is missing, when in reality it is `which` which

Re: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers location

Hello Please take a look at updated webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/ I decided to use AC_CHECK_HEADERS instead AC_CHECK_FILE as it doesn’t work in cross-compilation scenario. libffi binary is located in ab

Re: RFR: 8248612: Back quotes and double quotes must not be escaped in: Cannot convert \"$unix_path\" to Windows path

Thanks Magnus for your review. I will push it tonight. Best regards, Jie On 2020/7/1, 4:39 PM, "Magnus Ihse Bursie" wrote: On 2020-07-01 04:29, jiefu(傅杰) wrote: > Hi all, > > May I get reviews for this fix? > > JBS:https://bugs.openjdk.java.net/browse/JDK-8248612

Re: RFR: 8248612: Back quotes and double quotes must not be escaped in: Cannot convert \"$unix_path\" to Windows path

On 2020-07-01 04:29, jiefu(傅杰) wrote: Hi all, May I get reviews for this fix? JBS:https://bugs.openjdk.java.net/browse/JDK-8248612 Webrev: http://cr.openjdk.java.net/~jiefu/8248612/webrev.00/ LGTM. /Magnus Thanks a lot. Best regards, Jie

Re: JDK 16 RFR of JDK-8247534: Update --release 15 symbol information for JDK 15 build 29

Looks good to me. (A new innerclass entry was added for java/security/Provider$Service, and the current format sadly needs to restate the whole class header, including all innerclass entries for any change to the header.) Jan On 30. 06. 20 23:58, Joe Darcy wrote: Hello, Please review a smal