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

On 2020-07-02 11:13, Vladimir Kempik wrote: Hello Thanks for looking into this Here is updated webrev. http://cr.openjdk.java.net/~vkempik/8248495/webrev.03/ Regards, Vladimir. Thank you. Now it looks good. /Magnus 1 июля 2020 г., в 21:59, Erik Joelsson написал(а): I think this looks ok,

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

Hello Thanks for looking into this Here is updated webrev. http://cr.openjdk.java.net/~vkempik/8248495/webrev.03/ Regards, Vladimir. > 1 июля 2020 г., в 21:59, Erik Joelsson написал(а): > > I think this looks ok, but would like Magnus' input as he is already involved > in this review. > > /E

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

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: 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[16] 8248495: [macos] zerovm is broken due to libffi headers location

Hello You are using libffi from brew. I'm trying to use the system's one. On x86_64 you have a choice, but on arm64 there is no choice atm. I believe its wrong when configure script can't find default system's library located at default location for this type of OS. Thanks, Vladimir. "jiefu(傅

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

On 2020-07-01 01:50, jiefu(傅杰) wrote: Hi Vladimir and Magnus, How about configuring with --with-libffi=... like this: --with-libffi=/usr/local/Cellar/libffi/3.2.1/lib/libffi-3.2.1 --disable-warnings-as-errors I can compile zero vm on our macos platforms with that configuration. Th

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

Hi Vladimir and Magnus, How about configuring with --with-libffi=... like this: --with-libffi=/usr/local/Cellar/libffi/3.2.1/lib/libffi-3.2.1 --disable-warnings-as-errors I can compile zero vm on our macos platforms with that configuration. Thanks. Best regards, Jie On 2020/7/1, 3

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

On 2020-06-30 21:08, Vladimir Kempik wrote: Hello I agree modding hpp files is a bad idea Thanks for idea with setting LIBFFI_CFLAGS here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/ I still think you are doing this too complicated, and the wrong way around.

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

Hello I agree modding hpp files is a bad idea Thanks for idea with setting LIBFFI_CFLAGS here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/ AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for it was still needed. This special case only appli

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

Vladimir, This looks like it can break in other situation than your specific case. It sounds like you should set LIBFFI_CFLAGS= to  -Iinstallation>, such that "/ffi.h" exists. In particular, the change of include path in globalDefinitions_zero.hpp looks bad. /Magnus On 2020-06-30 15:33, Vla

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

Hello Please review this fix for zero vm building on macos. The issue comes from the libffi, it’s headers are located inside usr/include/ffi/ folder in Macos.sdk, so it can’t be found by configure script. If one wants to use system’s libffi and pass path to libffi via configure argument as --w