This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: MSYS mode (continue)
- From: LRN <lrn1986 at gmail dot com>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 29 Jul 2013 19:36:13 +0400
- Subject: Re: MSYS mode (continue)
- References: <20130711111744 dot GG15346 at calimero dot vinschen dot de> <51F123EB dot 9000900 at cwilson dot fastmail dot fm> <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>
-----BEGIN PGP SIGNED MESSAGE-----
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).
> 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.
- --
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJR9ovsAAoJEOs4Jb6SI2CwwdcH/0qynygMxZMHTh/P9WIkJ3oQ
yysC8gJ21ScexouI3uwSzFH6n9pFUZ7cboFsdY3b5WH62K85RHZnI0EUd8YLAmM+
NXPj7XiqSbWbEO7GBQhsvr3T5QEP4M/2xCOTQdqMJI2Ew4VAbKsEDrZQIvZoQoGD
59ZFzMZR1phE868EFg2QtdHVomyZwudUg+ZWkuK4vxhkfkMQ/ebNG21tvRSXFgYM
yh/jRXTd0ITVw7NgXc5w6U16u9xC3eJFtdIfpxF1cKvkPUikyo4rZFiLl+n8O1JM
X+XMrJmHOjTV/yqYB1g5Zx6Ebhb8xkh0S222fDrWCD7TtQixT5rKmt3XIdFwRSk=
=d8By
-----END PGP SIGNATURE-----