Re: Support for MinGW compilers in the Cygwin environment

[JonY]

On 10/23/2013 13:53, Daniel Richard G. wrote:
> On Tue, 2013 Oct 22 17:38+0800, JonY wrote:
>>
>> This has nothing to do with MSYS vs Cygwin, your whole patch is messed
>> up, it needs to be shot down and burned like the bad idea it is.
>> Cygwin ships a CROSS COMPILER, mingw gcc is not a replacement for cygwin-
>> gcc like your use case suggests.
> 
> I never suggested replacing Cygwin-GCC with MinGW-GCC; if I want a
> Cygwin binary, I'll use Cygwin-GCC. I'm not interested in producing
> binaries that depend on the Cygwin DLL, however, so that's off the
> table for me.
> 

You just did, CC=i686-pc-mingw32-gcc, they are NOT drop-in replacements.

>>> The main goal of my patch was to eliminate the need to specify
>>> triplet(s) explicitly when using the MinGW compilers on Cygwin.
>>
>> Why would you even do that? Cygwin and MinGW ARE NOT INTERCHANGEABLE,
>> they just happen to run on Windows.
> 
> I'm not interchanging one for the other. I just don't want to use
> Cygwin-GCC. (I do want to use the Cygwin *environment*, however, because
> that lets me do nice things like run an sshd on Windows.)
> 

You just lied to autotools by setting CC=i686-pc-mingw32-gcc and
tricking it to set --build=i686-pc-cygwin while the build machine is
actually Cygwin.

>>> In the same way that, on a Solaris machine I work with here, I
>>> can get
>>>
>>>     $ ./config.guess
>>>     i386-pc-solaris2.10
>>>     $ CC="cc -xarch=generic64" ./config.guess
>>>     x86_64-pc-solaris2.10
>>
>> --host does that already, why would you even want to set
>> CC/CXX/LD/AR/RANLIB/DLLTOOL manually when --host does exactly that?
>> Not to mention this will break libtool in horrible ways.
> 
> (It's easier to add e.g. /usr/i686-pc-mingw32/bin to the PATH than to
> set all those variables.)
> 

No you don't, those are used by GCC internally and should never be
exposed to the user.

> My point isn't that --host doesn't work, nor that it should go away, but
> that it shouldn't be a requirement here---any more than it is when
> someone builds 64-bit binaries on a system that identifies as 32-bit.
> 

It is a requirement, the point is that the build system IS NOT MSYS, IT
IS CYGWIN. What Cygwin runs on does not matter.

> Could you be more specific on the "this" that would break Libtool? As
> far as I'm aware, Libtool is perfectly capable of generating MinGW
> libraries.
> 

Libtool calls cmd to translate paths if the build triplet is mingw,
cygpath is Cygwin. Under Cygwin, the cmd calls are just going to hang
due to the difference between MSYS and Cygwin handling of paths. I just
had to deal with this silliness for accidentally setting --build=mingw32
and you want to make it a default behavior?

>>> it would be reasonable for config.guess (or possibly some other part
>>> of the toolchain?) to notice when we are using e.g. CC=i686-pc-mingw32-
>>> gcc and return a triplet reflecting that, rather than put the onus
>>> on the user to identify what can already be inferred from the
>>> environment.
>>
>> Did the user remember to set CXX? Did he remember to set AR too? Are
>> you implying the user is too stupid to know what he is compiling for?
> 
> CXX and AR are standard build-environment variables (and the latter need
> not be set if Autoconf can find ar.exe in the MinGW tool dir). I'm not
> thinking of a stupid user here, but a user of any experience who wonders
> why Autotools makes this process more complicated than it is.
> 

Of course you did, you just explained that setting --host is too hard
for the user while he sets CC/CXX instead. I wonder how is it
experienced users not know anything about --host but set environment
variables manually.

Who is this user you speak of? Why does he not know about --host but
knows about CC, CXX et all? Why can't he read configure --help for
explanations? Is this user an illiterate cargo cultist?

>> Great. now there is a hidden variable called CC that I need to check
>> when supporting users, so much clearer than the highly visible --host
>> argument.
> 
> You consider CC to be a hidden variable?
> 

Yes, it is not clear from the configure argument what the value of CC
is. So users will come to you and ask "Why isn't my programs linking
with Cygwin????".

>> Now that you've done the i686-pc-mingw32 case, did you forget the
>> i686-w64-mingw32-gcc case too? After all, it would be nice if it did
>> the same too. Are you going to write another include-compile tests to
>> see which variant of mingw you are building for? What are you going to
>> do if other mingw implementations pop up?
> 
> If the triplet is something novel that config.guess doesn't know about,
> *that* would be a good argument to use --host/--build.
> 

It is, your patch turned a simple affair into a messy minefield.

>> You are not making a convincing argument, you haven't given any
>> insight on why setting CC is better than --host other than
>> highlighting the plight of fictional users.
> 
> CC is standard; --host, less so. And it's questionable why --host should
> be needed at all when we're compiling binaries that will run on the same
> system that built them.
> 

This line of reasoning is plain nonsense, the cross compile concept is
the very reason autotools exists.

>> Like Jan says, this is a horrible hack, adds confusion. Any changes
>> are purely cosmetic and of questionable value.
> 
> Not requiring users to go through the motions of a cross-compile to
> build Win32 binaries on Win32 *adds* confusion?
> 

But it IS CROSS COMPILATION, you just used a cross compiler! The results
just happen to run on the build machine. You compiled on Cygwin and
targeted mingw, is that too hard to understand? I suggest you stop your
revisionism.

>>> Non-GCC compilers which define __MINGW{32,64}__? Are you referring
>>> to Clang?
>>
>> Yes.
> 
> MinGW-Clang uses a different triplet from MinGW-GCC?

Potentially, since Clang is not beholden to GNU standards. Not to
mention some users do CC=cl.

signature.asc
Description: OpenPGP digital signature