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

[Johannes Brakensiek]

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 
To: David Chisnall , Johannes Brakensiek 


Cc: Discuss GNUstep 
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 
 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

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

[Richard Frith-Macdonald]

> On 23 Feb 2021, at 23:08, Johannes Brakensiek  
> wrote:
> 
> 
> yes, my bell is ringing. I went through a very similar issue nearly exactly 
> one year ago.
> 
> This was the result:

...

>> 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?
> 

Thanks a lot.  That was a great hint.
I was able to reproduce Riccardo's problem, and use your hint to investigate.
Looking at the symbols in the object files, they began with __ (two underscores)
Looking atwhat gnustep-make was doing, I could see it was looking for a prefix 
of three underscores
The difference there is between mingw32 (uses three underscores) and mingw64 
(uses two underscores, like linux/bsd etc).
So I needed to figure out why gnustep-make was using the command for mingw32 on 
a mingw64 system.

It turns out the culprit was /mingw64/etc/config.site setting the target host 
type to be mingw32
I don't know why it does that (it comes from the mingw/msys distribution) ... 
maybe it's a mistake/bug, or maybe they think people using mingw64 actually 
want to cross-compile for mingw32 (seems perverse).

Anyway, it can be overridden by using --host=mingw64 when configuring 
gnustep-make, as a command line argument takes precedence over information from 
config.site

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

[Johannes Brakensiek]

On 24 Feb 2021, at 13:45, Richard Frith-Macdonald wrote:


Thanks a lot.  That was a great hint.
I was able to reproduce Riccardo's problem, and use your hint to 
investigate.


Great! Glad I could help.

Thank you for your detailed description. Should help a lot for further 
issues.


Johannes

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

[Riccardo Mottola]

Hi Richard!

Richard Frith-Macdonald wrote:

Thanks a lot.  That was a great hint.
I was able to reproduce Riccardo's problem, and use your hint to investigate.
Looking at the symbols in the object files, they began with __ (two underscores)
Looking atwhat gnustep-make was doing, I could see it was looking for a prefix 
of three underscores
The difference there is between mingw32 (uses three underscores) and mingw64 
(uses two underscores, like linux/bsd etc).
So I needed to figure out why gnustep-make was using the command for mingw32 on 
a mingw64 system.

It turns out the culprit was /mingw64/etc/config.site setting the target host 
type to be mingw32
I don't know why it does that (it comes from the mingw/msys distribution) ... 
maybe it's a mistake/bug, or maybe they think people using mingw64 actually 
want to cross-compile for mingw32 (seems perverse).


To me it seems perverse... or perhaps a bug? I do see:

MSYSTEM_CHOST=x86_64-w64-mingw32
MSYSTEM_CARCH=x86_64
CONTITLE=MinGW x64
PROCESSOR_ARCHITECTURE=AMD64

So it really knows it is 64bit.

On the 32bit shell, I see:
MSYSTEM_CHOST=i686-w64-mingw32

I opened a bug on mingw to ask for explanations:

ming64_64 host type set to mingw32 · Issue #8020 · msys2/MINGW-packages 
(github.com) 




Anyway, it can be overridden by using --host=mingw64 when configuring 
gnustep-make, as a command line argument takes precedence over information from 
config.site



I tried, reconfigured make, rebuilt ProjectCenter and it works!


I documented this on the wiki, just to remember!

Riccardo

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

[Riccardo Mottola]

Hi,

Richard Frith-Macdonald wrote:

It's a mistake/bug, or maybe they think people using mingw64 actually want to 
cross-compile for mingw32 (seems perverse).
Anyway, it can be overridden by using --host=mingw64 when configuring 
gnustep-make, as a command line argument takes precedence over information from 
config.site



I actually found this informative info, which in case would also allow 
us to distinguis between the original mingw and mingw, if needed, the 
key is the w64 vs. pc


Citing:

This triplet specifies where the executables produced by this program (gcc) 
will run. Originally the
MinGW.org project chose `*-pc-mingw32`, so we selected `*-w64-mingw32` to avoid 
the conflict.

There is no special meaning about `w64` itself. `mingw32` on the other hand 
specifies the ABI, so
all `i686-*-mingw32` targets are considered ABI-compatible.

Neither does `w64` specify the target is 64-bit, nor does `mingw32` specify the 
target is 32-bit.
They are just hard-coded names.

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

[Riccardo Mottola]

Hi,

Richard Frith-Macdonald wrote:

It turns out the culprit was /mingw64/etc/config.site setting the target host 
type to be mingw32
I don't know why it does that (it comes from the mingw/msys distribution) ... 
maybe it's a mistake/bug, or maybe they think people using mingw64 actually 
want to cross-compile for mingw32 (seems perverse).

Anyway, it can be overridden by using --host=mingw64 when configuring 
gnustep-make, as a command line argument takes precedence over information from 
config.site


perhaps we should change the way we use the host information? I got an 
answer from the bug.

From there I found this:

https://sourceforge.net/p/mingw-w64/wiki2/TypeTriplets/

- i686-w64-mingw32
- x86_64-w64-mingw32

