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 <jast...@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.sanc...@gmail.com> > *Date: *Tuesday, February 5, 2019 at 3:37 PM > *To: *"Stephens, J. Adam" <jast...@sandia.gov> > *Cc: *"Maynard, Robert (External Contact)" <robert.mayn...@kitware.com>, " > cmake@cmake.org" <cmake@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@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.mayn...@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@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 > >
-- 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