Message-ID: <49800695.8070503@cwilson.fastmail.fm>
Date: Wed, 28 Jan 2009 02:17:41 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: RFD: cygwin + *native* MinGW compiler
References: <497FC147 DOT 306 AT cwilson DOT fastmail DOT fm> <497FE127 DOT 1010705 AT sbcglobal DOT net> <497FED17 DOT 4040901 AT cwilson DOT fastmail DOT fm> <497FF7D0 DOT 3090505 AT users DOT sourceforge DOT net>
In-Reply-To: <497FF7D0.3090505@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Yaakov (Cygwin/X) wrote:
> Charles Wilson wrote:
>> This led to a suggestion that "--build=cygwin --host=mingw32" should
>> always be interpreted as: mingw32-gcc is a cygwin-hosted cross compiler,
>> NOT the native MinGW-project supported gcc (and if it IS the native
>> MinGW one, expect breakage). I'm not sure such a sweeping statement is
>> accurate, or wise -- will that assumption break people's exising
>> (working) setups?
> 
> If you're talking about configure gcc with those flags,

No, I'm talking about configuring/compiling *other* stuff, using some
gcc that is found via the normal rules (prefixing a triple to 'gcc' when
specified by build/host/target options, looking in PATH, etc).

> then wouldn't
> that usually mean that you're cross-compiling a regular, native MinGW
> compiler?  If you want a cygwin-hosted MinGW cross-compiler, you should
> be using "--build=cygwin --host=cygwin --target=mingw32". 

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?

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

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

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.

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.

> I would be
> hesitant to change the usual meaning of build/host just for
> Cygwin/MinGW; I don't think we need to add to the confusion that most
> people have about Cygwin.

I don't think anyone is proposing that; I think the original suggestion
actually enforces a more "normal" (e.g. like *nix/bsd/sol/etc)
interpretation on the build/host/target triples. No more pretending that
build=mingw32 when it's really cygwin; etc.

--
Chuck

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