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

[Richard Frith-Macdonald]

> On 23 Feb 2021, at 23:08, Johannes Brakensiek <johannes@brakensiek.info> 
> 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