This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MSYS mode (continue)


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]