Re: Support for MinGW compilers in the Cygwin environment

[Daniel Richard G.]

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.

> 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...

> > (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.

> > 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.

> 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.

> > 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.

> 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.

> > 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.

> > 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?

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.

> > 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.

> > 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.

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.

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.

> > MinGW-Clang uses a different triplet from MinGW-GCC?
>
> Potentially, since Clang is not beholden to GNU standards.

Their modus operandi has generally been to mimic GCC's interface and
behavior, for the sake of compatibility. Where they deviate from
that is largely in adding features or capabilities that GCC doesn't
have. I wouldn't expect them to break established convention without
a good reason.

> Not to mention some users do CC=cl.

Interesting, I wasn't aware that was supported without a wrapper script.
But as long as the Microsoft compilers don't #define __MINGW{32,64}__,
the guessed triplet won't change.

(If you do set CC=cl, do the Autotools handle that as a cross-compile?)


--Daniel


-- 
Daniel Richard G. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.