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

> On 25 Feb 2021, at 11:49, Richard Frith-Macdonald <[email protected]> wrote:
> 
> 
> 
>> On 25 Feb 2021, at 11:05, Riccardo Mottola <[email protected]> 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.