libffi issueshttps://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues2023-08-15T19:57:46Zhttps://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/12"Unsupported pair" error when building for for mips2023-08-15T19:57:46ZGerardo Puga"Unsupported pair" error when building for for mipsI'm trying to cross-compile GLIB for a mips32. libffi is included as a subproject within GLIB, and during the build process I hit this error in meson.build in libffi:
https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/blob/m...I'm trying to cross-compile GLIB for a mips32. libffi is included as a subproject within GLIB, and during the build process I hit this error in meson.build in libffi:
https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/blob/meson/meson.build#L259
Initially, by looking at the "if" ladder I thought that mips was not supported by libffi, but then I saw that actually it seems to be supported [elsewhere](https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/tree/meson/src/mips) (even within the [same file](https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/blob/meson/meson.build#L83)).
Is this "if" ladder missing an option for "mips"? am I missing something else?
Thanks.https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/11Build for fat library(x86_64 and arm64) on macOS Apple M12022-09-13T07:42:24ZTuming WenBuild for fat library(x86_64 and arm64) on macOS Apple M1I can easy build fat library(x86_64 and arm64) from source https://github.com/libffi/libffi 3.4.2 on macOS Apple M1.
```
./configure CFLAGS="-arch x86_64 -arch arm64" \
LDFLAGS="-framework CoreFoundation" \
--prefix=/some_place/libffi-3....I can easy build fat library(x86_64 and arm64) from source https://github.com/libffi/libffi 3.4.2 on macOS Apple M1.
```
./configure CFLAGS="-arch x86_64 -arch arm64" \
LDFLAGS="-framework CoreFoundation" \
--prefix=/some_place/libffi-3.4.2 \
--enable-shared=no
--- Verify using file command ---
file /some_place/libffi-3.4.2/lib/libffi.a
/some_place/libffi-3.4.2/lib/libffi.a: Mach-O universal binary with 2 architectures: [x86_64:current ar archive random librarycurrent ar archive random library] [arm64:current ar archive random librarycurrent ar archive random library]
/some_place/libffi-3.4.2/lib/libffi.a (for architecture x86_64): current ar archive random library
/some_place/libffi-3.4.2/lib/libffi.a (for architecture arm64): current ar archive random library
```
Is it possible to build fat library on macOS Apple M1 with `meson build system`?<br>
Could you give me some advice?<br>
I also try to build but always failed. please take a look `Meson build result`
```
meson build --native-file /some_place/universal-libffi.txt
/some_place/universal-libffi.txt
--------------------------------
[binaries]
c = 'clang'
objc = 'clang'
cpp = 'clang++'
ar = 'ar'
ld = 'ld'
strip = 'strip'
lipo = 'lipo'
ranlib = 'ranlib'
pkg-config = '/some_place/bin/universal/pkg-config-0.29.2/bin/pkg-config'
[built-in options]
prefix = '/some_place/libffi'
c_args = ['-arch', 'x86_64']
c_link_args = ['-framework', 'CoreFoundation']
cpp_args = ['-arch', 'x86_64']
cpp_link_args = ['-framework', 'CoreFoundation']
default_library = 'static'
buildtype = 'release'
```
`Meson build result`
```
The Meson build system
Version: 0.63.2
Source dir: /some_place/Downloads/libffi-meson
Build dir: /some_place/Downloads/libffi-meson/build
Build type: native build
Project name: libffi
Project version: 3.2.9999
C compiler for the host machine: clang (clang 13.1.6 "Apple clang version 13.1.6 (clang-1316.0.21.2.5)")
C linker for the host machine: clang ld64 764
Host machine cpu family: aarch64
Host machine cpu: arm64
Message: host cpu: arm64
Message: host cpu_family: aarch64
Message: host system: darwin
Checking if "ASM .cfi" compiles: NO
Checking for size of "size_t" : 8
Checking for size of "long double" : 16
Checking for size of "double" : 8
Message: sizeof "long double" is greater than "double"
Message: .eh_frame is hard-coded to ro
Message: Cannot use PROT_EXEC on this target, using fallback
Checking for function "memcpy" : YES
Checking for function "mkostemp" : YES
Has header "alloca.h" : YES
Has header "inttypes.h" : YES
Has header "stdint.h" : YES
Compiler for C supports function attribute visibility: YES
Program test-cc-supports-hidden-visibility.py found: YES (/Applications/Xcode.app/Contents/Developer/usr/bin/python3 /some_place/Downloads/libffi-meson/test-cc-supports-hidden-visibility.py)
Message: .hidden pseudo-op is NOT available: .hidden not found in the outputted assembly
Configuring fficonfig.h using configuration
Program msvcc.sh found: YES (/Users/tuming/Downloads/libffi-meson/msvcc.sh)
Configuring ffi-aarch64.h using configuration
Configuring ffitarget.h using configuration
Configuring ffi.h using configuration
Compiler for C supports arguments -x assembler-with-cpp: NO
Build targets in project: 1
libffi 3.2.9999
User defined options
Native files: /some_place/universal-libffi.txt
Found ninja-1.11.1 at /some_place/bin/universal/ninja-1.11.1/bin/ninja
tuming@Tumings-Mac-mini libffi-meson % ninja -C build
ninja: Entering directory `build'
[1/8] Compiling C object src/libffi.a.p/aarch64_sysv.S.o
FAILED: src/libffi.a.p/aarch64_sysv.S.o
clang -Isrc/libffi.a.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fcolor-diagnostics -Wall -Winvalid-pch -O3 -DFFI_BUILDING -DFFI_STATIC_BUILD -arch x86_64 -DTARGET=AARCH64 -MD -MQ src/libffi.a.p/aarch64_sysv.S.o -MF src/libffi.a.p/aarch64_sysv.S.o.d -o src/libffi.a.p/aarch64_sysv.S.o -c ../src/aarch64/sysv.S
In file included from ../src/aarch64/sysv.S:24:
include/ffi.h:10:10: fatal error: 'ffi-x86_64.h' file not found
#include "ffi-x86_64.h"
^~~~~~~~~~~~~~
1 error generated.
[2/8] Compiling C object src/libffi.a.p/types.c.o
FAILED: src/libffi.a.p/types.c.o
clang -Isrc/libffi.a.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fcolor-diagnostics -Wall -Winvalid-pch -O3 -DFFI_BUILDING -DFFI_STATIC_BUILD -arch x86_64 -DTARGET=AARCH64 -MD -MQ src/libffi.a.p/types.c.o -MF src/libffi.a.p/types.c.o.d -o src/libffi.a.p/types.c.o -c ../src/types.c
In file included from ../src/types.c:31:
include/ffi.h:10:10: fatal error: 'ffi-x86_64.h' file not found
#include "ffi-x86_64.h"
^~~~~~~~~~~~~~
1 error generated.
[3/8] Compiling C object src/libffi.a.p/closures.c.o
FAILED: src/libffi.a.p/closures.c.o
clang -Isrc/libffi.a.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fcolor-diagnostics -Wall -Winvalid-pch -O3 -DFFI_BUILDING -DFFI_STATIC_BUILD -arch x86_64 -DTARGET=AARCH64 -MD -MQ src/libffi.a.p/closures.c.o -MF src/libffi.a.p/closures.c.o.d -o src/libffi.a.p/closures.c.o -c ../src/closures.c
In file included from ../src/closures.c:34:
include/ffi.h:10:10: fatal error: 'ffi-x86_64.h' file not found
#include "ffi-x86_64.h"
^~~~~~~~~~~~~~
1 error generated.
[4/8] Compiling C object src/libffi.a.p/raw_api.c.o
FAILED: src/libffi.a.p/raw_api.c.o
clang -Isrc/libffi.a.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fcolor-diagnostics -Wall -Winvalid-pch -O3 -DFFI_BUILDING -DFFI_STATIC_BUILD -arch x86_64 -DTARGET=AARCH64 -MD -MQ src/libffi.a.p/raw_api.c.o -MF src/libffi.a.p/raw_api.c.o.d -o src/libffi.a.p/raw_api.c.o -c ../src/raw_api.c
In file included from ../src/raw_api.c:29:
include/ffi.h:10:10: fatal error: 'ffi-x86_64.h' file not found
#include "ffi-x86_64.h"
^~~~~~~~~~~~~~
1 error generated.
[5/8] Compiling C object src/libffi.a.p/java_raw_api.c.o
FAILED: src/libffi.a.p/java_raw_api.c.o
clang -Isrc/libffi.a.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fcolor-diagnostics -Wall -Winvalid-pch -O3 -DFFI_BUILDING -DFFI_STATIC_BUILD -arch x86_64 -DTARGET=AARCH64 -MD -MQ src/libffi.a.p/java_raw_api.c.o -MF src/libffi.a.p/java_raw_api.c.o.d -o src/libffi.a.p/java_raw_api.c.o -c ../src/java_raw_api.c
In file included from ../src/java_raw_api.c:38:
include/ffi.h:10:10: fatal error: 'ffi-x86_64.h' file not found
#include "ffi-x86_64.h"
^~~~~~~~~~~~~~
1 error generated.
[6/8] Compiling C object src/libffi.a.p/prep_cif.c.o
FAILED: src/libffi.a.p/prep_cif.c.o
clang -Isrc/libffi.a.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fcolor-diagnostics -Wall -Winvalid-pch -O3 -DFFI_BUILDING -DFFI_STATIC_BUILD -arch x86_64 -DTARGET=AARCH64 -MD -MQ src/libffi.a.p/prep_cif.c.o -MF src/libffi.a.p/prep_cif.c.o.d -o src/libffi.a.p/prep_cif.c.o -c ../src/prep_cif.c
In file included from ../src/prep_cif.c:26:
include/ffi.h:10:10: fatal error: 'ffi-x86_64.h' file not found
#include "ffi-x86_64.h"
^~~~~~~~~~~~~~
1 error generated.
[7/8] Compiling C object src/libffi.a.p/aarch64_ffi.c.o
FAILED: src/libffi.a.p/aarch64_ffi.c.o
clang -Isrc/libffi.a.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fcolor-diagnostics -Wall -Winvalid-pch -O3 -DFFI_BUILDING -DFFI_STATIC_BUILD -arch x86_64 -DTARGET=AARCH64 -MD -MQ src/libffi.a.p/aarch64_ffi.c.o -MF src/libffi.a.p/aarch64_ffi.c.o.d -o src/libffi.a.p/aarch64_ffi.c.o -c ../src/aarch64/ffi.c
In file included from ../src/aarch64/ffi.c:26:
include/ffi.h:10:10: fatal error: 'ffi-x86_64.h' file not found
#include "ffi-x86_64.h"
^~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.
```https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/9Build failure with `-Dc_std=c11`2022-02-07T04:10:11ZLászló VáradyBuild failure with `-Dc_std=c11`When configuring the project with `-Dc_std=cXX` (89, 99, 11), the compilation fails due to an incorrectly detected PCREL check:
```sh
$ meson setup -Dc_std=c11 build
...
$ meson compile -C build
[1/10] Compiling C object src/libffi.so.7...When configuring the project with `-Dc_std=cXX` (89, 99, 11), the compilation fails due to an incorrectly detected PCREL check:
```sh
$ meson setup -Dc_std=c11 build
...
$ meson compile -C build
[1/10] Compiling C object src/libffi.so.7.1.0.p/x86_unix64.S.o
FAILED: src/libffi.so.7.1.0.p/x86_unix64.S.o
cc -Isrc/libffi.so.7.1.0.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -O2 -g -DFFI_BUILDING -fPIC -DTARGET=X86_64 -MD -MQ src/libffi.so.7.1.0.p/x86_unix64.S.o -MF src/libffi.so.7.1.0.p/x86_unix64.S.o.d -o src/libffi.so.7.1.0.p/x86_unix64.S.o -c ../src/x86/unix64.S
../src/x86/unix64.S: Assembler messages:
../src/x86/unix64.S:451: Error: junk at end of line, first unrecognized character is `@'
```
The problematic check:
```
Command line: cc /tmpg5c31nq9/testfile.c -o /tmpg5c31nq9/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -std=c11
Code:
asm (".text; foo: nop; .data; .long foo-.; .text");
Compiler stdout:
Compiler stderr:
/tmpg5c31nq9/testfile.c:1:6: error: expected declaration specifiers or '...' before string constant
1 | asm (".text; foo: nop; .data; .long foo-.; .text");
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Checking if "ASM x86 PCREL" : compiles: NO
```
Workaround:
Using `-Dc_std=gnuXX`.https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/8HTTPS access to the libffi repo is frequently down2021-12-27T14:58:23ZkcgenHTTPS access to the libffi repo is frequently downTry it:
![2021-12-27_06-40](/uploads/128d94dab93c30983c45e94bf6c43ad3/2021-12-27_06-40.png)
---
`git clone https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi.git`
The connection will either timeout or fail with a 504 error (...Try it:
![2021-12-27_06-40](/uploads/128d94dab93c30983c45e94bf6c43ad3/2021-12-27_06-40.png)
---
`git clone https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi.git`
The connection will either timeout or fail with a 504 error (at least, that's been this case for the last ~18 hours).
This isn't so bad as the `git` API still works as does simply downloading the tarball or zip file.
However, more serious problem happen for projects that use the glib project's Meson wrap, as it in turn depends on libffi via its own subproject Meson wrap:
https://gitlab.gnome.org/GNOME/glib/-/blob/main/subprojects/libffi.wrap
These periodic outages have affected the DOSBox Staging project off and on for months with errors like:
![2021-12-27_06-38](/uploads/5294af862d504ebec421ce7ac6f3a78b/2021-12-27_06-38.png)
However, we could manually re-launch the workflow and repeated runs would usually go through. I had originally chalked this up to overloaded VM farm or network overload at GitHub - but the last day has finally led me to isolate the issue to the ffi project itself.https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/7Can't build with clang-cl after recent (16.9.0) MSVC 2019 update2022-05-17T12:45:42ZAleksandr MezinCan't build with clang-cl after recent (16.9.0) MSVC 2019 updateFails to build with clang-cl again:
```
[9/9] Linking target src/ffi-7.dll
FAILED: src/ffi-7.dll src/ffi-7.pdb
"lld-link" /MACHINE:x64 /OUT:src/ffi-7.dll src/x86_win64_intel_S.obj src/ffi-7.dll.p/prep_cif.c.obj src/ffi-7.dll.p/types.c....Fails to build with clang-cl again:
```
[9/9] Linking target src/ffi-7.dll
FAILED: src/ffi-7.dll src/ffi-7.pdb
"lld-link" /MACHINE:x64 /OUT:src/ffi-7.dll src/x86_win64_intel_S.obj src/ffi-7.dll.p/prep_cif.c.obj src/ffi-7.dll.p/types.c.obj src/ffi-7.dll.p/raw_api.c.obj src/ffi-7.dll.p/java_raw_api.c.obj src/ffi-7.dll.p/closures.c.obj src/ffi-7.dll.p/x86_ffiw64.c.obj "/nologo" "/DEBUG" "/PDB:src\ffi-7.pdb" "/DLL" "/IMPLIB:src\ffi.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib"
lld-link: error: duplicate symbol: ffi_type_void
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_uint8
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_sint8
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_uint16
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_sint16
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_uint32
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_sint32
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_uint64
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_sint64
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_pointer
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_float
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_double
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/types.c.obj
lld-link: error: duplicate symbol: ffi_type_void
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/raw_api.c.obj
lld-link: error: duplicate symbol: ffi_type_uint8
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/raw_api.c.obj
lld-link: error: duplicate symbol: ffi_type_sint8
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/raw_api.c.obj
lld-link: error: duplicate symbol: ffi_type_uint16
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/raw_api.c.obj
lld-link: error: duplicate symbol: ffi_type_sint16
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/raw_api.c.obj
lld-link: error: duplicate symbol: ffi_type_uint32
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/raw_api.c.obj
lld-link: error: duplicate symbol: ffi_type_sint32
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/raw_api.c.obj
lld-link: error: duplicate symbol: ffi_type_uint64
>>> defined at src/ffi-7.dll.p/prep_cif.c.obj
>>> defined at src/ffi-7.dll.p/raw_api.c.obj
lld-link: error: too many errors emitted, stopping now (use /errorlimit:0 to see all errors)
ninja: build stopped: subcommand failed.
```https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/6libffi does not honor includedir2021-03-03T18:57:09ZTim Fleschenberglibffi does not honor includedirHi,
I am currently in the process of building glib and discovered that libffi as a subproject does not honor the includedir and always places the header files in an include directory directly below prefix. However, the includedir path i...Hi,
I am currently in the process of building glib and discovered that libffi as a subproject does not honor the includedir and always places the header files in an include directory directly below prefix. However, the includedir path information in the libffi pkgconfig file is correctly pointing to the specified includedir.
This behavior should be corrected with this patch: [patchfile.patch](/uploads/9e5d0c7408989deca426e57c92ce2620/patchfile.patch)
However, I am new to using meson and have no idea whether this patch breaks something in other projects or if there is a superordinate prefix specifically for subprojects that should be used.https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/5Can't build with clang-cl: No specified compiler can handle file subprojects\...2021-02-28T10:19:10ZAleksandr MezinCan't build with clang-cl: No specified compiler can handle file subprojects\libffi\src\x86/win64.S```
>set CC=clang-cl
>set CXX=clang-cl
>meson setup . ..\libffi-build
...
ERROR: No specified compiler can handle file src\x86/win64.S
``````
>set CC=clang-cl
>set CXX=clang-cl
>meson setup . ..\libffi-build
...
ERROR: No specified compiler can handle file src\x86/win64.S
```https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/4unable to cross-compile for 32 bit Windows: "ffi-x86.h: No such file or direc...2022-05-13T20:39:15ZFelix Schwarzunable to cross-compile for 32 bit Windows: "ffi-x86.h: No such file or directory"I hope I'm not overlooking something really trivial but I'm unable to cross-compile libffi for 32 bit Windows (using Fedora 33, mingw32 10.2.1):
$ meson build.win --cross-file=meson.cross-file
The Meson build system
Version: 0.55....I hope I'm not overlooking something really trivial but I'm unable to cross-compile libffi for 32 bit Windows (using Fedora 33, mingw32 10.2.1):
$ meson build.win --cross-file=meson.cross-file
The Meson build system
Version: 0.55.3
Source dir: …/libffi
Build dir: …/libffi/build.win
Build type: cross build
Project name: libffi
Project version: 3.2.1
C compiler for the build machine: cc (gcc 10.2.1 "cc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)")
C linker for the build machine: cc ld.bfd 2.35-15
C compiler for the host machine: /usr/bin/i686-w64-mingw32-gcc (gcc 10.2.1 "i686-w64-mingw32-gcc (GCC) 10.2.1 20200723 (Fedora MinGW 10.2.1-2.fc33)")
C linker for the host machine: /usr/bin/i686-w64-mingw32-gcc ld.bfd 2.34-3
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86_64
Host machine cpu: i686
Target machine cpu family: x86_64
Target machine cpu: i686
Message: host cpu: i686
Message: host cpu_family: x86_64
Message: host system: windows
Found ninja-1.10.1 at /usr/bin/ninja
…
$ ninja -C build.win
ninja: Entering directory `build.win'
[1/8] Compiling C object src/libffi-7.dll.p/types.c.obj
FAILED: src/libffi-7.dll.p/types.c.obj
/usr/bin/i686-w64-mingw32-gcc -Isrc/libffi-7.dll.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -DFFI_BUILDING -DTARGET=X86_WIN32 -MD -MQ src/libffi-7.dll.p/types.c.obj -MF src/libffi-7.dll.p/types.c.obj.d -o src/libffi-7.dll.p/types.c.obj -c ../src/types.c
In file included from ../src/types.c:31:
include/ffi.h:8:10: fatal error: ffi-x86.h: No such file or directory
8 | #include "ffi-x86.h"
| ^~~~~~~~~~~
compilation terminated.
…
and indeed `ffi-x86.h` is nowhere to be found:
$ find build.win -name "ffi*.h"
build.win/fficonfig.h
build.win/include/ffitarget-x86_64.h
build.win/include/ffi-x86_64.h
build.win/include/ffi.h
build.win/include/ffitarget.h
To me it looks like meson does not tell libffi correctly about the target cpu
meson.cross-file:
[binaries]
c = '/usr/bin/i686-w64-mingw32-gcc'
cpp = '/usr/bin/i686-w64-mingw32-g++'
ar = '/usr/bin/i686-w64-mingw32-ar'
strip = '/usr/bin/i686-w64-mingw32-strip'
exe_wrapper = 'wine'
# needed for glib
windres = '/usr/bin/i686-w64-mingw32-windres'
# "host machine is the machine on which the compiled binary will run."
[host_machine]
system = 'windows'
cpu_family = 'x86_64'
cpu = 'i686'
endian = 'little'https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/3Building using meson on POWER2020-12-03T18:01:06ZWileam Y. PhanBuilding using meson on POWERHi,
I want to build Midnight Commander on an IBM POWER9 machine, which has GLib as a dependency, so I tried building GLib using `meson` first. Using version 2.67.0 tarball, I get the following error message:
```
subprojects/libffi/src/m...Hi,
I want to build Midnight Commander on an IBM POWER9 machine, which has GLib as a dependency, so I tried building GLib using `meson` first. Using version 2.67.0 tarball, I get the following error message:
```
subprojects/libffi/src/meson.build:71:2: ERROR: Problem encountered: Unsupported pair: system "linux", cpu family "ppc64"
```
Here are some system details:
```
$ uname -a
Linux tellico-master0 4.14.0-115.10.1.el7a.ppc64le #1 SMP Wed Jun 26 09:32:17 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
```
```
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.6 (Maipo)
```
```
$ gcc --version
gcc (Spack GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
Any help would be appreciated. Thanks!https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/2libffi fails to build when cross-building on linux with MinGW2021-04-07T15:21:59ZAntonio Ospitelibffi fails to build when cross-building on linux with MinGWHi,
following up from https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/commit/edaa2f7f5726efa2efe33335493e81e6715d7a82#note_611688 I observe a failure when cross-building on linux using MinGW.
This is the meson cross-file ...Hi,
following up from https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/commit/edaa2f7f5726efa2efe33335493e81e6715d7a82#note_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
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, Antoniohttps://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/1Build files assume host_system is 'darwin' when cross-compiling to iOS2020-05-28T20:02:58ZNirbheek Chauhannirbheek.chauhan@gmail.comBuild files assume host_system is 'darwin' when cross-compiling to iOSSo, the [current situation in Meson](https://github.com/mesonbuild/meson/issues/6257) is that [the only `host_machine.system()` values specified are for native compilation](https://mesonbuild.com/Reference-tables.html#operating-system-na...So, the [current situation in Meson](https://github.com/mesonbuild/meson/issues/6257) is that [the only `host_machine.system()` values specified are for native compilation](https://mesonbuild.com/Reference-tables.html#operating-system-names). When cross-compiling, the cross files can specify anything. This means that some people use `system = 'darwin'` and others (like cerbero) use `system = 'ios'` in the cross file.
This is, obviously, a very shitty situation.
Why am I filing it here? Well, we check for `host_system == 'ios'` in all gstreamer code, and in glib, but not in libffi. The only thing this changes is:
```patch
--- _builddir-host_system=darwin/fficonfig.h
+++ _builddir-host_system=ios/fficonfig.h
@@ -10,7 +10,7 @@
/* #undef FFI_DEBUG */
/* Cannot use PROT_EXEC on this target, so, we revert to alternative means */
-#define FFI_EXEC_TRAMPOLINE_TABLE 1
+#define FFI_EXEC_TRAMPOLINE_TABLE 0
/* Define this if you want to enable pax emulated trampolines */
/* #undef FFI_MMAP_EXEC_EMUTRAMP_PAX */
```
It's `0` when `host_system` is `ios` and `1` when it's `darwin`. Now I'm not sure if we should change this or not, so I'm filing an issue so we can deal with it later. Perhaps after we sync with upstream.