embedded frameworks and dyld failure

[Uli Kusterer]

Am 29.09.2007 um 11:53 schrieb scott little:
> I have found that the exact same issue occurs for Mail Plugins that  
> I have written. I was trying to use RBSplitView as a framework from  
> within a plugin and at run time it would always complain about that  
> framework not being there. I could not get the linker to change  
> where it would look at run time no matter what I did. In the end I  
> used the static library supplied for RBSplitView.
>
> I would love to know how to solve this one as well.

  @executable_path literally means the path of the *executable*  
launched. It won't point to the loader of a particular library, it  
will point to the root application in whose memory space all those  
libraries were launched. You'd need something like an @loader_path if  
you want to embed one framework in the other. Since, AFAIK, that  
isn't available yet, you may have to change the path of a bundle that  
is loaded by another bundle so it points at the correct path  
*relative to the application*, not relative to its containing framework.

  Does that help in any way? You'd definitely want to make sure you  
have unique identifiers, too, because frameworks get loaded based on  
their identifier, I think, so it may be possible that if one  
framework got loaded with a particular identifier, the OS may not  
actually load the others.

  Also, make sure your Cocoa class names are unique across *all*  
frameworks. There's only a single namespace for classes, so if you  
load a framework with a class named the same as one already loaded,  
your new class will not be loaded, and your code will use the already  
loaded class instead, which may implement a completely different API.

Cheers,
-- M. Uli Kusterer
http://www.zathras.de