Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]

Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]

[Chiheng Xu]

On Tue, Aug 10, 2010 at 1:25 AM, Earnie <earnie@users.sourceforge.net> wrote:
> Chiheng Xu wrote:
>>
>>  On Fri, Jul 30, 2010 at 10:50 AM, Chiheng Xu <chiheng.xu@gmail.com>
>>  wrote:
>> >
>> > 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
mode.

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
> use.
>

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 .





-- 
Chiheng Xu
Wuhan,China

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

On 08/09/2010 07:19 PM, Chiheng Xu wrote:
> 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
> mode.

Not true.  But you are correct that in 1.7 it is harder to get text mode
processing in a default install, because text mode is a) slower, and b)
less tested.

> 
> As far as I know, Cygwin now use Windows shortcut to implement
> symlink. This work well with native apps.

Not true.  Cygwin can read windows shortcuts as symlinks, but does not
generate windows shortcuts to hold new symlinks because windows
shortcuts are inherently limited in such a way that they cannot serve as
true POSIX symlinks.

> 
> 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".

Such a patch will never be accepted in the cygwin port of bash.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]

[Chiheng Xu]

On Tue, Aug 10, 2010 at 9:57 AM, Eric Blake <eblake@redhat.com> wrote:
> On 08/09/2010 07:19 PM, Chiheng Xu wrote:
>> As far as I know, Cygwin now use Windows shortcut to implement
>> symlink. This work well with native apps.
>
> Not true.  Cygwin can read windows shortcuts as symlinks, but does not
> generate windows shortcuts to hold new symlinks because windows
> shortcuts are inherently limited in such a way that they cannot serve as
> true POSIX symlinks.
>

http://en.wikipedia.org/wiki/Symbolic_link#Cygwin_symbolic_links



-- 
Chiheng Xu
Wuhan,China

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?]

[Corinna Vinschen]

On Aug 12 17:09, Chiheng Xu wrote:
> On Tue, Aug 10, 2010 at 9:57 AM, Eric Blake <eblake@redhat.com> wrote:
> > On 08/09/2010 07:19 PM, Chiheng Xu wrote:
> >> As far as I know, Cygwin now use Windows shortcut to implement
> >> symlink. This work well with native apps.
> >
> > Not true.  Cygwin can read windows shortcuts as symlinks, but does not
> > generate windows shortcuts to hold new symlinks because windows
> > shortcuts are inherently limited in such a way that they cannot serve as
> > true POSIX symlinks.
> >
> 
> http://en.wikipedia.org/wiki/Symbolic_link#Cygwin_symbolic_links

This is old info.  Better trust the original source of information:

http://www.cygwin.com/cygwin-ug-net/highlights.html#ov-hi-files


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple