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

Tue Feb 1 14:31:53 EST 2011

It sounds to me (since you're not able to use @executable_path) that
stuff from your bundle is depending on being loaded into executables
from more than one path. In which case, you are asking for subtle and
hard-to-diagnose issues down the road (in my opinion)...

I could be wrong ...

What you're saying sounds reasonable, and as long as it works as
expected, then everything should be just fine.

Personally, if I were doing that, I would verify it:
- on other machines, with none of the build products anywhere in sight
(i.e. -- drag-n-drop it to a clean minimal machine and try it there)
- use "Activity Monitor" to see what files are actually loaded at
runtime by various run scenarios (run your app, with/without plugins,
run other exes in your bundle, ...)

Good luck,
David

On Tue, Feb 1, 2011 at 2:07 PM, Scott Fowler <s.fowler at tecplot.com> wrote:
> 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.
>