so "ming32" is the name of the "vendor", it is confusing... I guess it 
kept compatibility with the original mingw project. But, in case it 
would be called like "mingw2" but still be the same.


The architecture is i686 or x86_64, can we match that to make the 
decisions in gnustep-make?


Riccardo

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

[Richard Frith-Macdonald]

> On 25 Feb 2021, at 11:05, Riccardo Mottola  wrote:
> 
> Hi,
> 
> Richard Frith-Macdonald wrote:
>> It's a mistake/bug, or maybe they think people using mingw64 actually want 
>> to cross-compile for mingw32 (seems perverse).
>> Anyway, it can be overridden by using --host=mingw64 when configuring 
>> gnustep-make, as a command line argument takes precedence over information 
>> from config.site
>> 
> 
> I actually found this informative info, which in case would also allow us to 
> distinguis between the original mingw and mingw, if needed, the key is the 
> w64 vs. pc
> 
> Citing:
> 
> This triplet specifies where the executables produced by this program (gcc) 
> will run. Originally the
> MinGW.org project chose `*-pc-mingw32`, so we selected `*-w64-mingw32` to 
> avoid the conflict.
> 
> There is no special meaning about `w64` itself. `mingw32` on the other hand 
> specifies the ABI, so
> all `i686-*-mingw32` targets are considered ABI-compatible.
> 
> Neither does `w64` specify the target is 64-bit, nor does `mingw32` specify 
> the target is 32-bit.
> They are just hard-coded names.

Autoconf refers to the parts of the triplet as 
CPU-TYPE-MANUFACTURER-OPERATING_SYSTEM
config.guess returns x86_64-pc-mingw64

I don't really buy the argument that mingw32 and mingw64 are ABI compatible ... 
maybe it's technically/theoretically true for some definition of ABI, but it's 
praqctically false since in practice the two are tied to different processor 
architectures.
Certainly Autoconf (in the form opf config.guess) does not believe it.

Still, since the mingw64 people seem to have chosen to do it this way, and 
presumably can't easily change, and the autoconf people probably don't want to 
change a standard that they 'own', I guess we will need to find a way to work 
around the fact that, depending on where you get the triplet from, it might say 
the system is mingw64 or might say it's mingw32.
We will need to find where gnustep-make looks for either, and put additional 
checks in place for other parts of the triplet.

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

[Richard Frith-Macdonald]

> On 25 Feb 2021, at 11:49, Richard Frith-Macdonald 
>  wrote:
> 
> 
> 
>> On 25 Feb 2021, at 11:05, Riccardo Mottola  
>> wrote:
>> 
>> Hi,
>> 
>> Richard Frith-Macdonald wrote:
>>> It's a mistake/bug, or maybe they think people using mingw64 actually want 
>>> to cross-compile for mingw32 (seems perverse).
>>> Anyway, it can be overridden by using --host=mingw64 when configuring 
>>> gnustep-make, as a command line argument takes precedence over information 
>>> from config.site
>>> 
>> 
>> I actually found this informative info, which in case would also allow us to 
>> distinguis between the original mingw and mingw, if needed, the key is the 
>> w64 vs. pc
>> 
>> Citing:
>> 
>> This triplet specifies where the executables produced by this program (gcc) 
>> will run. Originally the
>> MinGW.org project chose `*-pc-mingw32`, so we selected `*-w64-mingw32` to 
>> avoid the conflict.
>> 
>> There is no special meaning about `w64` itself. `mingw32` on the other hand 
>> specifies the ABI, so
>> all `i686-*-mingw32` targets are considered ABI-compatible.
>> 
>> Neither does `w64` specify the target is 64-bit, nor does `mingw32` specify 
>> the target is 32-bit.
>> They are just hard-coded names.
> 
> Autoconf refers to the parts of the triplet as 
> CPU-TYPE-MANUFACTURER-OPERATING_SYSTEM
> config.guess returns x86_64-pc-mingw64
> 
> I don't really buy the argument that mingw32 and mingw64 are ABI compatible 
> ... maybe it's technically/theoretically true for some definition of ABI, but 
> it's praqctically false since in practice the two are tied to different 
> processor architectures.
> Certainly Autoconf (in the form opf config.guess) does not believe it.
> 
> Still, since the mingw64 people seem to have chosen to do it this way, and 
> presumably can't easily change, and the autoconf people probably don't want 
> to change a standard that they 'own', I guess we will need to find a way to 
> work around the fact that, depending on where you get the triplet from, it 
> might say the system is mingw64 or might say it's mingw32.
> We will need to find where gnustep-make looks for either, and put additional 
> checks in place for other parts of the triplet.

Given that we can get either x86_64-w64-mingw32 or x86_64-pc-mingw64 depending 
on whether the information comes from autoconf or from a config file supplied 
by the mingw-w64 project, it seemd to me that we need to standardise within our 
system.
Since we are currently expecting the 'os' part of the triplet to contain 
mingw64 on a mingw64 system, the simplest option was for the  
configure/configure.ac script to map the host vendor-os and target vendor-os 
from w64-mingw32 to pc-mingw64 and leave everything else unchanged.