8000 Add cmake configuration files by am11 · Pull Request #535 · libffi/libffi · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add cmake configuration files #535

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

am11
Copy link
@am11 am11 commented Jan 6, 2020

This delta adds cmake configuration files, and targets various platforms and architectures.

Usage

Unix/MinGW environments:

#!/usr/bin/env sh

git clone https://github.com/am11/libffi --branch feature/cmake-build-configs \
  --single-branch --depth 1
mkdir libffi/build
cd $_
cmake ..  # configure: options in AC counterpart can be overriden from command-line
          # e.g.:  cmake .. -DFFI_MMAP_EXEC_EMUTRAMP_PAX=1 -DVERSION=X.Y

# for MinGW:
cmake .. -G "Unix Makefiles"  # can use "MinGW Makefiles", bit i was using
                              # git-for-windows-sdk which complains that we should
                              # "not" have sh.exe in PATH, to proceed.. 😑

cmake --build . --config Release   # build

# builds ./libffi.a and ./libffi.so (or libffi.dylib on macOS)

Visual Studio:

:: just a normal command prompt or powershell
:: (doesn't have to be VS developer command prompt,
:: or a prompt with vcvarsall.bat already ran..)

git clone https://github.com/am11/libffi --branch feature/cmake-build-configs ^
  --single-branch --depth 1
mkdir libffi\build
cd libffi
cmake ..  :: configure: options in AC counterpart are overriden from command-line,
          :: e.g.:  cmake .. -DFFI_MMAP_EXEC_EMUTRAMP_PAX=1 -DVERSION=X.Y

:: or to cross-compile:
cmake .. -A Win32
cmake .. -A ARM
cmake .. -A ARM64

cmake --build . --config Release   :: build

:: builds .\libffi.lib and .\libffi.dll

Minimal supported version of cmake is 2.8.8 (release APR 2012), where add_library(..OBJECT..) was introduced. That is used to prevent it for recompiling sources for static and shared targets (i.e. a negligible optimization). If need be, it can be reworked to support older version.

Introspection cases are written for x86_64, i386, aarch64 and arm ISAs. More cases can be added in future, I do not have access to SPARC and MIPS etc. right now.

Few symbols were dropped in (newly added) :/include/fficonfig.h.in, which are not used in the code and require unnecessary introspection cases; (most prominently LIBFFI_GNU_SYMBOL_VERSIONING).

Tested combinations:

OS ARCH CMAKE RESULT COMMENT
Ubuntu 18.04 x86_64 3.15.4
Ubuntu 16.04 aarch64 3.5.1
Ubuntu 18.04 armv7l 3.10.2
Alpine Linux 3.11.2 aarch64 3.15.5
Alpine Linux 3.5.2 armv7l 3.6.3
CentOS 6.10 i386 2.8.12
FreeBSD 12.0 amd64 3.15.5
SmartOS live release-20180315 x86_64 3.10.1
macOS 10.14.6 X86_64 3.15.3
Windows 10.0.19536.1000 AMD64 3.15.5 × MASM assembler does not like syntax of generated asm. see #275 (comment)
Windows 10.0.19536.1000 X86 3.15.5 × MASM assembler does not like syntax of generated asm. see #275 (comment)
Windows 10.0.19536.1000 ARM64 3.15.5
Windows 10.0.19536.1000 ARM 3.15.5

@am11
Copy link
Author
am11 commented Jan 7, 2020

Fixed win32 and win64 builds with msvc. Problem was:

-#cmakedefine01 HAVE_AS_CFI_PSEUDO_OP
+#cmakedefine HAVE_AS_CFI_PSEUDO_OP

also made it so that emitted .vcxproj gets <MASM> after .S->.asm preprocessing step, as opposed to custom ml[64].exe ... command. For ARM, <ARMASM> is not yet available in VS common targets, so we continue to use armasm[64] .. custom command.

@sztomi
Copy link
sztomi commented Nov 18, 2020

This check:

