[CMake] Help with fixup_bundle for Mac OS - @executable_path, @loader_path, @rpath

[Scott Fowler]

fixup_bundle is doing everything we need it to on Mac, except that the install_names are "wrong".  It seems that we might be able to just execute a script at install time to change @executable_path to @loader_path.  This gets us 90% of the way.

> otool -L QtGui.framework/Version/4/QtGui
Old: @executable_path/../Frameworks/QtCore.framework/Version/4/QtCore
New: @loader_path/../Frameworks/QtCore.framework/Version/4/QtCore

Just changing to @loader_path doesn't work for the Frameworks because they're now pointing to the wrong relative path.  If our install time script can change "@loader_path/.." to "@loader_path/../../../../" (just for the Frameworks) we'd be golden.

Does that sound like a reasonable solution, or am I just asking for pain later?

Thanks for the input.

-----Original Message-----
From: David Cole [mailto:david.cole at kitware.com]
Sent: Tuesday, February 01, 2011 10:49 AM
To: Scott Fowler
Cc: Sean McBride; cmake at cmake.org
Subject: Re: [CMake] Help with fixup_bundle for Mac OS - @executable_path, @loader_path, @rpath

We only have "exepath" defined with which to make a replacement.

BundleUtilities is strongly biased toward having everything be
relative to the main bundle executable (or a similarly-pathed
executable) because of that very line of code. We are using
@executable_path occurrences to actually resolve to real files in
order to make all the logic work well. We need to locate real files at
fixup time in order to make sure the final bundle is truly
stand-alone.

This is a much more difficult task if you start throwing @loader_path
references into files -- because BundleUtilities *cannot* know via
static analysis what loader_path refers to when it is found in a file
other than the one currently being analyzed. We only know what
@executable_path is because we make the simplifying assumption that
all executables will be located in the same relative location to the
libraries they depend on.

So: if your bundle consists of executables located in more than one
path depth..... BundleUtilities is not going to be sufficient, and you
will have to use it simply as a guide for your own custom solution.


Does that help?

David



On Tue, Feb 1, 2011 at 1:19 PM, Scott Fowler <s.fowler at tecplot.com> wrote:
> How well does @loader_path work with line 372 in BundleUtilities.cmake?  It doesn't seem to make any allowances for @loader_path or @rpath.
>
>    string(REPLACE "@executable_path" "${exepath}" resolved_embedded_item "${embedded_item}")
>    get_filename_component(resolved_embedded_item "${resolved_embedded_item}" ABSOLUTE)
>
> Scott
>
> -----Original Message-----
> From: Sean McBride [mailto:sean at rogue-research.com]
> Sent: Tuesday, February 01, 2011 9:26 AM
> To: Scott Fowler; cmake at cmake.org
> Subject: Re: [CMake] Help with fixup_bundle for Mac OS - @executable_path, @loader_path, @rpath
>
> On Tue, 1 Feb 2011 08:39:08 -0800, Scott Fowler said:
>
>>I have an application "Foo" which distributes a plugin for a separate
>>application "Bar".  My plugin is dependent on libraries distributed with
>>application "Foo".  When application "Bar" tries to load the plugin, the
>>plugin will not load, as it cannot find the libraries distributed with "Foo".
>>
>>As far as I can tell this boils down to the @executable_path reference
>>which fixup_bundle inserts into my binaries.
>>
>>>otool -L plugin.dylib
>>@executable_path/../MacOS/libsomedependency.dylib
>>@executable_path/../MacOS/libsomeotherdependency.dylib
>>etc...
>>
>>When application "Bar" loads my plugin, I'm assuming that
>>@executable_path resolves to the location of "Bar", but the plugin's
>>dependent libraries are in Foo.app/Contents/MacOS, not in Bar.app/
>>Contents/MacOS.
>>
>>All this leads me to believe that I should be using @loader_path or
>>@rpath instead, but I don't see a way to do this using CMake as it
>>appears that BundleUtilities.cmake and GetPrerequisites.cmake are
>>hardcoded to use @executable_path.
>
> Install names are such a PITA.  Here's a great overview:
> <http://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-
> names.html>
>
> @loader_path was added in 10.4, and assuming you don't need to support
> anything older, you should never use @executable_path because
> @loader_path is the same or better.  Not sure if it will solve your
> problem though.
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>
> This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed.  If you are NOT the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying this e-mail is strictly prohibited.
> _______________________________________________
> 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://www.cmake.org/mailman/listinfo/cmake
>

This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed.  If you are NOT the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing or copying this e-mail is strictly prohibited.