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

[Patryk Laurent]

Hi,

Another part of the mystery that we shouldn't forget is that _frameworkVersion is not being set, it is always null.  So even if the standard locations were being checked, NSBundle would not not know what version subdirectory to look in...

I am not sure what sets the framework version, and why it is being lost...

Previously, Riccardo was not able to replicate this issue that we have been having.

Patryk

On January 6, 2020 at 1:50 AM, Riccaro Mottola <riccardo.mottola@libero.it> wrote:

Hi Patryk,

On 2020-01-02 19:24:08 +0100 Patryk Laurent <plaurent@me.com> wrote:

Happy new year to you as well! I do see thoss errors when I just

openapp

GWorkspace on its own. Furthermore there is an error specifically

about

failing to load InspectorWin [1].

With the NSLog() at line 2280 I see it (among many other things) has

_frameworkVersion null [2].

Thank you. I don't see a specific GWorkspace issue, but you seem 
indeed to have a generic framework issue and once things do not load, 
various errors appear. I have now clang+libobjc2 set up and I cannot 
reproduce this issue.

Let's try to work together with Fred and David and see if this can 
sorted out for you.

Riccardo

--

On February 1, 2020 at 3:22 PM, Johannes Brakensiek <johannes@brakensiek.info> wrote:

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