Re: Support for MinGW compilers in the Cygwin environment

[JonY]

On 10/24/2013 13:58, Daniel Richard G. wrote:
> On Wed, 2013 Oct 23 18:05+0800, JonY wrote:
>>>
>>> I never suggested replacing Cygwin-GCC with MinGW-GCC
>>
>> You just did, CC=i686-pc-mingw32-gcc, they are NOT drop-in
>> replacements.
> 
> I'm aware that the two compilers produce different kinds of outputs (a
> Cygwin binary versus a native Win32 binary), and both have their place.
> I just want native Win32 binaries.
> 

Which is why you cross compile, if you don't want executables native to
its environment, in this case Cygwin.

>> 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.
> 
> I'd like for Autotools to get the MinGW triplet automatically, but some
> people on this list don't seem to like the idea...
> 

Then use MSYS, MSYS is designed specifically for that, or wait for that
MSYS mode Cygwin plugin thing, but it won't be done any time soon.
Cygwin is not MSYS, MSYS is not Cygwin.

>>> (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.
> 
> Technically, those are binutils programs. GCC may be the main consumer
> of them, but it's certainly not the only one.
> 

So don't touch them, they are not for you. Cross binutils specifically
did not modify /etc/profile to add it to your path.

>>> 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.
> 
> MSYS is not involved at all here, only Cygwin and the MinGW compiler.
> 

Which is why this is a cross compile situation, use --host.

>> 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?
> 
> Oh, you're referring to func_convert_core_msys_to_w32(). I've run into
> that same hang, which seems to result from CMD.exe not knowing what to
> do with "//c" as opposed to "/c".
> 
> I'll gladly submit a patch that allows the Libtool script to detect the
> MSYS shell at invocation time using ${BASH_VERSINFO[5]}, if that's the
> main objection.
> 

That was already tried, like this patch, it was messy and of little
value. Why not just use --host? You are building on Cygwin and want to
run your code without it, aka via mingw.

>>> 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.
> 
> Well, first, keep in mind that the CC/CXX world is bigger than the
> Autotools world (even though the Autotools world isn't anything to
> sneeze at either). Secondly, even a user who knows about --host isn't
> necessarily going to think that cross-compilation machinery is needed to
> build MinGW/Win32 binaries in a Cygwin/Win32 environment. Not only is
> that not obvious, it's counterintuitive.
> 

No, setting CC is counter-intuitive, you already know the triplet
prefix, just set --host and be done with it. Cygwin and mingw are
separate things, they just happen to run on Windows. Is DLLTOOL, AR,
RANLIB, RC also standard?

There is also Interix/SUA and DJGPP, possibly other funny alternatives
too, so why does Cygwin/MinGW pair get special treatment?

>> 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?
> 
> No, just someone who is less well-versed in the specifics of
> GNU/Autotools than you.
> 

So why do we need to compensate for pebkac? If this user can read --help:

> System types:
>   --build=BUILD     configure for building on BUILD [guessed]
>   --host=HOST       cross-compile to build programs to run on HOST [BUILD]

Now was that so hard?

>>> 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????".
> 
> If CC is set, it's because the user set it explicitly. (It would be nice
> if Autoconf reported that CC was set and what the value is, as it
> sort-of did in the old days, but that's another story.) This would be a
> problem if, say, Cygwin shipped an /etc/profile that set CC---but no one
> does that, for exactly that reason.
> 

Yes, it would be another gotcha to work with, good job, you added
another vector to mess 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.
> 
> Could you give some examples of that? Or links to examples?
> 

There are source packages out there that require using both native GCC
and cross GCC when cross compiling. So what now? Do you also make a
special $BUILD_CC $BUILD_AR $BUILD_LD and so on? Another more
complicated version of --build?

> It may be obvious to you why my patch is the technical equivalent of a
> North Korean invasion, because you've presumably had your nose in
> Autotools development for a long time and you're intimately familiar
> with what would break. For my part, I've worked with Autotools for a
> number of years, written numerous scripts for them, and have a general
> idea of what goes on in there. And it's not at all obvious to me what
> the complications of this approach are.
> 

Good, so stop this invasion, you are turning it into Operation Downfall v2.

>>> 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.
> 
> The raison d'etre of Autotools is to relieve users of the burden of
> selecting every little compile-time option needed to build a
> software package:
> 
>     http://web.mit.edu/gnu/doc/html/autoconf_14.html#SEC103
> 
> Cross-compliation is certainly a useful feature, and the Autotools make
> it a lot easier than it would be otherwise. But it's not why Autotools
> came into being, and when you compare how many builds are cross-compiled
> versus how many aren't, it's not why most people use Autotools either.
> 

Cross compile IS a compile time option, you CHOSE to cross compile,
didn't you? Autotools made cross compile straightforward, by not
requiring environment variables to be strewn about, but by just setting
--host. The other buildsystems that claim to be superior to autotools
fall flat here.

>>> 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.
> 
> Replace "Cygwin" with i386-pc-solaris2.10, and "MinGW" with x86_64-pc-
> solaris2.10. I understand that that's not a cross-compilation
> scenario; I just do
> 
>     $ CC="cc -xarch=generic64" ./configure
> 
> and go to town. Compiled on i386 and targeted x86_64.
> 
> You've been telling me that my patch is a horrible idea, that Cygwin
> is not MinGW, that --host --host --host --host --host... but in all
> that verbiage, the only thing you've said that even comes close to
> being an explanation is the Libtool "cmd //c" hang issue. And that
> could be reworked.
> 

Already attempted, it was a mess, patch was rejected upstream with good
cause.

This is the crux of the argument. It is a nasty hack when CC variable
can cause the triplet to misidentify the build triplet. Why do you need
another way of saying --host?

> Before putting together my patch, I tried to find information about this
> issue on $WWW_SEARCH_ENGINE, and didn't find much. If you've been
> involved in the long-term development of config.{guess,sub} and the
> Autotools, if you've seen firsthand why handling a MinGW-on-Cygwin build
> as a cross-compile is the only technically sound solution, then you
> would be in a good position to elucidate why things are the way they are
> now. But if you don't know the development history of these tools, and
> can only tell me the proper way of using them as they currently exist,
> then we're not going to get anywhere. Because then you won't know what
> it is I want to know.
> 

Go find Cygming project from the early GCC 2.8/2.95 era. Patch is in
your name, so you justify reversing a decade of precedence.

> I'm not saying my patch should necessarily be accepted, but if it isn't,
> then I would like to understand the technical reasoning. If all this has
> been rehashed before, links would be great. If not, then I'm all ears.
> 

The real reason it is rejected is that you are trying to do a special
case --host if Cygwin is around, when setting --host as usual can do it.

If anything, patch is firmly rejected, status quo maintained.

signature.asc
Description: OpenPGP digital signature