On Mon, 8 May 2023 10:31:20 GMT, Aleksey Shipilev <[email protected]> wrote:
>> After thinking a bit, I think I'd prefer this to be addressed in the build
>> system instead. e.g. something like:
>>
>>
>> diff --git a/make/autoconf/lib-ffi.m4 b/make/autoconf/lib-ffi.m4
>> index 0905c3cd225..83de5a4abf7 100644
>> --- a/make/autoconf/lib-ffi.m4
>> +++ b/make/autoconf/lib-ffi.m4
>> @@ -106,6 +106,13 @@ AC_DEFUN_ONCE([LIB_SETUP_LIBFFI],
>> AC_MSG_ERROR([Could not find libffi! $HELP_MSG])
>> fi
>>
>> + if test "x${OPENJDK_TARGET_CPU}" = "xaarch64" && test
>> "x${OPENJDK_TARGET_OS}" = xmacosx; then
>> + # ffi.h checks '#if FFI_GO_CLOSURES' which throws a warning in xcode
>> on aarch64 because the aarch64
>> + # ffitarget.h (included from ffi.h) doesn't explicitly define
>> FFI_GO_CLOSURES (like it does on e.g. x64).
>> + # define it explicitly here to avoid compilation errors
>> + LIBFFI_CFLAGS="$LIBFFI_CFLAGS -DFFI_GO_CLOSURES=0"
>> + fi
>> +
>> AC_MSG_CHECKING([if libffi works])
>> AC_LANG_PUSH(C)
>> OLD_CFLAGS="$CFLAGS"
>>
>>
>> And then remove the workaround from the source code. (`LIBFFI_CFLAGS` is
>> used to build both relevant libraries, and should also be used when a new
>> library is added that needs libffi. So this would avoid a repeat of this
>> issue)
>>
>> Either way, let's thoroughly document the issue this time around, so future
>> editors won't have to guess why this is needed.
>
>> And then remove the workaround from the source code. (`LIBFFI_CFLAGS` is
>> used to build both relevant libraries, and should also be used when a new
>> library is added that needs libffi. So this would avoid a repeat of this
>> issue)
>
> Yes, I added a variant of that fix that explicitly checks for
> `FFI_GO_CLOSURES` definition during configure. (Now I have to find a system
> which actually supports recent FFI to test it...
@shipilev Ran this through our CI again, but it's failing there
(`linux-x64-zero` and `linux-aarch64-zero`). It seems like the check in the
configuration is erroneously failing (`checking for FFI_GO_CLOSURES
definition... no, defining`) and then the compilation of hotspot fails because
`FFI_GO_CLOSURES` is already defined, when `ffitarget.h` tries to define it
again.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13827#issuecomment-1538564604
