embedded frameworks and dyld failure

[scott little]

Uli,

Thanks for this information, it helped a lot, because in searching  
for other @executable_path options (which I was aware of from the  
first time I looked at this) I found that the Tiger Release Notes  
actually DO provide a @loader_path!

http://developer.apple.com/releasenotes/DeveloperTools/RN-dyld/

Works fine now. Note that I have already taken into account the other  
points that you mention here.

scott
--
"Only the curious will learn and only the resolute overcome the  
obstacles to learning. The quest quotient has always excited me more  
than the intelligence quotient."
Eugene S. Wilson
--
scott little
slittle at free.fr
--
sadly no music right now: iTunes is Stopped



On 29 Sep, 2007, at 19:51, Uli Kusterer wrote:

> 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
>
>
>
>