MSYS mode (continue)

Tue Jul 30 01:18:00 GMT 2013

Hash: SHA1

On 29.07.2013 20:37, Charles Wilson wrote:
> 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.
> 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).

That might work. It also means that you'll need a new cygwin
cross-compiler (a mingw->cygwin cross-compiler, although in reality it
might be cygwin->cygwin native compiler that looks like a
cross-compiler). Unless existing one can be stuffed into
/usr/i686-pc-cygwin without any ill effects.

> 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.
Yes, LRN is assuming that /usr/bin/gcc is a cygwin-gcc, and
/mingw/bin/gcc is a mingw gcc.
$MSYSTEM/$PATH games worked well enough so far.

> 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.
Yes, that is a good point.

> 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.
Yes, but with cygwin that is going to go away, as i686-pc-cygwin IS a
valid triplet. More reasons to not to let mingw apps see these autotools
and m4 files.

> The /mingw version of the autotools was not hacked in this way.
Though it might be hacked in other, unspecified ways (for example, i
mess with stuff a lot to integrate W32 CPython; this is not needed for

You've laid out advantages and "advantages" of the former system.
What are the advantages of the latter system?

- -- 
O< ascii ribbon - stop html email! -
Version: GnuPG v1.4.11 (MingW32)


More information about the Cygwin-developers mailing list