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

[Juan Sanchez]

Hello,

How are you adding the library?  Are you using "-L /path/to/boost/libs
-lboost_foo" syntax when using target_link_libraries?  What do you see when
running "otool -L" on the resulting executable?  If you still need to run
install_name_tool, I suppose you can do it using a POST_BUILD cmake command.
https://cmake.org/cmake/help/v3.13/command/add_custom_command.html

Regards,

Juan


On Wed, Feb 6, 2019 at 11:32 AM Stephens, J. Adam <jasteph at sandia.gov>
wrote:

> Hi Juan,
>
>
>
> I believe BUILD_WITH_INSTALL_RPATH would place the correct RPATH in the
> executables. It’s a potentially easier alternative to using the BUILD_RPATH
> property for that purpose. However, I think it’s only half of what needs to
> happen. The linker still would be unable to find the boost libraries
> because their install names do not contain @rpath. Thanks for the
> suggestion.
>
>
>
> --
>
> J. Adam Stephens, Ph.D.
>
> Dakota Support Analyst
>
> https://dakota.sandia.gov/
>
> Optimization and UQ
>
> Sandia National Laboratories
>
> Albuquerque, NM
>
>
>
>
>
> *From: *Juan Sanchez <juan.e.sanchez at gmail.com>
> *Date: *Tuesday, February 5, 2019 at 3:37 PM
> *To: *"Stephens, J. Adam" <jasteph at sandia.gov>
> *Cc: *"Maynard, Robert (External Contact)" <robert.maynard at kitware.com>, "
> cmake at cmake.org" <cmake at cmake.org>
> *Subject: *Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12
>
>
>
> 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/20190206/3b22218f/attachment.html>