This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: MSYS mode (continue)
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 29 Jul 2013 12:37:43 -0400
- Subject: Re: MSYS mode (continue)
- References: <20130725150209 dot GA15619 at calimero dot vinschen dot de> <51F16C82 dot 7030509 at cwilson dot fastmail dot fm> <20130725205320 dot GA2725 at ednor dot casa dot cgf dot cx> <20130726081510 dot GN5086 at calimero dot vinschen dot de> <51F3394A dot 6050309 at cwilson dot fastmail dot fm> <CAF1jjLv_znaB_EH4LDo_xTq3d+-QuZR3R5jWQYpKiZJdDPKWFA at mail dot gmail dot com> <20130729092958 dot GB3731 at calimero dot vinschen dot de> <51F64B38 dot 8000500 at gmail dot com> <20130729111856 dot GD30069 at calimero dot vinschen dot de> <51F68BED dot 5010506 at gmail dot com> <20130729154725 dot GD4166 at calimero dot vinschen dot de>
On 7/29/2013 11:47 AM, Corinna Vinschen wrote:
That's what I understood differently. From the discussion on mingw-w64
it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
I agree with Corinna here. I think LRN is assuming that the
installation structure will remain the same as MinGW/MSYS going forward,
and I do not believe that is correct -- at least, that's not what
Corinna is proposing IIUC.
Here's how MinGW/MSYS works right now:
*normally* the batch file you use to enter the "MinGW" environment,
launches bash with
1) MSYSTEM=MINGW32
2) /mingw/bin at the "front" of $PATH (wherever your mount
table happens to say that is)
Your phyiscal directory structure *normally* looks something like this:
C:\MinGW <<<<< mounted as /mingw
bin MinGW (that is, "native" win32) gcc.exe & friends
include "native" win32 headers
lib and libraries
msys
1.0 <<<<< mounted as /
bin gcc.exe -- only this time, it's an
msys-target compiler. But note that it is
actually configured as a "native" compiler
include msys headers and
lib libraries
Because of #1 and #2 above, uname reports MINGW32, and the first gcc
found in your path is the "native" win32 MinGW one.
However, an *msys* developer would launch a script that invokes bash with
1) MSYSTEM=MSYS
2) /bin at the "front" of $PATH
In this case, uname reports MSYS, and the first gcc found in your path
is the msys one.
=====-----=====
In the new scenario, we might have a separable installation -- maybe
c:\msys\2.0\
but there isn't any gcc.exe installed there. And then you might install
MinGW gcc somewhere like
c:\MinGW-4.8.1\
and just arrange that
c:\msys\2.0\etc\fstab
has
c:\MinGW-4.8.1\ /mingw
and again, you make sure that /mingw/bin is in your $PATH.
However, in the new scenario, you MIGHT have, in
c:\msys\2.0\i686-pc-cygwin\, a cross compiler targetting "cygwin/msys"
and running on...MinGW (even though "MinGW" environment is, for all
intents and purposes, a slightly modified cygwin -- but uname reports
MINGW32 just like it does for "native" MinGW/win32 operation). To build
msys apps in this environment, you have to use --host=i686-pc-cygwin
(and remember, because uname is reporting "MINGW32", any build system
will operate under the assumption that you are, in fact, cross compiling).
There are some advantages to the former system, not least of which is
that when MSYSTEM=MSYS, you're compiling natively so you can easily run
any test suites without having to play games with the build system.
I think LRN is assuming that the gcc installed in /bin would be the
cygwin gcc (configured as a native compiler), and we'd continue to play
$MSYSTEM/$PATH games.
One additional "advantage" to the former system is the autotools. Right
now we can have a "clean" separation between aclocal/.m4 files that have
data corresponding to MinGW-compiled native libs and tools, and
aclocal/.m4 files that have data corresponding to the msys ones --
because we have two entirely distinct "sets" of autotools.
/mingw/* has the whole panoply of autoconf2.1/2.5/wrapper,
automake1.4--1.12/wrapper, libtool, gettext, and libintl. All are
configured with --prefix=/mingw, so they look in /mingw/share/aclocal*/
for .m4 stuff.
OTOH, in /{bin,lib,share} we have one specific version of autoconf (2.59
IIRC), one specific version of automake (1.11?), libtool specially
hacked to support msys (because "regular" libtool does not), gettext,
and libintl. Because msys has never been, and was not intended to be, a
public "triple" value, these versions' config.guess/config.sub were
modified to recognize the MSYS uname, and report i686-pc-msys as a
triple, and to actually handle that triple correctly.
The /mingw version of the autotools was not hacked in this way.
This way, when porting some package in /mingw land and running
re-autoconf, users don't get "fooled" by picking up stuff in
/share/aclocal/* -- they only "see" the .m4 files that correspond to
OTHER fully-ported-to-mingw libs and tools.
--
Chuck