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 applies to macos/clang when sysroot is set and no libffi configure options is used. (which is default case) Thanks, Vladimir > 30 июня 2020 г., в 19:46, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> > написал(а): > > Vladimir, > > This looks like it can break in other situation than your specific case. > > It sounds like you should set LIBFFI_CFLAGS= to -I<path to your ffi > installation>, such that "<path to your ffi installation>/ffi.h" exists. In > particular, the change of include path in globalDefinitions_zero.hpp looks > bad. > > /Magnus > > On 2020-06-30 15:33, Vladimir Kempik wrote: >> 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 --with-libffi-include=/usr/include/ffi, then it won’t be found >> by configure because clang will look exactly in /usr/include/ffi, but not in >> macos.sdk >> The system, at least on 10.15 doesn’t have /usr/includes at all. >> >> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and >> no --with-libffi-include argument. >> >> However there is one issue with this patch, if --with-libffi-include passed >> then c++ code will still try to include <ffi/ffi.h> >> >> I’m not sure which way is the best for such rare case. it could be possible >> to define include filename in configure and pass it via -D and CFLAGS to c++ >> code. >> >> >> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/ >> >> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495 >> >> Thanks, Vladimir
