RFR: 8307527: MacOS Zero builds fail with undefined FFI_GO_CLOSURES after JDK-8304265

[Jorn Vernee]

On Mon, 8 May 2023 10:31:20 GMT, Aleksey Shipilev <shade at openjdk.org> 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