Re: GNUstep stack trace & gnustep-base.dll path

[Richard Frith-Macdonald]

On 5 May 2006, at 08:21, Richard Frith-Macdonald wrote:

> On 4 May 2006, at 09:44, David Ayers wrote:
>
> > I guess I was too terse but I would have assumed that:
> >
> > [[NSBundle bundleForLibrary:@"gnustep-base"] executablePath]
> >
> > would be what would give the expected result but indeed, this  
> > returns:
> >
> > /usr/GNUstep/System/Library/Libraries/Resources/gnustep-base/./gnu- 
> > gnu-gnu/gnustep-base
> >
> > for me in a flattended configuration.
> >
> > Should this be considered a bug?
>
> While Adam is the expert on NSBundle, I think this looks like a  
> bug ... probably on a few counts:
>
> 1. I guess in a 'flattened' configuration the 'gnu-gnu-gnu' should  
> not be in there
> 2. The actual path to the library itsself is not in the resources  
> subdirectory
> 3. I would expect the library name to be at the end of the path
>
> Now, I hope that the oddities arise because this bundle is a  
> special case produced by a non-standard method (bundleForLibrary  
> which does not exist in OpenStep/MacOS-X).  While special case code  
> could be considered a feature rather than a bug, I think it's  
> behavior should be consistent with that of other bundles!  I would  
> have thought it should return the path of the library.

After looking at bundleForLibrary: some more ... I'm fairly convinced  
that it should in fact return nil for -executablePath
That's because I'm now much clearer on what this extension does ...  
it provides a resource bundle for a library linked in to the  
executable, but it is nothing to do with the code in the library.   
The bundle is based solely on the library name, and may be used for -
1. a dynamically linked library (the obvious case)
2. a statically linked library (so the original library may not exist  
on the running system!)
3. a library which is not even linked in to the executable ... if you  
want to use its resources but not the code.