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