Re: RFC: x86_64-pc-mingw64 and getting it mapped out

On 28/07/13 17:34, Earnie Boyd wrote:
> I do not know what you mean by "Kai did something similar".

Similar, but not identical: IIRC, he designated x86_64-pc-mingw32 as a
64-bit compiler, producing code to run in 64-bit, on x86_64 CPUs.
> 
>> What we have today is clean, simple and effective.  If you want to
>> ignore the KISS principle, and so make it complicated and ultimately
>> unworkable, then perhaps it is time for me to bid you adieu.
> 
> I do not know what you mean by "What we have today is clean, simple
> and effective."

Current build systems can inspect $host_os alone, to determine that the
build is to be 32-bit code, even if that is running under a 32-bit OS
hosted on an x86_64 CPU platform.  That's exactly the scenario my day
job company runs today; they buy 64-bit machines, but install 32-bit
Windows -- don't ask me why.

> I am not seeing "unworkable" nor am I seeing that I'm ignoring the
> KISS principle.

So, how many of said (existing) build systems are you going to break,
in your bid for regressive "progress".

> In fact I'm trying to work a KISS principle for providing libraries
> with varying bitness and architecture to be used by a cross compiler.
> Keeping the mingw32/mingw64 in the triplet is just a misnomer and can
> be misleading.

I disagree.  Strongly.  Indulge me for a moment, and explain how you
would have discriminated between a hypothetical mingw16 and mingw32.
Just as 16-bit and 32-bit Windows were equally at home on i386..i686,
32-bit and 64-bit Windows are equally at home on x86_64.  CPU bitness
alone is not sufficient to identify OS bitness.

> What we have today is /mingw/mingw32 for the hosted libraries.  Are
> you stating that you want to keep that over /mingw/i686-pc-mingw?
> Here's the harm in it, the i686 could be i486 or i586 but the
> libraries i'm building are hosted for i686.  Now someone thinking they
> can build software for i586 with the libraries in /mingw/mingw32 will
> be out of luck.

This is a different issue; that your libraries require instructions
which are specific to a particular generation of one processor family is
distinct from the issue of which OS variant you support.

If you really want the hassle of maintaining multiple versions of the
libraries, optimized for different CPU generations within the *same*
processor family, then yes, you need the fuller qualification within the
triplet, but that still remains distinct from OS bitness.

> And I can imagine that there could be a 64bit Windows OS on some other
> chip set than x86_64.  So I want ot have /mingw/x86_64-pc-mingw for
> that instead of /mingw/mingw64 for the same harm reason for mingw32.
> 
> Can you debunk what I'm saying about the architecture variance being
> harmful in using /mingw/mingw32 and /mingw/mingw64?  If so then I'll
> be fine with leaving it.  However, I will suggest changing the default
> guess from i386 to i686 since that is where most of the world is.

But the least common denominator remains i386; you need to demonstrate a
very strong justification for eschewing the portability which choice of
LCD grants.


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk