> On Jul 10, 2019, at 4:42 AM, Eric Doenges <doen...@mvtec.com> wrote: > > The simplest way to do this is to use the BUILD_RPATH and/or INSTALL_RPATH > properties, i.e. something like: > > list(GET BLAS_LIBRARIES 0 _BLAS_FIRSTLIB) > get_filename_component(_BLAS_LIBDIR "${_BLAS_FIRSTLIB}" DIRECTORY > set_target_properties(test_blas PROPERTIES BUILD_RPATH "${_BLAS_LIBDIR}") > > This assumes BLAS_LIBRARIES is a list of libraries specified with absolute > paths; if this assumption is incorrect, you must figure out the directory to > specify to BUILD_RPATH some other way. If the tests are run using the > installed binary (or you build your binaries using the install rpath from the > start, like we do), then you must set INSTALL_RPATH instead of BUILD_RPATH. > For a detailed description, see the CMake wiki page on RPATH handling > <https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling>. > > Also note that while I think this should work, I haven't actually tested it > myself. >
Thank you Eric, this does work. I have a large number of test executables and more are always being added by users, so I appended the result to the CMAKE_BUILD_RPATH in the test root directory and this results in the expected behavior. Luke > Am 09.07.19 um 16:22 schrieb Luke D'Alessandro: >> Hi all, >> >> I have one of those complex interactions that results in an issue where it’s >> not clear to me which component is responsible. >> >> I have unit tests written using CTest that depend on Intel's MKL BLAS >> implementation. I use find_package(BLAS) and link the test executables to >> ${BLAS_LIBRARIES}. The test executables depend on the DYLD_LIBRARY_PATH to >> find the mkl libraries, rather than an embedded LC_RPATH. >> >> Unfortunately, because of Apple’s SIP, the DYLD_LIBRARY_PATH is not >> propagated to the ctest environment, so when it tries to run the >> tests it fails to link the MKL libraries. >> >> I need to get CMake to embed an external LC_PATH for test executables in the >> build directory. >> >> Here's a basic test executable (test.cpp) >> >>> #include <mkl_cblas.h> >>> >>> int main() { >>> return &cblas_dgemm != nullptr; >>> } >> >> and here is the associated CMakeLists.txt >> >>> cmake_minimum_required(VERSION 3.14.5) >>> >>> project(blas LANGUAGES CXX) >>> include(CTest) >>> >>> set(BLA_VENDOR Intel10_64lp_seq) >>> find_package(BLAS REQUIRED) >>> >>> add_executable(test_blas test.cpp) >>> target_link_libraries(test_blas ${BLAS_LIBRARIES}) >>> >>> add_test(NAME test_direct COMMAND test_blas) >> This finds MKL and builds and links the executable without any problem, and >> I can run it manually from my shell. But when I run with CTest I have the >> SIP issue because MacOS won’t propagate the necessary DYLD_LIBRARY_PATH into >> CTest’s environment. >> >>> Lukes-MacBook:test ldalessa$ make test >>> Running tests... >>> Test project /Users/ldalessa/test >>> Start 1: test_direct >>> 1/1 Test #1: test_direct ......................Child aborted***Exception: >>> 0.01 sec >>> >>> 0% tests passed, 1 tests failed out of 1 >>> >>> Total Test time (real) = 0.01 sec >>> >>> The following tests FAILED: >>> 1 - test_direct (Child aborted) >>> Errors while running CTest >>> make: *** [test] Error 8 >> >>> Lukes-MacBook:test ldalessa$ cat Testing/Temporary/LastTest.log >>> Start testing: Jun 10 03:35 PDT >>> ---------------------------------------------------------- >>> 1/1 Testing: test_direct >>> 1/1 Test: test_direct >>> Command: "/Users/ldalessa/test/test_blas" >>> Directory: /Users/ldalessa/test >>> "test_direct" start time: Jun 10 03:35 PDT >>> Output: >>> ---------------------------------------------------------- >>> dyld: Library not loaded: @rpath/libmkl_intel_lp64.dylib >>> Referenced from: /Users/ldalessa/test/test_blas >>> Reason: image not found >>> <end of output> >>> Test time = 0.01 sec >>> ---------------------------------------------------------- >>> Test Failed. >>> "test_direct" end time: Jun 10 03:35 PDT >>> "test_direct" time elapsed: 00:00:00 >>> ---------------------------------------------------------- >>> >>> End testing: Jun 10 03:35 PDT >>> Lukes-MacBook:test ldalessa$ >> My temporary workaround for this is currently to use Apple's Accelerate >> framework instead of MKL, which links using an embedded LC_PATH properly. >> The reason this isn’t adequate is that it is an intrusive solution. Intel's >> MKL uses different headers (mkl_blas.h, mkl_lapack.h) and symbol names which >> are explicitly used in the source code, so I have to have extra >> configure-time and configured header changes to adapt the code base to >> Accelerate. We also don’t (and won’t) have verified and validated code with >> Accelerate so it’s not a long term solution to our issues. Disabling SIP is >> also a non-starter. >> >> Thanks, >> Luke >> >> (https://stackoverflow.com/questions/56524774/how-to-use-ctest-on-macos-without-disabling-sip-no-lc-path-is-set >> >> <https://stackoverflow.com/questions/56524774/how-to-use-ctest-on-macos-without-disabling-sip-no-lc-path-is-set>) >> >> >> > -- > Dr. Eric Dönges > Senior Software Engineer > > MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany > doen...@mvtec.com <mailto:doen...@mvtec.com> | Tel: +49 89 457 695-0 | > www.mvtec.com <http://www.mvtec.com/> > Sign up <http://www.mvtec.com/newsletter> for our MVTec Newsletter! > > Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt > Amtsgericht München HRB 114695 > >
-- 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