[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: config.guess: On Windows, support MSVC (cl.exe), probably wrapped.
From: |
Earnie |
Subject: |
Re: config.guess: On Windows, support MSVC (cl.exe), probably wrapped. |
Date: |
Thu, 20 Apr 2017 10:08:41 -0400 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 4/20/2017 4:00 AM, Michael Haubenwallner wrote:
>
> On 04/19/2017 11:57 PM, Ben Elliston wrote:
>> On Wed, Apr 19, 2017 at 07:40:30PM +0200, Michael Haubenwallner wrote:
>>
>>> Subject: [PATCH] * config.guess: Support MSVC compiler on Windows.
>>
>> Why aren't you just running uname? There's no need to run a compiler
>> to determine the machine architecture.
>
> This is kind of "multilib", where one machine can run binaries of multiple
> architectures, like 32bit and 64bit, while uname tells about the underlying
> POSIX-like system only (which provides the SHELL).
>
> For example, I'm using x86_64 Cygwin to run cl.exe creating 32bit binaries,
> which can be executed, so it's not a "cross"-compile. Now the host triplet
> should be i686-pc-winnt, but uname can tell x86_64 (cygwin) only.
>
The config.* scripts weren't meant to do this. Executing a compiler
isn't the correct thing to do. Use the --host and --build options of
configure to overcome the issue. You might have luck with MSYS by
setting the MSYSTEM environment variable to a value of WINNT. But that
won't help with the "multilib" issue either; the only option for that is
--host and --build options. And you would need to set the CC variable
of course outside of configure.
Another option that I've employed in the past is to create a cc script
that DTRT regardless of uname. The cc script just executes the compiler
of choice and interpolates the compiler options.
--
Earnie