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

[Jorn Vernee]

On Fri, 5 May 2023 09:11:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug. Actually, I am not sure why JDK-8304265 changed the `#ifndef FFI_GO_CLOSURES` to `#ifdef _APPLE_`. That seems too intrusive if `FFI_GO_CLOSURES` *is* enabled. So I rewrote the block to something more safe.
> 
> Additional testing:
>  - [x] macos-aarch64-zero-fastdebug `make images` passes

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13827#issuecomment-1536257130