* Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?] [not found] ` <4C603A09.7060804@users.sourceforge.net> @ 2010-08-10 1:19 ` Chiheng Xu 2010-08-10 1:58 ` Eric Blake 0 siblings, 1 reply; 4+ messages in thread From: Chiheng Xu @ 2010-08-10 1:19 UTC (permalink / raw) To: Earnie; +Cc: w64-public, cygwin 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?] 2010-08-10 1:19 ` [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?] Chiheng Xu @ 2010-08-10 1:58 ` Eric Blake 2010-08-12 9:09 ` Chiheng Xu 0 siblings, 1 reply; 4+ messages in thread From: Eric Blake @ 2010-08-10 1:58 UTC (permalink / raw) To: cygwin, chiheng.xu [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?] 2010-08-10 1:58 ` Eric Blake @ 2010-08-12 9:09 ` Chiheng Xu 2010-08-12 9:51 ` Corinna Vinschen 0 siblings, 1 reply; 4+ messages in thread From: Chiheng Xu @ 2010-08-12 9:09 UTC (permalink / raw) To: Eric Blake; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?] 2010-08-12 9:09 ` Chiheng Xu @ 2010-08-12 9:51 ` Corinna Vinschen 0 siblings, 0 replies; 4+ messages in thread From: Corinna Vinschen @ 2010-08-12 9:51 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-08-12 9:51 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <AANLkTikzVW_UqbgrmUCAKT-_-ArQtzQnMy0+uk3wWFou@mail.gmail.com> [not found] ` <4C4F7390.7000708@users.sourceforge.net> [not found] ` <4C502643.5000604@users.sourceforge.net> [not found] ` <AANLkTikNFADak1_fNDkfLKHMbTHFj8B76r_A5ROLH+Yh@mail.gmail.com> [not found] ` <4C5060C9.8070505@users.sourceforge.net> [not found] ` <AANLkTimv-vMxHqRx6kUA5WDt1AkFdXcD9h5xnJ=yjVW4@mail.gmail.com> [not found] ` <4C519892.7080306@users.sourceforge.net> [not found] ` <AANLkTi=_PJB8TnmzOcUUMfLi8Y0OpsoO5RK=r1ee88Sk@mail.gmail.com> [not found] ` <AANLkTin7EueWQr9Ms9iT_rUkxZFegRNNVo84G6Xu3ss3@mail.gmail.com> [not found] ` <4C51D47F.1010601@users.sourceforge.net> [not found] ` <AANLkTinSOi0bcv0wEaEuvqASxnwg7cBxHJC9VMBbkF0H@mail.gmail.com> [not found] ` <4C51DD43.3010308@users.sourceforge.net> [not found] ` <AANLkTikguOL9gFbKe6dOL3kbZqjO7CF0ArJLby-paLAE@mail.gmail.com> [not found] ` <AANLkTinFHMQBnw01hUbsC9DfDiEN5HD=ZLkOaDvpJXae@mail.gmail.com> [not found] ` <4C603A09.7060804@users.sourceforge.net> 2010-08-10 1:19 ` [Mingw-w64-public] Cygwin vs MSYS [WAS: Making config.guess detect mingw64 platform?] Chiheng Xu 2010-08-10 1:58 ` Eric Blake 2010-08-12 9:09 ` Chiheng Xu 2010-08-12 9:51 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).