[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 |
-----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-----
- Re: cl.exe and system types, (continued)
- Re: cl.exe and system types, Bob Friesenhahn, 2018/08/20
- Re: cl.exe and system types, Sébastien Hinderer, 2018/08/20
- Re: cl.exe and system types, Earnie, 2018/08/20
- Re: cl.exe and system types, Sébastien Hinderer, 2018/08/21
- Re: cl.exe and system types, Nick Bowler, 2018/08/21
- Re: cl.exe and system types, Earnie, 2018/08/21
- Re: cl.exe and system types, Sébastien Hinderer, 2018/08/23
- Re: cl.exe and system types, Earnie, 2018/08/23
- Re: cl.exe and system types, Keith Marshall, 2018/08/23
- Re: cl.exe and system types, Sébastien Hinderer, 2018/08/24
- Re: cl.exe and system types,
Keith Marshall <=
- Re: cl.exe and system types, Sébastien Hinderer, 2018/08/24
- Re: cl.exe and system types, Bob Friesenhahn, 2018/08/20
Re: cl.exe and system types, Peter Rosin, 2018/08/21