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 <jast...@sandia.gov> 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
