[feature] Provide macOs packages to build with @rpath in install names

[gabyx]

The rather old answer describes the problem quite well: #1238 (comment)

On macOS it would help a lot if all packages in ConanCenter have an option (if not defaulted…) to have install names prepended with @rpath. This is already available for conan builds but probably in a lot of packages not activated etc? This would align it better to Linux and would make debugging much easier. As executables can use the RPATH facility to load the libs from Conan. Lots of packages come with naked install names posing quite some headache and not so good behavior (see answer above).

• I've read the CONTRIBUTING guide.

[memsharded]

I am not sure about the request, you mean adding rpaths always?

In the new integrations, we are trying to respect as much as possible what the users build scripts are doing. We map only the minimum information from the Conan settings, like defining the architecture, or if the library is shared or static. But things like rpaths seems like something Conan should not change? The current CMake default for example is not good enough? I am not sure that Conan changing the default CMake behavior would be a good approach.

[gabyx]

Ah so your saying, any package in ConanCenter (e.g fmt::fmt) which has naked install paths on macOS is the CMake default behavior, because MACOSX_RPATH is default to off?

I think with naked install_names which then the loader does not consider the RPATHS mechanism as described in the post above, seems to be simplifiying to much. With naked install_names the behavior is similar to Windows (which is anyway a nuissance) So, only LD_LIBRARY_PATH mechanism can be used to run the executable, which is a big disadvantage IMO. I dont understand why RPATH mechanics are turned off on macOS, since it does not hinder anything (on precondition that you only have relative paths etc in any RPATH (@executable_path etc.))

Havigh RPATH properly setup enables to have a cmake build & install where the binaries properly work without having
to fiddle with the environment (linux,mac, windows still needs dll copying).

[SpaceIm]

I'm currently fixing all CCI recipes regarding shared libs on macOS: https://github.com/conan-io/conan-center-index/pulls?q=is%3Apr+in%3Atitle+relocatable+macos

It will take lot of time since they are all polluted by conan_basic_setup() without KEEP_RPATHS argument (don't know why CMAKE_MACOSX_RPATH is disabled by default in conan_basic_setup() of cmake generator).
With new generators & helpers, it should be fine, but recipes must still ensure that https://cmake.org/cmake/help/latest/policy/CMP0042.html is set to NEW (a CMakeLists requiring a version of CMake lower than 3.0 would have this policy set to OLD by default).

So basically:

• always call conan_basic_setup(KEEP_RPATHS) (new CMakeToolchain is fine by default, but not used in conan-center for the moment).
• externally inject CMAKE_POLICY_DEFAULT_CMP0042 NEW if upstream CMakeLists has min version lower then 3.0
• always rely on install target instead of self.copy in package() (so that rpath of shared libs in the install tree is cleared, which is not the case for shared libs in the build tree).

Autotools based recipe are also broken without manual fix of configure script (here it's a "bug" in autotools actually). Few recipes have this fix, it must be extended to all autotools based recipe.

I've also suggested to implement a hook in conan-center to ensure that shared libs are:

• relocatable (which means @rpath/libname on macOS).
• rpath is cleared after installation

[gabyx]

Thats sounds very crisp! Thanks for your effort!

[memsharded]

This needs a check ("look into") into the new integrations (CMakeToolchain, AutotoolsTolchain...) to see what is the current status and approach.

[jcar87]

Hi @gabyx - I can confirm that @SpaceIm 's summary is accurate.

The newer CMake integrations in Conan 2.0 will no longer alter CMake's default behaviour with regards to install name handling for macOS shared libraries.

In general, it will be down to the recipe (or the upstream libraries themselves) to "do the right thing" when it comes to building relocatable libraries with the @rpath/ install name convention on Apple platforms, or at least provide ways to do so.

For recipes of libraries that are built with CMake, if the minimum declared version causes the CMP0042 policy to be "NEW", and the install target is called to package the binaries, then libraries should already be packaged correctly.

Mileage may vary with other build systems, or libraries that override CMake's own default behaviour in this regard. In order of preference, this may require: upstream fixes, patches in the recipe, or patching the files in the package() method after they are generated. For the last case (patching the files in the package() method), we are going to introduce a new function in tools to traverse the package tree and fix the install names of packaged dylib files. We believe other build systems may still be using other conventions and a standalone tool could be useful beyond only Autotools.

From what I can see, packages in Conan Center are already moving towards this convention - I have downloaded a few libraries and they seem correct in this regard. Please feel free to raise new issues in Conan Center's GitHub page if you encounter any recipe that needs fixing.

[gabyx]

@jcar87 Nice to here, that sounds pretty reasonable.
Out of curisosity: The new function in tools will change the package? Wasn't the immutability of the package an unchangable design decision?

[memsharded]

Out of curisosity: The new function in tools will change the package? Wasn't the immutability of the package an unchangable design decision?

This tool would execute as the final step in the package() method. That is, before the final package is formed. It is not intended to execute at package installation time, but at package creation time. So the immutability of packages still holds intact.

[memsharded]

#11365 moves the autotools.install() functionality to its own apple tool. CMake will do the right thing, this is only necessary for some autotools (and maybe other different build systems) projects.