[CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

[Craig Scott]

I don't know if it is an option in your case, but you could build boost
yourself as static libraries. Then the whole build/install rpath situation
goes away. In case it is helpful, I recently gave an example of how I'm
currently doing this with a FetchContent-based solution. It won't suit
everyone, but the approach might be relevant for your particular case.

https://gitlab.kitware.com/cmake/cmake/issues/18831#note_509194


On Wed, Feb 6, 2019 at 9:00 AM Stephens, J. Adam via CMake <cmake at cmake.org>
wrote:

> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when
> installing/packaging, and our packages continue to work fine on OS X 10.12.
> My question is about what to do with executables before packaging, while
> they are still just in the build tree. We need them to work for purposes of
> testing via CTest.
>
> Adam
>
>
> On 2/5/19, 2:56 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:
>
>     My general approach for the second problem is to run a tool such as
>     install_name_tool to change the library names to have @rpath when
>     constructing the package.
>
>     On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>     <cmake at cmake.org> wrote:
>     >
>     > Hello,
>     >
>     >
>     >
>     > The project I work on links to several shared boost libraries. After
> our organization disallowed use of OS X 10.11 and we upgraded our
> built/test slave to 10.12, we encountered a problem with our testing.
> Executables in the build tree that were built as part of our project now
> fail to run with the error that boost libraries can’t be found.
>     >
>     >
>     >
>     > Superficially, the problem is that (I think) Apple strengthened the
> SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any
> effect – previously the linker was able to locate the boost libs for our
> build tree executables that way.
>     >
>     >
>     >
>     > The deeper problem is twofold: First, the build tree executables
> don’t include the boost lib folder in their RPATHs. Second, the install
> names embedded in boost libs themselves are just the bare filenames with no
> @rpath. (My understanding is, the boost project does that deliberately
> because they can’t know what users of their libraries will want.)
>     >
>     >
>     >
>     > Recent versions of CMake (3.8+) have the property BUILD_RPATH that
> we could use to embed the path to the boost libs into the build tree
> executables. That doesn’t solve the second part of the problem, though.
> Without embedding install names that look like @rpath/libboost_foo.dylib in
> the build tree executables, I think the linker will still be unable to find
> them.
>     >
>     >
>     >
>     > What is the best (or least bad) way to fix this?
>     >
>     >
>     >
>     > Thanks!
>     >
>     >
>     >
>     > Adam
>     >
>     >
>     >
>     > --
>     >
>     > J. Adam Stephens, Ph.D.
>     >
>     > Dakota Support Analyst
>     >
>     > https://dakota.sandia.gov/
>     >
>     > Optimization and UQ
>     >
>     > Sandia National Laboratories
>     >
>     > Albuquerque, NM
>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190206/3df8ffdc/attachment-0001.html>