config-patches
[Top][All Lists]
Advanced

[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



reply via email to

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