[Top][All Lists]

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

Re: cl.exe and system types

From: Keith Marshall
Subject: Re: cl.exe and system types
Date: Fri, 24 Aug 2018 10:50:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

Hash: SHA1

On 24/08/18 09:23, Sébastien Hinderer wrote:
> Keith Marshall (2018/08/23 20:00 +0100):
>> For --build, the output from config.guess should always be 
>> suitable; for --host, it may be okay to affix an arbitrary
>> suffix to mingw32, such as (untested [*]) --host=mingw32cl
>> CC=cl.exe, (and any other explicit tool identification
>> assignments which may be required).
> But why would you include a "mingw" string in something that does
> not use mingw at all?

Because it's an OS name already known to config.sub, and because it's
an OS designator which is specific to native MS-Windows software
builds, (but see below).  Also, "MinGW" is a contraction of
"Minimalist GNU for Windows", and you are using at least one GNU tool
(autoconf) in your build process.

> Isn't that a bit confising?

Perhaps not to anyone who understands the "MinGW" concept, but again,
see below.

>> You could possibly also use AS_IF, or AS_CASE, in or
>> a user written macro included by, to test
>> $host_alias for your specific modified host identifier, and make
>> a conditional assignment of CC=cl.exe and so on, within the
>> generated configure script itself.
> Ah I quite like this idea, thanks! Let's see whether it's doable!
> :)

It is:

  $ cat



  $ autoconf
  $ ./configure --build=`./config.guess` --host=i386-pc-mingw32cl
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... i386-pc-mingw32cl
  checking target system type... i386-pc-mingw32cl
  checking for i386-pc-mingw32cl-gcc... cl.exe
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.out
  checking for suffix of executables...
  checking whether we are cross compiling... yes
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  checking whether cl.exe accepts -g... yes
  checking for cl.exe option to accept ISO C89... none needed

Note that I've run this on GNU/Linux, so cl.exe doesn't really exist;
I've kludged it as a hard link to gcc.

>> [*] Note that I've explicitly avoided "mingw32msvc" as a host 
>> identifier in this example, because some GNU/Linux distributors 
>> have adopted that, (inappropriately, IMO), to designate their 
>> mingw32 cross-compiler tool chains.
> The choice looks unfortunate to me, too.

It's a really terrible idea.  I believe that their idea is to indicate
that the generated code depends on MSVCRT.DLL, (which is distributed
with Windows itself -- not with MSVC); this would be credible, if they
called it "mingw32msvcrt", but they don't!  "mingw32msvc" implies a
dependency on MSVC -- the Microsoft Visual-C compiler -- which is 100%
bullshit; there is no such dependency.

> Okay so as far as msvc is concerned, on 32bits I am able to run 
> configure with:
> ./configure --build=i686-pc-cygwin --host=i686-pc-windows CC=cl
> (what matters here is --build and --host), the assignment to CC
> could indeed go away if it becomes host-based.

Okay.  I wasn't aware that config.sub already understands "windows",
(and indeed, it even understands an arbitrary suffix appended to
"windows", provided there's no hyphen within it).  If you are happy to
interpret "--host=windows", (or any canonical triplet which ends with
"-windows"), to implicitly require cl.exe, then you could adapt:

  AS_CASE([$host_alias],[*windows | *mingw*cl],[CC=cl.exe])

or otherwise, you could qualify it:

  AS_CASE([$host_alias],[*windowsmsvc | *mingw*cl],[CC=cl.exe])

> For the 64 bits architecture, it seems the followingworks:
> ./configure --build=x86_64-unknown-cygwin --host=x86_64-pc-windows
> CC=cl

This should also work, with any of the preceding adaptations.

> Do you guys think I can proceed with these values for build and
> host?

I don't see why not; you've nothing to lose by trying.

- -- 

Public key available from
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
Version: GnuPG v2.0.20 (GNU/Linux)


reply via email to

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