[cmake-developers] rpaths on Mac

[Clinton Stimpson]

On Friday, November 18, 2011 04:59:36 am David Cole wrote:
> On Thu, Nov 17, 2011 at 5:26 PM, Clinton Stimpson <clinton at elemtech.com> 
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