This is the mail archive of the
mailing list for the Cygwin project.
Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]
- From: Chiheng Xu <chiheng dot xu at gmail dot com>
- To: Earnie <earnie at users dot sourceforge dot net>
- Cc: w64-public at lists dot sourceforge dot net, cygwin at cygwin dot com
- Date: Tue, 10 Aug 2010 09:19:46 +0800
- Subject: Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]
- References: <AANLkTikzVW_UqbgrmUCAKT-_-ArQtzQnMy0+uk3wWFou@mail.gmail.com> <4C4F7390.email@example.com> <4C502643.firstname.lastname@example.org> <AANLkTikNFADak1_fNDkfLKHMbTHFj8B76r_A5ROLH+Yh@mail.gmail.com> <4C5060C9.email@example.com> <AANLkTimv-vMxHqRx6kUA5WDt1AkFdXcD9h5xnJ=yjVW4@mail.gmail.com> <4C519892.firstname.lastname@example.org> <AANLkTi=_PJB8TnmzOcUUMfLi8Y0OpsoO5RK=r1ee88Sk@mail.gmail.com> <AANLkTin7EueWQr9Ms9iT_rUkxZFegRNNVo84G6Xu3ss3@mail.gmail.com> <4C51D47F.email@example.com> <AANLkTinSOi0bcv0wEaEuvqASxnwg7cBxHJC9VMBbkF0H@mail.gmail.com> <4C51DD43.firstname.lastname@example.org> <AANLkTikguOL9gFbKe6dOL3kbZqjO7CF0ArJLby-paLAE@mail.gmail.com> <AANLkTinFHMQBnw01hUbsC9DfDiEN5HD=ZLkOaDvpJXae@mail.gmail.com> <4C603A09.email@example.com>
On Tue, Aug 10, 2010 at 1:25 AM, Earnie <firstname.lastname@example.org> wrote:
> Chiheng Xu wrote:
>> On Fri, Jul 30, 2010 at 10:50 AM, Chiheng Xu <email@example.com>
>> > Is 64-bits MSYS or Cygwin necessary?
>> > MSYS may be not necessary at all.
>> > If Cygwin merge the changes done in MSYS, and provide a Win32_Path
>> > mode(translating all Unix paths to Win32 paths at fork/exec or
>> > spawn) and MinGW transform itself to use binary mode(linking with
>> > binmode.o instead of txtmode.o) and slightly patch uname.exe in
>> > coreutils, Cygwin has the potential to replace MSYS and provide
>> > many tools missing in MSYS, like tcl/tk, expect, dejagnu necessary
>> > for the testing of GCC/GDB/BINUTILS.
>> What I want to say is that, transform Cygwin to be universal POSIX
>> command line environment for Windows.
> I understood what you meant.
>> Cygwin's default mode is "Unix path mode", so it can't not launch
>> native Win32 executable(like MinGW gcc) that require paths in their
>> argv to be Win32 path. So Cygwin need to provide an optional
>> "Win32 path mode", like MSYS do.
> And I know this isn't yet going to happen. There are now some MSYS ideas
> present in Cygwin but it has been many years in getting that acceptance.
>> But ordinary Win32 executable is linked with txtmode.o, which is not
>> compatible with Cygwin's binary mode. So MinGW also need slightly
>> transform itself to linked with binmode.o.
> Nor MSYS' binary mode. But this won't change either since the default for
> Microsoft is text mode.
I must confess that I'm really a newbie of Cygwin and MinGW.
As far as I know, Cygwin has dropped text mode in 1.7, only providing
binary mode. This make Cygwin more like an real Linux environment. I
think this is because many Unix tools can not work perfectly at text
When I use Cygwin shell and MinGW gcc to configure gcc, the configure
script invoke `gcc -print-multi-os-directory`, the Cygwin shell could
not handle the trailing "\r". If the MinGW gcc work in binary mode,
the problem will disappear.
So, to let MinGW gcc and other tools work in binary mode seems crucial
if you want use Cygwin as MinGW's shell.
I am more interested in toolchain(GCC/BINUTILS/GDB). I only want
MinGW toolchain to compatible with Cygwin. This can let us use Cygwin
to build and test MinGW toolchain.
>> Cygwin has an CYGWIN environment variable, can set the mode of
>> cygwin1.dll . I believe Cygwin maintainer will accept to add an
>> "Win32 path mode".
> There is more to it than this. Cygwin provides a script or binary to
> convert the paths between Windows and POSIX. But it also does funny things
> to emulate symlinks and native GCC has no idea what to do with these.
> Makefiles contain the creation of symlinks and this causes the native GCC
> problems when building a package. It was not an easy decision to fork
> Cygwin when I did but I did because of the issues of acceptance of the
> patches. If you feel that you can have luck with providing Cygwin with such
> patches more power to you. I would be happy to see it and would promote its
As far as I know, Cygwin now use Windows shortcut to implement
symlink. This work well with native apps.
Last year, I have tried to patch bash-3.2 of Cygwin to let it's "pwd"
built-in command to print the Win32 version of current working
directory, like "d:/work/gcc" , instead of "/cygdrive/d/work/gcc". I
used the patched Cygwin bash(with MSYS's uname.exe)and MinGW gcc to
configure and build MinGW gcc in Cygwin. The configure script work
well initially. But it choke at `gcc -print-multi-os-directory`.
But, finally, I think the method of patching bash may be not necessary.
MSYS's method of translating Unix paths to "mixed" Win32 paths may be
necessary and optimal. So, you only need to patch cygwin1.dll .
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple