gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Frith-Macdonald
Subject: Re: Windows ming64- loading resources in a Framework fails - bundleForClass
Date: Thu, 25 Feb 2021 11:49:43 +0000


> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]