KiCad: Create App Bundle with CMake fails on macOS CoreFoundation RPATH @rpath

[hannesweisbach]

Describe the bug

I am trying to make KiCad build under macOS + nix. My last hurdle is that the CMake scripts of KiCad want to create an app bundle during the install phase. This currently fails, because during verification of the created app bundle CMake encounters the non-absolute RPATH to CoreFoundation @rpath/CoreFoundation.framework/Versions/A/CoreFoundation in the dependencies of the executables in the app bundle. Because an app bundle is supposed to be self-contained and CMake does not recognize the reference as one to a system library, verification of the bundle, and hence the install step, fails.

For example, eeschema depends on cairo, which in turn depends on fontconfig:

/nix/store/ip78z0sjkhafnqq6zckm3zx4n3lcf3q3-cctools-binutils-darwin-927.0.2/bin/otool -L /tmp/nix/store/ph6y7bkl31mywl2kh9m6zdvwn9f920v8-kicad-base-c6e7f7de7d/eeschema.app/Contents/MacOS/eeschema
[…]
	/nix/store/aq6g3nkffccdm7lpvl62yfh3xqab8fd0-cairo-1.16.0/lib/libcairo.2.dylib (compatibility version 11603.0.0, current version 11603.0.0)
[…]

/nix/store/ip78z0sjkhafnqq6zckm3zx4n3lcf3q3-cctools-binutils-darwin-927.0.2/bin/otool -L /nix/store/aq6g3nkffccdm7lpvl62yfh3xqab8fd0-cairo-1.16.0/lib/libcairo.2.dylib
[…]
	/nix/store/99apywdnix0j9c8pyb8f6g3gabc3ml45-fontconfig-2.13.92-lib/lib/libfontconfig.1.dylib (compatibility version 14.0.0, current version 14.0.0)
[…]

libfontconfig in turn has an RPATH set:

/nix/store/99apywdnix0j9c8pyb8f6g3gabc3ml45-fontconfig-2.13.92-lib/lib/libfontconfig.1.dylib:
	/nix/store/99apywdnix0j9c8pyb8f6g3gabc3ml45-fontconfig-2.13.92-lib/lib/libfontconfig.1.dylib (compatibility version 14.0.0, current version 14.0.0)
	/nix/store/slm1f903cz47r2hi8v543mj3fcakvwrc-freetype-2.10.2/lib/libfreetype.6.dylib (compatibility version 24.0.0, current version 24.2.0)
	/nix/store/bafwypxc11wp51phssmh9h6vqmwzmnxf-bzip2-1.0.6.0.1/lib/libbz2.1.dylib (compatibility version 2.0.0, current version 2.6.0)
	/nix/store/0hr8d4x5w1046a6mcwgfnyj85f7ylf8g-libpng-apng-1.6.37/lib/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
	/nix/store/ilrm722frr4fb3096wjc6wbspdf7pgyr-zlib-1.2.11/lib/libz.dylib (compatibility version 1.0.0, current version 1.2.11)
	/nix/store/cjflr1cvpkq74ln7j2qndri3a5513797-expat-2.2.8/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.10.0)
	/nix/store/vrxrz8fqi2cmv0z7kxfza2nycbbbkh1k-gettext-0.21/lib/libintl.8.dylib (compatibility version 11.0.0, current version 11.0.0)
	@rpath/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1454.90.0)
	/nix/store/hw4x6gakgd43f13zys92ng0hj0acisls-Libsystem-osx-10.12.6/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

libcontconfig gets copied into app bundle as dependency. CMake notices this:

warning: unexpected reference to '@rpath/CoreFoundation.framework/Versions/A/CoreFoundation'

And finally, the verification step of the Bundle creation fails:

warning: cannot resolve item '@rpath/CoreFoundation.framework/Versions/A/CoreFoundation'

  possible problems:
    need more directories?
    need to use InstallRequiredSystemLibraries?
    run in install tree instead of build tree?

