Note: I am not Cc [email protected] since I'm not a member of the list. Chiheng Xu wrote: > > I must confess that I'm really a newbie of Cygwin and MinGW. >
I began with Cygwin many years ago. > 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. > Cygwin and native MinGW have never worked well together and thus I created MSYS. To transform the \r into something manageable in binary mode you would need to pipe the output of the gcc command to sed or tr to remove the \r; E.G. `gcc -print-multi-os-directory | tr -d "\r"`. As for native gcc opening stdout, stderr and files it writes in binary mode, I personally see no harm in it. But stdin and the files it opens for input cannot be since editors used may add \r\n. > So, to let MinGW gcc and other tools work in binary mode seems > crucial if you want use Cygwin as MinGW's shell. > Alternatively you could grab the source for a version and build it yourself adding the necessary bits. As for an official distribution if the changes are made upstream then they'll be in the distributed binaries. But it isn't as simple as adding binary.o to the final executable build. > 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. > And again this is why MSYS exists. Now, Cygwin themselves distributes a native binary version of GCC, perhaps you can convince them that their distribution should produce only binary output. But MinGW needs GCC to be as native supportive as it possibly can be. > > >> 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. > Yes, it always has. There is much file manipulation in the emulation which I removed from MSYS. It has to open the shortcut file to read the source path for the symlink and then check that file to see if it is a shortcut to yet another file. Windows programs other than the file explorer themselves do not know how to deal with the shortcut file. > 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". The /cygdrive thing is yet another reason MSYS came about. I argued that /cygdrive was bogus and needed to be simply /. Eventually a mount option was entered for you to change /cygdrive to what ever you wanted it to be including /. Before that you had to edit the registry entry. > 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`. > IIRC, this is the reason that text mode in Cygwin has survived this long. It was required to have Cygwin in text mode to use the native GCC. Are you sure you can't add an option to the CYGWIN variable version 1.7? > But, finally, I think the method of patching bash may be not > necessary. > The combination you stated above wasn't understood very well by me. It sounds as if you tried to mix MSYS and Cygwin binaries which is a combination for failure and a locked PC requiring a hard reboot. > MSYS's method of translating Unix path to "mixed" Win32 path may be > necessary and optimal. So, you only need to patch cygwin1.dll . > I modified cygwin1.dll and named it msys-1.0.dll. Really, I did it because at the time the patches necessary for what I wanted would not be accepted. One of the ideas I had with MSYS was to allow other vendors to distribute it in their own directories without fearing conflict of runtime with other implementations of MSYS. Cygwin 1.7 now does that as well but it took years for it to happen and most likely as a result of some paying client saying they wanted it. I don't have time or any desire to go muck with trying to have a patch accepted for Cygwin. But if you wish you may use any idea provided by MSYS that Cygwin doesn't yet do and try to provide the necessary patches to Cygwin for approval. Earnie ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
