gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Johannes Brakensiek
Subject: Re: Windows ming64- loading resources in a Framework fails - bundleForClass
Date: Wed, 24 Feb 2021 00:08:06 +0100

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 <plaurent@me.com>
To: David Chisnall <gnustep@theravensnest.org>, Johannes Brakensiek <johannes@brakensiek.info>
Cc: Discuss GNUstep <Discuss-gnustep@gnu.org>
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 <johannes@brakensiek.info> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]