libffi fails to build when cross-building on linux with MinGW

Hi,

following up from edaa2f7f (comment 611688) I observe a failure when cross-building on linux using MinGW.

This is the meson cross-file I am using:

[host_machine]
system = 'windows'
cpu_family = 'x86_64'
cpu = 'x86_64'
endian = 'little'

[properties]
c_args = []
c_link_args = []

[binaries]
c = 'x86_64-w64-mingw32-gcc'
cpp = 'x86_64-w64-mingw32-g++'
ar = 'x86_64-w64-mingw32-ar'
strip = 'x86_64-w64-mingw32-strip'
pkgconfig = 'x86_64-w64-mingw32-pkg-config'
windres = 'x86_64-w64-mingw32-windres'

And this is the failure I am seeing:

$ meson --cross-file meson_mingw_w64_x86-64.txt build/
...
$ ninja -C build/
ninja: Entering directory `build/'
[8/8] Linking target src/libffi-7.dll
FAILED: src/libffi-7.dll 
x86_64-w64-mingw32-gcc  -o src/libffi-7.dll src/libffi-7.dll.p/prep_cif.c.obj src/libffi-7.dll.p/types.c.obj src/libffi-7.dll.p/raw_api.c.obj src/libffi-7.dll.p/java_raw_api.c.obj src/libffi-7.dll.p/closures.c.obj src/libffi-7.dll.p/x86_ffiw64.c.obj src/libffi-7.dll.p/x86_win64.S.obj -Wl,--allow-shlib-undefined -shared -Wl,--start-group -Wl,--out-implib=src/libffi.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
/usr/bin/x86_64-w64-mingw32-ld: src/libffi-7.dll.p/types.c.obj:/home/ao2/WIP/gnome/libffi/build/../src/types.c:104: multiple definition of `ffi_type_complex_longdouble'; src/libffi-7.dll.p/prep_cif.c.obj:/home/ao2/WIP/gnome/libffi/build/include/ffi-x86_64.h:201: first defined here
/usr/bin/x86_64-w64-mingw32-ld: src/libffi-7.dll.p/types.c.obj:/home/ao2/WIP/gnome/libffi/build/../src/types.c:97: multiple definition of `ffi_type_longdouble'; src/libffi-7.dll.p/prep_cif.c.obj:/home/ao2/WIP/gnome/libffi/build/include/ffi-x86_64.h:192: first defined here
...

with a lot of similar messages.

The issue goes away with this patch:

diff --git a/include/ffi.h.in b/include/ffi.h.in
index 1fca797..50febfa 100644
--- a/include/ffi.h.in
+++ b/include/ffi.h.in
@@ -64,7 +64,7 @@ extern "C" {
    the static version of the library, but don't worry about that.
    Besides, as a workaround, they can define FFI_BUILDING if they
    *know* they are going to link with the static library.  */
-#if defined _WIN32 && !defined FFI_STATIC_BUILD
+#if defined _MSC_VER && !defined FFI_STATIC_BUILD
 #ifdef FFI_BUILDING
 #define FFI_EXTERN __declspec(dllexport)
 #else

Which seems consistent with what upstream does and what is also in @Ericson2314 branch which does not show the problem.

It's not an urgent thing, even less so now that I have a local workaround, so if there are plans to rebase the meson port on top of the latest upstream I will happily wait for that.

However I am still wondering why you do not experience the issue when building from cerbero, maybe some other factor makes _WIN32 defined in your environment?

BTW I am using this MinGW version:

C compiler for the host machine: x86_64-w64-mingw32-gcc (gcc 10.0.0 "x86_64-w64-mingw32-gcc (GCC) 10-win32 20200525")
C linker for the host machine: x86_64-w64-mingw32-gcc ld.bfd 2.34.90.20200706

Thanks, Antonio