Re: Windows ming64- loading resources in a Framework fails - bundleForClass

Hi Riccardo,

On 23 Feb 2021, at 23:42, Riccardo Mottola wrote:

> where GNUstep runs on Windows msys2 (mingw64) some GORM files to load. 
> Test is ProjectCenter, which loads the main interface file (menu) but 
> nothing else, like the LogPanel
>
> Tracking this down a little with Fred, I think I found that NSBundle's 
> "bundleForClass" fails.
>
> A class which is inside ProjectCenter's Framework appears to be 
> indentified as being part of the application and not its Framework:
>
> warning: 2021-02-23 23:22:15.664 ProjectCenter[5688:5276] NSLog 
> bundleForClass lib: C:\msys64\mingw64\Local\Tools\ProjectCenter-0.dll
> warning: 2021-02-23 23:22:15.664 ProjectCenter[5688:5276] Path for NIB 
> file LogPanel.gorm
>
> does this anomaly ring a bell for somebody?
>
>
> very interesting is that on old msys-1 where I upgraded all core 
> libraries, it works! so it is not a fully windows specific thing, but 
> something for mingw64, I guess a hack going bad??

yes, my bell is ringing. I went through a very similar issue nearly 
exactly one year ago.

This was the result:

Forwarded message:

> From: Patryk Laurent <[email protected]>
> To: David Chisnall <[email protected]>, Johannes Brakensiek 
> <[email protected]>
> Cc: Discuss GNUstep <[email protected]>
> Subject: nm not finding __objc_class names Re: Loading bundle 
> resources using GNUstep runtime 2.0
> Date: Sun, 16 Feb 2020 12:42:49 -0800
>
> Hi,
>
>> On Feb 16, 2020, at 11:17, Johannes Brakensiek 
>> <[email protected]> wrote:
>>
>> 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 see the list “frameworkClasses” is meant to be populated during 
> the make process running “nm *.o -Pg” as part of 
> EXTRACT_CLASS_NAMES_COMMAND. Defined in target.make, this command is 
> used to look for lines output from nm starting with 
> “__objc_class_name”.
>
> However, when I tried running nm manually on the objects in 
> ProjectCenter.obj, grep shows *no* lines containing __objc_class_name.
>
> @David do you have any insight as to why the names of the classes are 
> not be appearing?  Should they be appearing?
>
> Regards,
> Patryk

So I suspect mingw64 is writing class names in a format target.make does 
not match when reading and embedding the class list of the framework?

Johannes