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

> On 23 Feb 2021, at 23:08, Johannes Brakensiek <[email protected]> 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