MSYS mode (continue)
LRN
lrn1986@gmail.com
Tue Jul 30 01:18:00 GMT 2013
-----BEGIN PGP SIGNED MESSAGE-----
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
msys-python).
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! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJR9xRSAAoJEOs4Jb6SI2CwZgUH/0O53vyz6+QfwWFYBWCtsXl9
yIwVEoEQY7GmwFFPRXLiZkh8EQx2/xKdZrpwFGVHPb/hFyYuBPjDkzDlWV6KrFBh
o3YKPlZjPw1gyD+p03ekFkxpgPgZpucaR0k54UyqnnXAtZwA8NhToMokxPJVKez3
e4gpM+dmmpWWsZLQl7I1ZwOTnG88B7aySt8nphGpfUCtfWGzaKU+6JN48HzQapHU
7Wj30Ashmt1eI9LJK5kz+RnBEzdrYlsJITDa+BdHBSFhgqZsMc/DothBmcxi4hl4
ZPFWi6ErAggdkIHrYku1/YUjDjZ19KXHkerY+0y9QwQAJUVZ0iSaau82C3EIZcY=
=p74t
-----END PGP SIGNATURE-----
More information about the Cygwin-developers
mailing list