On 11/17/2011 11:49 AM, Clinton Stimpson wrote:
I'm experimenting with using @rpath instead of @executable_path and @loader_path, because @rpath is useful in some situations where the others don't work as well. For example, I want to avoid setting DYLD_LIBRARY_PATH when using a relocatable SDK. Using @rpath allows a user to embed a path in their executable/library that gives the location of the SDK libraries that they linked with. Public SDK libraries would also know how to find private SDK libraries with an rpath of @loader_path and dependencies starting with @rpath. What needs to be considered if the following is added to Platforms/Darwin.cmake? set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,") set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG_SEP ":")
Is that all that is necessary to get the standard RPATH behavior on OS X? Nice!
Would that have undesirable side effects?
Since the original RPATH support in CMake pre-dated the feature on OS X we implemented INSTALL_NAME_DIR instead. We need to investigate how the two features would/should interact.
One possibility is adding -rpath link flags to those who currently don't have/want it.
We may need a switch to choose between RPATH and INSTALL_NAME_DIR. The default of the switch can be chosen based on the minimum required version of CMake. Over time everyone will start using RPATH instead. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
