boost: Add -headerpad_max_install_names link flag on Apple platforms

[irieger]

Add -headerpad_max_install_names linker flag for boost building on Apple platforms. This change reflects what is done on CMake based builds by default and allows proper library modification for relative load paths after the build.

Specify library name and version: boost/1.80.0

This is also a good place to share with all of us why you are submitting this PR (specially if it is a new addition to ConanCenter): is it a dependency of other libraries you want to package? Are you the author of the library? Thanks!

I'm building a hobby project of mine using conan for the dependencies and found that boost doesn't allow packing via dylibbuilder to correct @rpath linking to work inside the app package. On the conan Slack on cpplang I was told that for cmake -headerpad_max_install_names is a default linker flag. This modifies the boost conanfile to add the appropriate linker flag to the b2 build flags. Hope that is the right place to do this?

I'm currently a bit short on time so I haven't yet checked every item on the checklist below but maybe there can be some general feedback if this approach is good and this change is welcomed.

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the conan-center hook activated.

[CLAassistant]

All committers have signed the CLA.

[ghost]

I detected other pull requests that are modifying boost/all recipe:

• [boost] Fix issues building with Conan 2 and with python #15105
• boost: add Boost.URL #15011
• boost: fix build with icu + improve injection of cpp_info of dependencies #14819
• boost: Add configure options #14625
• (#14605) boost: Add configuration parameters #14606
• Added patch that disables Boost deprecated code which fixes compilation on Clang-15 #13053

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[conan-center-bot]

Conan v1 pipeline

Sorry, the build is only launched for Access Request users. You can request access writing in this issue.

[prince-chrismc]

to correct @rpath linking

🙈 this looks innocent but I have no clue

I am asking for an extra set expert eyes :) hopefully they go on sale soon 😆

[jcar87]

Hi @irieger - I have a couple questions!

found that boost doesn't allow packing via dylibbuilder to correct @rpath linking to work inside the app package.

When Boost from Conan Center is built with -oboost:shared=True, the generated dylib files all have @rpath/libboost_xxx.dylib as their install name. I believe that should already satisfy cases of relocatability.

If by app package you mean a macOS .app bundle, the shared libraries would typically go in the Frameworks library,

MyApp.app/
--
   Contents/
      MacOS/
         my_app_executable
   Frameworks/
         libboost_xxx.dylib

and the executable would have @executable_path/../Frameworks as an RPATH entry - this should allow consuming the boost libraries without any modifications. While it is possible to modify the install name of the boost libraries such that the executable refers to those, it is largely unnecessary these days.

I'm wondering what approach this dylibbuilder tool is following - but I'm surprised this is needed at all.

[jcar87]

Hi @irieger - would you be able to provide more feedback?

[SpaceIm]

I think this PR is fine. All CCI recipes based on CMake, Autotools & Meson inject this flag under the hood when a shared lib or executable is built. It allows to set arbitrary long paths in LC_RPATH afterwards in shared libs or executables built by conan when users want to distribute their application.

@jcar87 The fact that install_name of dependencies is @rpath is necessary to allow LC_RPATH of a runtime artifact to work properly, but not sufficient when you want to set LC_RPATH afterwards.

[irieger]

Sorry for reacting late. Had a few very busy weeks.

I'm wondering what approach this dylibbuilder tool is following - but I'm surprised this is needed at all.
I found it as a solution to pack everything together. With a larger set of dylibs I found it not that easy to get all required things packed together with the correct paths. dylibbuild does exactly this. Failed to work on boost but with the change didn't and as I understand for other build systems that is the default.

But in the end I'm not too deep into this full build processes. This is a hobby project of mine that I finally wanted to link with shared libs as otherwise all of my several binary tools would contain all the dependencies statically linked and pilling up on disc. The full scope of this change might need feedback from someone deeper in the boost build process. Just found this parameter I suggest to change in a guide how to get boost properly packed on mac.

So I'm not sure how I can give more feedback here as I'm myself not fully overseeing this option. But it made sense to me and I wanted to start the discussion.

[jcar87]

Sorry for reacting late. Had a few very busy weeks.

I'm wondering what approach this dylibbuilder tool is following - but I'm surprised this is needed at all.
I found it as a solution to pack everything together. With a larger set of dylibs I found it not that easy to get all required things packed together with the correct paths. dylibbuild does exactly this. Failed to work on boost but with the change didn't and as I understand for other build systems that is the default.

But in the end I'm not too deep into this full build processes. This is a hobby project of mine that I finally wanted to link with shared libs as otherwise all of my several binary tools would contain all the dependencies statically linked and pilling up on disc. The full scope of this change might need feedback from someone deeper in the boost build process. Just found this parameter I suggest to change in a guide how to get boost properly packed on mac.

So I'm not sure how I can give more feedback here as I'm myself not fully overseeing this option. But it made sense to me and I wanted to start the discussion.

Hi @irieger - thanks for your reply. We have reviewed this internally - there is relevant information in the manpages of dyld (the runtime linker/loader) regarding the use of rpath@ which would enable relocatable binaries:

   @rpath/
          Dyld maintains a current stack of paths called the run path
          list.  When @rpath is encountered it is substituted with each
          path in the run path list until a loadable dylib if found.  The
          run path stack is built from the LC_RPATH load commands in the
          depencency chain that lead to the current dylib load.  You can
          add an LC_RPATH load command to an image with the -rpath option
          to ld(1).  You can even add a LC_RPATH load command path that
          starts with @loader_path/, and it will push a path on the run
          path stack that relative to the image containing the LC_RPATH.
          The use of @rpath is most useful when you have a complex
          directory structure of programs and dylibs which can be
          installed anywhere, but keep their relative positions.  This
          scenario could be implemented using @loader_path, but every
          client of a dylib could need a different load path because its
          relative position in the file system is different. The use of
          @rpath introduces a level of indirection that simplies things.
          You pick a location in your directory structure as an anchor
          point.  Each dylib then gets an install path that starts with
          @rpath and is the path to the dylib relative to the anchor
          point. Each main executable is linked with -rpath
          @loader_path/zzz, where zzz is the path from the executable to
          the anchor point.  At runtime dyld sets it run path to be the
          anchor point, then each dylib is found relative to the anchor
          point.

Shared libraries for Apple platforms on macOS should all have @rpath/ as the prefix for their install name. Paired with the relevant information from here. The relevant bit from the text above is that the RPATH entries in the calling executables (The ones that end up loading shared libraries, directly or indirectly), will be taken into account - so when you package your application and libraries from Conan, all you would need to do is make sure the executables have an @rpath entry that points to the location of the libraries (this is typically relative to the location of the executable with @executable_path). This negates the need altogether to have to patch the install names or rpaths of any of the libraries.

The run path stack is built from the LC_RPATH load commands in the depencency chain that lead to the current dylib load.

I'll close this PR since based on the information we have, the change should be unnecessary. However, if you could provide more details about the process you are following to create relocatable bundles, in a way that the binaries created from these recipes are not suitable, please feel free to open an issue and assign it to me and we'll review it.

Thanks!