Linking to boost on OS X 10.12

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Linking to boost on OS X 10.12

CMake mailing list

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
Reply | Threaded
Open this post in threaded view
|

Re: Linking to boost on OS X 10.12

CMake mailing list
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
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

CMake mailing list
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" <[hidden email]> 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
    <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

CMake mailing list
The version of the libraries that you load from your build directory
would need to be fixed up to.

On Tue, Feb 5, 2019 at 5:00 PM Stephens, J. Adam <[hidden email]> 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" <[hidden email]> 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
>     <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Craig Scott-3
In reply to this post by CMake mailing list
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.



On Wed, Feb 6, 2019 at 9:00 AM Stephens, J. Adam via CMake <[hidden email]> 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" <[hidden email]> 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
    <[hidden email]> 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

Get the hand-book for every CMake user: Professional CMake: A Practical Guide

--

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
Reply | Threaded
Open this post in threaded view
|

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

Juan E. Sanchez
In reply to this post by CMake mailing list

On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake <[hidden email]> 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" <[hidden email]> 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
    <[hidden email]> 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

--

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
Reply | Threaded
Open this post in threaded view
|

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

CMake mailing list
In reply to this post by CMake mailing list
Robert,

We unfortunately can't just modify the boost libraries where they are installed because our customers need to be able to build our project from source, and they would need to do the same thing. We could perhaps do something more radical like copy those libraries into the build tree and modify them, or build our own boost as part of our project.

Alternatively, we could use install_name_tool  to edit the build tree executables and change their dependencies from libboost_foo.dylib to @rpath/libboost_foo.dylib, just like we do for the executables we install. Can you think of a mechanism in CMake that would allow us to run install_name_tool on our executables as a final step in the build process?

Thanks again for your help.

Adam

--
J. Adam Stephens, Ph.D.
Dakota Support Analyst
https://dakota.sandia.gov/
Optimization and UQ
Sandia National Laboratories
Albuquerque, NM

 

On 2/5/19, 3:06 PM, "Robert Maynard" <[hidden email]> wrote:

    The version of the libraries that you load from your build directory
    would need to be fixed up to.
   
    On Tue, Feb 5, 2019 at 5:00 PM Stephens, J. Adam <[hidden email]> 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" <[hidden email]> 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
    >     <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

CMake mailing list
In reply to this post by Juan E. Sanchez

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 <[hidden email]>
Date: Tuesday, February 5, 2019 at 3:37 PM
To: "Stephens, J. Adam" <[hidden email]>
Cc: "Maynard, Robert (External Contact)" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

 

 

On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake <[hidden email]> 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" <[hidden email]> 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
    <[hidden email]> 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


--

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
Reply | Threaded
Open this post in threaded view
|

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

Juan E. 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.

Regards,

Juan


On Wed, Feb 6, 2019 at 11:32 AM Stephens, J. Adam <[hidden email]> 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 <[hidden email]>
Date: Tuesday, February 5, 2019 at 3:37 PM
To: "Stephens, J. Adam" <[hidden email]>
Cc: "Maynard, Robert (External Contact)" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

 

 

On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake <[hidden email]> 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" <[hidden email]> 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
    <[hidden email]> 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


--

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