[feature] fix_apple_shared_install_name: also fix install_name in LC_LOAD_DYLIB of executables in cpp_info.bindirs

[SpaceIm]

• [x] I've read the CONTRIBUTING guide.

For all dylib located in cpp_info.libdirs, conan.tools.apple.fix_apple_shared_install_name changes install_name to @rpath in their LC_ID_DYLIB section and also install_name of their dependencies in LC_LOAD_DYLIB.

But executables located in cpp_info.bindirs are not fixed, so they may not be relocatable if they have been linked to dylib of the same recipe fixed afterwards by conan.tools.apple.fix_apple_shared_install_name (because these executables have been created before the call of this method, so they also need this fix).

For example I'm migrating capnproto recipe to conan v2, here is the result of otool -L on one of its executables after package(), even with fix_apple_shared_install_name(self):

/Users/spaceim/.conan/data/capnproto/0.10.1/_/_/package/86b3b8f1d2506eef508c4383f35d09efc02ebc0b/bin/capnp:
	/lib/libcapnpc-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	/lib/libcapnp-json-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	/lib/libcapnp-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	/lib/libkj-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

(libcapnpc, libcapnp-json, libcapnp & libkj are libraries created & packaged in the same recipe, and properly fixed by fix_apple_shared_install_name())

I would have expected:

/Users/spaceim/.conan/data/capnproto/0.10.1/_/_/package/86b3b8f1d2506eef508c4383f35d09efc02ebc0b/bin/capnp:
	@rpath/libcapnpc-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libcapnp-json-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libcapnp-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libkj-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

[lasote]

Thanks for reporting. Do you have a capnproto branch that we can use to reproduce this?

[SpaceIm]

Yes: https://github.com/conan-io/conan-center-index/tree/03077b819c744da195224c9e5e25783f19bceb9b/recipes/capnproto/all

• Remove this workaround: https://github.com/conan-io/conan-center-index/blob/03077b819c744da195224c9e5e25783f19bceb9b/recipes/capnproto/all/conanfile.py#L143-L144

• Add fix_apple_shared_install_name(self) in package() just before or after https://github.com/conan-io/conan-center-index/blob/03077b819c744da195224c9e5e25783f19bceb9b/recipes/capnproto/all/conanfile.py#L161

[SpaceIm]

I forgot to mention that you should set -o capnproto:with_openssl=False (because openssl recipe is not conan v2 ready, so it propagates frameworkdirs in AutotoolsDeps, leading to an error in this PR of capnproto).

[lasote]

Hi, I was trying a patch for this but:

I would have expected: /Users/spaceim/.conan/data/capnproto/0.10.1///package/86b3b8f1d2506eef508c4383f35d09efc02ebc0b/bin/capnp: @rpath/libcapnpc-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)

That won't work either, because when running the executable, it is in ...efc02ebc0b/bin but the libraries are in ...efc02ebc0b/lib so, the following works but It doesn't look amazing either:

@executable_path/../lib/libhello.0.dylib

WDYT?

[SpaceIm]

I would have expected: /Users/spaceim/.conan/data/capnproto/0.10.1///package/86b3b8f1d2506eef508c4383f35d09efc02ebc0b/bin/capnp: @rpath/libcapnpc-0.10.1.dylib (compatibility version 0.0.0, current version 0.0.0)

That won't work either, because when running the executable, it is in ...efc02ebc0b/bin but the libraries are in ...efc02ebc0b/lib so, the following works but It doesn't look amazing either:

@executable_path/../lib/libhello.0.dylib

WDYT?

There is this trick in capnproto recipe: https://github.com/conan-io/conan-center-index/blob/03077b819c744da195224c9e5e25783f19bceb9b/recipes/capnproto/all/conanfile.py#L121-L122

It allows to call capnproto executables linked to shared capnproto libs without DYLD_LIBRARY_PATH (useful in add_custom_command() of consumers, since it triggers SIP).

However, it's not a robust solution when external dependencies are also shared (because their relative path in conan data tree is not predictable, and an absolute path would break when a package is consumed on a different machine than machine on which package has been built).

Anyway if DYLD_LIBRARY_PATH is properly set at runtime, it works (and if SIP is triggered, it fails, the macOS mess).