Re: RFD: cygwin + *native* MinGW compiler

["Yaakov (Cygwin/X)" <yselkowitz@users.sourceforge.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
> Right, if I'm building a compiler.  I'm not -- although that wasn't very
> clear, since the only examply I gave was Danny's incantation for
> building gcc, a compiler.  Oops.
> 
> I'm talking about building, say, ncurses so that it will run "natively"
> (that is, in the mingw environment without cygwin).  The question is,
> what assumptions should be made about the compiler that is used to
> compile ncurses, when you configure ncurses using --build= --target=?
> Does that compiler  understand /cygdrive/c/foo, or C:\foo?

That's a totally different story.  I think that would be obvious;
- --build=cygwin --target=mingw32 should mean you're using a Cygwin-based
MinGW cross-compiler.  AFAIK that's consistent with other platform
combinations.

> Only compilers and linkers have --targets.  Everything else, you
> (cross)compile using build/host (or just host; build is implicit). So,
> the implication of the suggestion above is that:
> 
> ../ncurses/configure --build=cygwin --host=mingw32
> 
> would mean that the gcc involved runs on the cygwin build platform, and
> understands /cygdrive/c/foo, but the ncurses library and tools will be
> native mingw32 and will only understand C:\foo. That is, it is a
> cygwin->mingw cross compiler. (Bringing this down to earth:
> specifically, when libtool is creating a wrapper executable -- say, for
> tic.exe -- using the cross-compiler, the wrapper exe will be a native
> win32 prog, and will need the DOS path to the exe it needs to "wrap".
> Not the cygwin path -- and libtool should use cygpath to obtain that DOS
> path).

Right.

> OTOH,
> 
> ../ncurses/configure --build=mingw32 --host=mingw32
> 
> would mean that the compiler TOO only understands C:\foo. That is, it is
> a native MinGW compiler as distributed by the MinGW team.  (Back to
> earth: specifically, when libtool is creating a wrapper executable using
> this "native" compiler, the wrapper exe will be a native win32 prog, and
> will need the DOS path to the exe it needs to "wrap". However, because
> of the oddities of "MinGW" $build -- it's actually msys, and has its own
> idea of a unix-like path -- libtool will need to convert that unix-like
> path to DOS format using the msys mechanism to do so. NOT cygpath).

So far so good.

> These are both logical scenarios, and represent the "normal" way of
> interpreting build/host for an cross-compile or native setup [other than
> the utter weirdness that is msys].  However...and here's the rub...until
> now the various win32 "hosted" platforms have been rather lax about
> these distinctions.  So, for instance, Danny can currently get away with
> the following:
> 
> cygwin-machine$ ../gcc/configure --build=mingw32 --host=ming32
> --target=mingw32
> 
> even though $build is NOT, actually, mingw32 (or even msys). It's
> cygwin. Enforcing the "normal" interpretation will break that usage
> (Back to earth: because the "wrong" mechanism (msys->mingw, instead of
> the true cygwin->mingw) to convert unix-like paths to the DOS path
> needed by the wrapper exe will be used. Don't lie to your tools about
> their $build environment...)
>
> Maybe this usage *should* be broken (or strongly discouraged, with an
> esoteric workaround for those who insist on mistreating their tools). I
> dunno.

Of course it's broken, period.  And just like all the other
misconceptions around Cygwin, I don't see why it we shouldn't be allowed
to fix it.

> Seems kinda harsh, to break something that currently works (even if it
> is evil) -- and the point of this thread, really, is to see how many
> people use cygwin + mingw in situations where they may be tempted to --
> or already do -- lie to their configure scripts about $build.

WJM. :-)  But as we're (finally!) abandoning the long-broken
- -mno-cygwin, I don't see why we can't dump this breakage as well.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkmAH8sACgkQpiWmPGlmQSPTwQCghn3w7Sr2ojNXQTdiizeIr9Qu
f8cAoPKk8R710du8gOFvFYDJuMAkGEUY
=7g0F
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/