Re: Loading bundle resources using GNUstep runtime 2.0, was: Hint towards solution? Re: ProjectCenter running or building

[Johannes Brakensiek]

Hi Patryk,

On 1 Feb 2020, at 19:18, Patryk Laurent wrote:

Ok, armed with this knowledge, I was able to get ProjectCenter to "work" by doing 2 things:

thank you for proving we’re on the right track. ;)

What does this all mean, and why does this help things work?  I don't know, but I would like to know, as well as the "right" way to fix it.

Well, I think it works, because you have moved the framework to the main bundle (the app bundle). The main bundle path is known and loading from the main bundle works.

Why does it not work otherwise? Here I can just guess. There is much magic going on within NSBundle it seems. This comment beginning in line 638 seems as it is giving some hints:

/* Nicola & Mirko:

   Frameworks can be used in an application in two different ways:

   […]

   (2) the framework was linked into the application.  This is much
   more difficult, because without using tricks, we have no way of
   knowing where the framework bundle (needed eg for resources) is on
   disk, and we have no way of knowing what the class list is, or the
   version.  So the trick we use in this case to work around those
   problems is that gnustep-make generates a 'NSFramework_xxx' class
   and compiles it into each framework.  By asking to the class, we
   can get the version information and the list of classes which were
   compiled into the framework.  To get the location of the framework
   on disk, we try using advanced dynamic linker features to get the
   shared object file on disk from which the NSFramework_xxx class was
   loaded.  If that doesn't work, because the dynamic linker can't
   provide this information on this platform (or maybe because the
   framework was statically linked into the application), we have a
   fallback trick :-) We look for the framework in the standard
   locations and in the main bundle.  This might fail if the framework
   is not in a standard location or there is more than one installed
   framework of the same name (and different versions?).

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.

So there might be two issues:

1. I suspect using the GNUstep runtime version 2.0 there are problems using these „advanced dynamic linker features“. This way of looking up the bundle path relies on using GSPrivateSymbolPath(). Already the code comments of NSBundle make clear that this is a very fragile solution („But in real life GSPrivateSymbolPath() is risky“). So I don’t know if there is a proper way to fix this for the newest runtime. Any help from experienced people is appreciated here. If this fails in the way that it returns a valid but wrong value I won’t be able to fix it.

2. If the fallback way of looking up the bundle path fails, this is something I might be able to at least debug to some extend. The responsible code seems to begin at line 838, the most important function called here seems to be _find_framework() beginning in line 547. The constant which should be set correctly is GSFrameworksDirectory. First hint: If this fails NSWarnMLog (to be activated by which debug flag?) should output an error message (see line 869).

So this is the current result of my research late in the night. ;)

Regards
Johannes