Re: Loading bundle resources using GNUstep runtime 2.0

[Johannes Brakensiek]

Hello everyone,

Am 02.02.20 um 00:22 schrieb Johannes Brakensiek:
> Using the debugger I did not see that „the standard locations“ (like 
> …/Library/Frameworks) were tested. So currently it seems to me the 
> fallback case is never reached. It might well be that the default way of 
> looking up the bundle path using GSPrivateSymbolPath() returns something 
> that seems valid but does not work or just is the path of the main 
> bundle. We’d need to further investigate here.

after some hours of debugging I found out the following:

GSPrivateSymbolPath() works, but it always returns a path like 
/usr/GNUstep/Local/Library/Libraries/libOperation.so.1

So the subdir is Libraries and even +(NSBundle 
*)bundleForLibrary(NSString *)libraryName version:(NSString 
*)interfaceVersion (NSBundle.m) only looks within "Libraries" so the 
bundle at Library/Frameworks cannot be found this way. But as testing of 
the paths of LD_LIBRARY_PATH follows after this, the bundle is usually 
found.

The cause that looking up a bundle/framework by a linked class name 
fails is that [framework frameworkClasses] returns null as well as 
frameworkVersion returns 0.

Framework classes should be set by the code at lines 888 until 900 but 
this does not work the way it should it seems.

This interface for this is defined in NSBundle.m:

@interface NSObject (PrivateFrameworks)
+ (NSString*) frameworkVersion;
+ (NSString**) frameworkClasses;
@end

I don't know if this way of defining the interface might lead to 
problems using the new runtime?

Apparently the implementation is defined when building the framework as 
you can see at 
https://github.com/gnustep/tools-make/blob/master/Instance/framework.make, 
lines 488 until 499.

Help is appreciated once more. ;)

Thanks in advance
Johannes