GTM.framework cannot be bundled in an other framework (or non application bundle)

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Link a non-application bundle against GTM.framework, and copy GTM.framework 
to e.g. 
@loader_path/Frameworks for a framework target. Dynamic linking will fail 
because 
GTM.framework is built with installation path = @executable_path/../Frameworks.

Please provide any additional information below.

As far as I know, the only solution to this problem is to set the GTM.framework 
installation path 
to be @rpath. Applications would then set *their* "Runpath search paths" 
setting to include 
@executable_path/../Frameworks. Frameworks could set their "Runpath search 
paths" to include 
@loader_path/Frameworks. This way GTM.framework can be bundled in app and 
non-app 
bundles.

Original issue reported on code.google.com by barryw...@gmail.com on 25 Feb 2009 at 12:49

[GoogleCodeExporter]

We actually don't really expect people to ship all of GTM as a framework, but 
instead to build it directly into their 
application.  The BuildingAndUsing doc has a comment about this, as time goes 
and we keep adding more to 
GTM, we figure it make more sense to use the framework simple as a initial aide 
to quickly try out some parts of 
GTM, but for shipping an application, it probably makes more sense to directly 
compile the individual sources 
you need so you don't have to carry a lot of code you don't need.

Original comment by thoma...@gmail.com on 25 Feb 2009 at 2:32

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I agree that a shipping product doesn't need to bundle GTM.framework (and I 
appreciate the effort you've put in 
to make the modules independent to allow this), but it's currently not possible 
to *explore* using 
GTM.framework within a non-application target (such as a plugin or framework) 
without modifying the 
GTM.framework target or modifying the application bundle of the app that links 
such a framework or loads such 
a bundle. In addition, for projects that want to track the SVN for GTM, it 
would be easier to use GTM.framework 
all the way through development and switch to direct inclusion of modules only 
at the ramp up to a release 
candidate--that way they benefit from build improvements, project additions, 
dependency changes, etc. without 
having to merge those changes manually.

Original comment by barryw...@gmail.com on 25 Feb 2009 at 10:48

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

There also no reason that changing from @executable_path/../Frameworks to 
@rpath for the installation path 
would eliminate the use case you lay out in comment 1 and in the 
BuildingAndUsing doc. Rather it would add a 
little flexibility to the "aide" stage and would *allow* though not require 
bundling the entire framework.

Original comment by barryw...@gmail.com on 25 Feb 2009 at 10:50

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

just making sure I follow things right, you're talking about a case where:

- you build a framework that links against the gtm framework.
- your framework then goes into another app?  ie-a plugin, to another app or a 
supporting library?

If that's the case, the app might be something that exists, so you can't really 
control it's rpath?  Seems like the 
safest might be to just switch to @loader_path?  That way it's always relative 
to whatever is using GTM.  There 
are still some use cases that could fail, but I'm not sure there's any solution 
that's "right" for all possible 
cases?

Also, @rpath is only valid for 10.5+, so the 10.4 configs would have to stay w/ 
the current value or switch to 
@loader_path.

Original comment by thoma...@gmail.com on 27 Feb 2009 at 4:45

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Yes, you understand correctly, but I don't think @loader_path will work for 
plugins and frameworks. 

Just to be totally explicit, there are two use cases:

1. I'm building Foo.plugin (a loadable bundle) and want to link Foo.plugin 
against GTM.framework *and* 
bundle GTM.framework in Foo.plugin since I do not control the application that 
will load Foo.plugin. In this 
case, the final plugin bundle will look like

Foo.plugin/
  Contents/
    Frameworks/
      GTM.framework
    ...
    MacOS/
      Foo
    ...

Having GTM.framework built with an installation path of 
@loader_path/../Frameworks would support this use 
case.

2. I'm building Bar.framework and want to link Bar.framework against 
GTM.framework *and* bundle 
GTM.framework with Bar.framework. One instance this came up for me was that I 
wanted to replace internal 
implementations in one of our frameworks with implementations from GTM. Since 
our framework is used in 
several apps (internally and by 3rd party developers), I wanted to isolate the 
GTM dependency so that all of 
the build settings of applications that link Bar.framework do not have to all 
be modified. In this case, the final 
Bar.framework package looks like this:

Bar.framework/
  Frameworks/
    GTM.framework
  Bar
  ...

In this case, having GTM.framework installed at @loader_path/../Frameworks does 
not work (it would need to 
be @loader_path/Frameworks).

The difference between framework and plugin/app bundles is a fail on Apple's 
part (rdar://). There is no way, 
using @loader_path (or @executable_path) to support both use cases (1) and (2). 
The solution is to set the 
installation path of GTM.framework to @rpath. Then adding 
@loader_path/../Frameworks to Foo.bundle's LD_RUNPATH_SEARCH_PATHS build 
setting and @loader_path/Frameworks to Bar.framework's LD_RUNPATH_SEARCH_PATHS 
build setting allows both use cases to succeed.

Because @rpath is only 10.5+, I propose changing 10.4 configs to 
@loader_path/../Frameworks, as this would 
support use case (1) which is currently unsuported and changing the 10.5+ 
configs to @rpath as this would 
support both use cases (and many others).

Original comment by barryw...@gmail.com on 27 Feb 2009 at 5:10

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Other solution is to build with -headerpad_max_install_names (which we should 
be doing anyways) and let the 
users set the path how they like with install_name_tool.

Original comment by dmaclach on 27 Feb 2009 at 5:29

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

landed in revision 86

Original comment by thoma...@gmail.com on 27 Feb 2009 at 7:45

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****