Re: cl.exe and system types

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
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 configure.ac or
>> a user written macro included by configure.ac, 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 configure.ac
  AC_INIT
  AC_CANONICAL_SYSTEM

  AS_CASE([$host_alias],[*mingw32cl],[CC=cl.exe])

  AC_PROG_CC

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

- -- 
Regards,
Keith.

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

iQIcBAEBAgAGBQJbf9TTAAoJEMCtNsY0flo/Bg4P/jbKi8Pg1jrIUWPcSMI+BxxP
3i3aQDsj7vRwtidEepYl4V2WVvOkTfXb+oHW02dQ//9PIzbND8TRqZbztD12cfRn
wVp7UA3uGRocCeVa54HoDzgb4wfi2fYgoHZP4MkmyeOfW2gXD2VmSOWYOiuHXDGk
TyR7PLC2yfxzaoJoK2OzeIWK0qjAWFeLrDJRL9XBwD+HHelW9ciZbA2qvLzyCpvo
GklwsVNqPZcKlGGNYCQ6890ck1s/ZcapS6QkljkBTQ80sNTOQoMzNdfxCrTKUgME
07X0QZkGikW07IBVE0QD51Rz9dYl59hbxvX/WU7Ct7IdsiGfh5pF/wJgX/2fNgET
hJNqZuWiZX6Z6rPJLR8T9nJ8221igOUUz59ARnHo6rHJS4CsCTjzzS5gmJt2SHit
9yKKQ4+tYS9V8ZhO+MOoCQfM0EjC6VjPVGfb/j46kYRCxK/qJTc770Vdwepketee
I+dC/y27ZzpIqoMaSiJQTsPwURTs+bgNCI1bsKEeITfbIAABsWA2hv9ywKvsMi6i
lAUel8fuDrHHMfwKU5XYWzvDyMnaTuO8xPbsncI+97Sgnc8Zzr1+dCSS2Ukc/iqn
TADQK/QnPy0guxy4JGdFP3yh9xEfkoJbOQ4vv0FhSExwestV9iQAFML4xO39ZEjJ
ng6AoynCDuQio8t8e8j3
=ObUU
-----END PGP SIGNATURE-----