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

[Richard Frith-Macdonald]

> On 25 Feb 2021, at 11:49, Richard Frith-Macdonald 
> <richard@frithmacdonald.me.uk> wrote:
> 
> 
> 
>> On 25 Feb 2021, at 11:05, Riccardo Mottola <riccardo.mottola@libero.it> 
>> 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.