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

[Juan Sanchez]

Hello,

Are you able to use BUILD_WITH_INSTALL_RPATH:
https://cmake.org/cmake/help/v3.13/prop_tgt/BUILD_WITH_INSTALL_RPATH.html
https://cmake.org/cmake/help/v3.13/prop_tgt/INSTALL_RPATH.html#prop_tgt:INSTALL_RPATH

Regards,

Juan


On Tue, Feb 5, 2019 at 4:00 PM 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
>     >
>     >
>     >
>     > --
>     >
>     > Powered by www.kitware.com
>     >
>     > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>     >
>     > Kitware offers various services to support the CMake community. For
> more information on each offering, please visit:
>     >
>     > CMake Support: http://cmake.org/cmake/help/support.html
>     > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     > CMake Training Courses: http://cmake.org/cmake/help/training.html
>     >
>     > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>     >
>     > Follow this link to subscribe/unsubscribe:
>     > https://cmake.org/mailman/listinfo/cmake
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/af9bcd61/attachment.html>