Mail Archives: cygwin/2009/01/28/04:05:32
-----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/
- Raw text -