check_c_source_runs(
    "
    #include <stdlib.h>
    #include <sys/types.h>
    #include <sys/mman.h>
    #include <fcntl.h>
    int main(void) {
        int devzero = open(\"/dev/zero\", O_RDWR);
        return devzero == -1 || mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, devzero, 0) == (void *)-1 ? 1 : 0;
    }" HAVE_MMAP_DEV_ZERO)

breaks cross-compilation from intel mac to arm ("apple silicon"). Is there a better way? Perhaps assuming it's true based on the target?

@am11
Copy link
Author
am11 commented Nov 18, 2020

breaks cross-compilation from intel mac to arm

It breaks as in HAVE_MMAP_DEV_ZERO has unexpected value or cmake aborts? If it is latter, then sounds like bug in the build.
Could you try to compile it manually what's wrong, something like:

$ clang -xc -isysroot $(xcrun -sdk macosx --show-sdk-path) -arch arm64 - <<EOF
    #include <stdlib.h>
    #include <sys/types.h>
    #include <sys/mman.h>
    #include <fcntl.h>
    int main(void) {
        int devzero = open("/dev/zero", O_RDWR);
        return devzero == -1 || mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, devzero, 0) == (void *)-1 ? 1 : 0;
    }
EOF
$ ./a.out
$ echo $?   # should be 0 or 1 (at least on Mojave without -arch arm64, I get 1)

@sztomi
Copy link
sztomi commented Nov 18, 2020

CMake aborts because that check requires running the output. Which is not possible when you are cross-compiling from x86_64 to arm64 (or just cross-compiling in general).

@am11
Copy link
Author
am11 commented Nov 18, 2020

Ah right, I will add cross compile check, cmake has the prior art for it.

@sztomi
Copy link
sztomi commented Nov 18, 2020

I simply added set(HAVE_MMAP_DEV_ZERO 1) to the darwin-aarch64 branch. I don't think there is anything better you can do, because you can't test the target system (by definition), so you need to make assumptions.

@am11
Copy link
Author
am11 commented Nov 18, 2020

Well, we can avoid running that test when cross-compiling, we can dial into tryrun.cmake mechanics etc. but if you are unblocked, great!

@sztomi
Copy link
sztomi commented Nov 18, 2020

Yeah, I'm good, thanks!

@TheOneRing
Copy link

Fails with ninja

  Running

   'C:/CraftRoot/dev-utils/bin/ninja.exe' '-C' 'C:/CraftRoot/build/_/3446fad4/build' '-t' 'cleandead'

  failed with:

   ninja: error: build.ninja:208: multiple rules generate ffi.lib [-w dupbuild=err]





CMake Error:
  Running

   'C:/CraftRoot/dev-utils/bin/ninja.exe' '-C' 'C:/CraftRoot/build/_/3446fad4/build' '-t' 'recompact'

  failed with:

   ninja: error: build.ninja:208: multiple rules generate ffi.lib [-w dupbuild=err]





CMake Warning:

@TheOneRing
Copy link
TheOneRing commented Dec 4, 2020

Fails as the the static import lib and the static lib have the same name.

-- Installing: C:/CraftRoot/build/libs/libffi/image-RelWithDebInfo-3.3/CraftRoot/lib/ffi.lib
-- Up-to-date: C:/CraftRoot/build/libs/libffi/image-RelWithDebInfo-3.3/CraftRoot/lib/ffi.lib
-- Installing: C:/CraftRoot/build/libs/libffi/image-RelWithDebInfo-3.3/CraftRoot/bin/ffi.dll

@am11
Copy link
Author
am11 commented Dec 4, 2020

@TheOneRing, I did not try with ninja, but does the following patch help ninja build:

--- CMakeLists.txt
+++ CMakeLists.txt

- set_target_properties(ffi_static PROPERTIES OUTPUT_NAME ffi)
+ set_target_properties(ffi_static PROPERTIES)

@TheOneRing
Copy link

Yes.
Also a .pc would be nice as many projects still rely on it

@fatduckling
Copy link

Hi team, any chance we can revisit this as it's been a few years? Having support for CMake will allow us to do cross compilation more easily. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0