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

2019-02-05 Thread Robert Maynard via CMake
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
 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


[CMake] Linking to boost on OS X 10.12

2019-02-05 Thread Stephens, J. Adam via CMake
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