[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cl.exe and system types
From: |
Sébastien Hinderer |
Subject: |
Re: cl.exe and system types |
Date: |
Fri, 24 Aug 2018 10:23:16 +0200 |
Dear Earnie and Keith,
Many thanks for your support, warmly appreciated.
Earnie (2018/08/23 13:08 -0400):
> It's going to depend on what you want. If you're using the crosstools
> for MinGW-w64 then you would specify --host as {i686,x86_64}-w64-mingw32
> and --build as {i686,x86_64}-pc-cygwin. If you're using MSVC, there is
> no crosstool chain of software so you specify a fictitious --host and
> --build to be the same such as {i686,x86_64}-pc-msvc and point the
> environment variables to the binaries. IIRC, The 64bit version of
> Cygwin has a cross build for the 32bit version[1] so the --host would be
> i686-pc-cygwin and config.guess can figure out the --build or you can
> specify it as x86_64-pc-cygwin.
>
> [1]
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=i686-pc-cygwin&arch=x86_64
>
Keith Marshall (2018/08/23 20:00 +0100):
> But the OP seems to want to use AC_CANONICAL_*. IIRC, these demand that
> the --build and --host, (and --target, if applicable), must be known to
> config.sub; that kind of precludes just inventing an arbitrary name.
yeah that's what I observe here indeed, I could'nt use "msvc" in the
argument of --host, for instance.
> 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? Isn't that a bit confising?
> 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! :)
> [*] 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.
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.
For the 64 bits architecture, it seems the followingworks:
./configure --build=x86_64-unknown-cygwin --host=x86_64-pc-windows CC=cl
Do you guys think I can proceed with these values for build and host?
Thanks!
Sébastien.
- Re: cl.exe and system types, (continued)
- Re: cl.exe and system types, Sébastien Hinderer, 2018/08/20
- 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 <=
- Re: cl.exe and system types, Keith Marshall, 2018/08/24
- 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