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) <https://github.com/msys2/MINGW-packages/issues/8020>

> 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