On Friday, November 18, 2011 04:59:36 am David Cole wrote: > On Thu, Nov 17, 2011 at 5:26 PM, Clinton Stimpson <[email protected]> wrote: > > On Thursday, November 17, 2011 02:03:15 pm Brad King wrote: > >> 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! > > > > Basically, yes, along with: > > set(CMAKE_INSTALL_NAME_DIR "@rpath") > > set(CMAKE_INSTALL_RPATH ...) > > > > To get the desired behavior, we can automate > > set(CMAKE_INSTALL_NAME_DIR "@rpath") > > I think it would be nice to have it be @rpath even in the build tree, but > > I don't see that as a requirement. It could help avoid install name > > changes at install time, or allow people to copy the libraries. > > > >> > 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. > > > > We still need a separate INSTALL_NAME_DIR setting and RPATH setting. > > But from what I can tell, INSTALL_NAME_DIR can be fixed to @rpath. > > > >> > 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. > > > > It does look like we need a switch. But overall, it looks like CMake is > > quite close to having this feature. > > Any idea what the switch can be called? > > > > As a side note, I had been using BundleUtilities and that falls apart > > with @rpath so that is something to fix before having everyone use this. > > > > -- > > Clinton Stimpson > > Elemental Technologies, Inc > > Computational Simulation Software, LLC > > www.csimsoft.com > > -- > > > > 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 > > But shouldn't BundleUtilities simply be unnecessary after adopting > this @rpath strategy/technique?
It would be unnecessary only if all 3rd party libraries also did this. Consider this: The Qt libraries in /Library/Frameworks have an identification name like "QtCore.framework/Versions/4/QtCore." That is just fine for an installation location like /Library/Frameworks, if they adopted the @rpath, then they would require their users to link with -rpath. Also, since they aren't system libraries, one likely wants to package them in a bundle, and any binary that links against Qt will need to be fixed by install_name_tool, even if cmake-built libraries used @rpath. For compatibility, I was thinking BundleUtilities could be modified to understand @rpath, but still change everything to @executable_path and give the same end result as before. We've had talks in the past about BundleUtilities(or a similar thing) taking another argument for the prefix of the installation, so we don't have the same parameter used for the install names. I think we'll need that going forward with rpaths. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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
