MSYS mode (continue)

Corinna Vinschen
Mon Jul 29 15:47:00 GMT 2013

On Jul 29 19:36, LRN wrote:
> Hash: SHA1
> On 29.07.2013 15:18, Corinna Vinschen wrote:
> > On Jul 29 15:00, LRN wrote:
> >> On 29.07.2013 13:29, Corinna Vinschen wrote:
> >>> On Jul 27 20:17, NightStrike wrote:
> >>>> Perhaps it would be useful to actually identify which packages have
> >>>> extenuating needs.  Maybe it's just one or two.  Maybe it's all but
> >>>> one or two.  I don't think that currently, the problem space is
> >>>> properly enumerated, but is instead living in the abstract.
> >>>
> >>> Very good point.  This would perhaps show us much better where we're
> >>> heading here.  From the current input I only see the following required
> >>> changes in relation to a stock Cygwin distro:
> >>>
> >>> - gcc targeting Mingw rather than Cygwin.
> >> You already have that, it's called "mingw cross-compiler for cygwin".
> >> And that is not what msys users use.
> >> I think you've meant something different here, i'm not sure what.
> > 
> > That's exactly what I meant.  Of course we have a mingw cross compiler
> > in the Cygwin distro, but as far as the discussion on the mingw-w64 list
> > showed, MSYS users apparently prefer the "native" gcc compiler (the one
> > called "gcc")
> "native" compiler is the one that does not do cross-compiling. That is,
> it compiles with $build==$host, produces code for $build, and looks for
> headers/libs in $prefix/{include,lib} (unlike cross-compilers, which
> produce code for $host!=$build and look in $prefix/$host/{include,lib}).
> Whether it's called "gcc.exe" or "i686-w64-mingw32.exe" is not important
> (well, it is, but usually you just symlink gcc.exe to i686-w64-mingw32.exe).

I'm perfectly aware what a cross compiler is, but in case of Cygwin or
MSYS you have a bit of a hard time to define what a native compiler is,
the one creating Cygwin binaries or the one creating Windows binaries
with the unspoken assumption that they don't require the Cygwin DLL.
That's why I tried to describe it in so may word and apparently failed.

> > to produce mingw executables (aka "native Windows
> > exectables running without a compat layer") to avoid cross compiling
> > when creating native Windows executables.  If the native gcc in an MSYS
> > install targets MSYS, and if you had to use a cross compiler to create
> > native Windows executables (as in Cygwin), there would ne no reason for
> > MSYS at all since it would be equivalent to Cygwin.
> Yes. In this case i don't see how Cygwin fits in here. Unless you
> suddenly decided to become a MinGW toolchain vendor.
> /usr/bin/gcc is a cygwin gcc that targets cygwin
> /mingw/bin/gcc is MinGW gcc that targets W32.
> Anything that resides in /mingw is completely outside of cygwin domain,
> which is why i was surprised to hear that you wanted to provide mingw gcc.
> I would expect people to get cygwin/msys in one place, and get MinGW in
> another. Even mingw-get, while being a source of both msys and mingw
> packages, clearly distinguishes betweent he two.

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.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list