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.
https://gitlab.kitware.com/cmake/cmake/issues/18831#note_509194 On Wed, Feb 6, 2019 at 9:00 AM 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 > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-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
