[cmake-developers] rpaths on Mac

[David Cole]

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?