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
