[libffi] Use upstream's build system

[dg0yt]

Uses the official build system.
Uses the official binary names for Windows. (One patch less for llvm.)
Reimplements exported CMake config with find_... commands, and moves it to the unofficial namespace. (Migration path included.)

Adds libffi dependency to gobject-introspection manifest.

[LilyWangLL]

Can you please resolve the conflicts against master?

[dg0yt]

Just the usual merge-unfriendly vcpkg versions stuff. Done.

[LilyWangLL]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[TrueBrain]

This change seems to break Python3 on x64-linux. It installs libffi in lib64 folder, instead of lib folder. This causes Python to not link against libffi, causing unresolved symbol errors. For more information: #33426

[Neumann-A]

This change seems to break Python3 on x64-linux. It installs libffi in lib64 folder, instead of lib folder.

What linux distro is that? the one vcpkg uses installs into /lib/

[TrueBrain]

As mentioned in #33426, this is with quay.io/pypa/manylinux2014_x86_64 container image. Which is used to build a lot of native Python libraries, as it is lovely compatible with a lot of different Linux machines.

[Neumann-A]

Try passing --disable-multi-os-directory to vcpkg_configure_make in the portfile. That is the only hint I currently have why the build might be ignoring the libdir setting of vcpkg.

[TrueBrain]

diff --git a/ports/libffi/portfile.cmake b/ports/libffi/portfile.cmake
index eaef8c8..40d936b 100644
--- a/ports/libffi/portfile.cmake
+++ b/ports/libffi/portfile.cmake
@@ -48,6 +48,7 @@ vcpkg_configure_make(
     OPTIONS
         --enable-portable-binary
         --disable-docs
+        --disable-multi-os-directory
         ${options}
 )

With that patch, it installs and works correctly. Shall I make a PR for this? (as in, is that an acceptable solution, or does it need more love somewhere)

[Neumann-A]

With that patch, it installs and works correctly. Shall I make a PR for this?

For me it looks like the correct solution so why not?

[Flole998]

It looks like this broke the builds on x86-linux, at least when building on a x64 linux system. It compiles just fine, however it is failing to add x86/ffi.lo to the target objects so that file is not compiled and linked into the final .a file, which then leads to ffi_call and other important functions to be missing. I've tried to hack around a little to specify the target passed to configure manually, but that didn't help either. I'm out of ideas now on how to convince it to properly build it.

It looks like -m32 only ends up in CXXFLAGS and not in CFLAGS for some reason. That causes the detection to not work properly anymore.

[dg0yt]

Please open a proper issue. The templates should remind you of neccessary information (platform, logs, etc).