-- warning: gp_resolved_file_type non-absolute file '@rpath/CoreFoundation.framework/Versions/A/CoreFoundation' returning type 'other' -- possibly incorrect
-- verified='0'
-- info='external prerequisites found:
f='/tmp/nix/store/ph6y7bkl31mywl2kh9m6zdvwn9f920v8-kicad-base-c6e7f7de7d/eeschema.app/Contents/MacOS/eeschema'
external_prereqs='@rpath/CoreFoundation.framework/Versions/A/CoreFoundation'
'
--
CMake Error at /nix/store/qzj93zqnp65ryzaqh51nrsyp64mkwrym-cmake-3.18.2/share/cmake-3.18/Modules/BundleUtilities.cmake:1121 (message):
  error: verify_app failed
Call Stack (most recent call first):
  /nix/store/qzj93zqnp65ryzaqh51nrsyp64mkwrym-cmake-3.18.2/share/cmake-3.18/Modules/BundleUtilities.cmake:987 (verify_app)
  eeschema/cmake_install.cmake:78 (fixup_bundle)
  cmake_install.cmake:62 (include)

My question now is, how do I fix or work around this? IIRC, nix uses an RPATH to CoreFoundation to be able to switch between pure and impure versions without recompilation? Correct me, if I'm wrong.

If I hack around this, i.e. make CMake think RPATHs are system libraries and don't need to be copied, the resulting app bundle works for me. So this is basically the last step to have KiCad build on Darwin. Maybe someone can give me hint.

I tried to search for how to build app bundle via CMake under Nix, but Github only let's me search open issues. Whenever I search for closed issues I get the Github unicorn and it tells me generation of the page has timed out :(

To Reproduce
Steps to reproduce the behavior:

1. See nix files: https://gist.github.com/hannesweisbach/e1a9203e3bc2a00f482309cc5a1bfc73
2. Get changes from open PR Add Cocoa to propagatedBuildInputs for tk #96267
3. change into directory of default.nix from (1) and execute nix-shell --pure
4. Build should succeed, but install phase of KiCad will fail.

Expected behavior

Create a working app bundle.

Screenshots

Full install log (CMake verbose enabled)
https://gist.github.com/hannesweisbach/f9c81f08e298f99bb6e55f76d7f40897

Notify maintainers

@evils @Kiwi @berce

Metadata

nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-darwin"`
 - host os: `Darwin 19.6.0, macOS 10.15.6`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.7`
 - channels(hannesweisbach): `""`
 - channels(root): `"nixpkgs-20.09pre242465.bd649f4f55c"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

[veprbl]

My question now is, how do I fix or work around this? IIRC, nix uses an RPATH to CoreFoundation to be able to switch between pure and impure versions without recompilation? Correct me, if I'm wrong.

Never heard of this. Also, changing RPATH is often done via recompilation anyway. I think, changing fontconfig to refer to CoreFoundation by an absolute path would be fine thing to do.

[hannesweisbach]

I assume I fix this by putting CoreFoundation as in buildInputs, right?
Easy enough for fontconfig, but what about gettext and curl? Those are the offending libs I see right now.

[hannesweisbach]

Sorry, wrong button 🤦🏼‍♂️

[veprbl]

@hannesweisbach
It might be easier to just not require bundle to be standalone. Reading the cmake documentation [1], it seems like all you would need to do for this is to somehow disable calls to fixup_bundle() in kicad. In principle, you should be able to build standalone bundle, but that might require some extra tuning to make it work.

[1] https://cmake.org/cmake/help/latest/module/BundleUtilities.html

[hannesweisbach]

Never heard of this. Also, changing RPATH is often done via recompilation anyway.

I read it on some thread on the NixOS discourse.

I think, changing fontconfig to refer to CoreFoundation by an absolute path would be fine thing to do.

I fixed fontconfig by adding CoreFoundation to buildInputs in #98379

It might be easier to just not require bundle to be standalone.

I've created (what do you call them? "pure"?) version of gettext & curl without RPATH references to use for me locally.
I'll work on patching out the calls to fixup_bundle and see of the resulting package contains working executables.

While doing this I looked for libraries in my /nix/store with non-absolute RPATH references to CoreFoundation. Should I be fixing those (assuming they are not bootstrap-packages, like curl and gettext)?

[stale]

I marked this as stale due to inactivity. → More info

[stale]

I marked this as stale due to inactivity. → More info