Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
Hi Алексей,
On Jun 11 21:10, Алексей Павлов wrote:
Cygwin and MSYS have significantly different goals (even if MSYS is
entirely based on Cygwin).
My understanding is that MSYS is the minimal shell required to run
autotools and get sources from internet from different repositories.
I'm again puzzled as to the mixup between the underlying POSIX DLL
called Cygwin/MSYS2, and the full distro (The DLL plus all tools) called
Cygwin/MSYS2.
I'm concerned about forking the Cygwin DLL.
I have no problems at all if you create a distro called MSYS2 centered
around the upstream Cygwin DLL.
MSYS is about porting Unix programs to Windows without having a Posix
emulation layer, and then (hopefully!) getting those changes up-streamed.
But Cygwin/MSYS2, the DLL *is* a POSIX layer. You can call it a parrot,
and it's still a POSIX layer.
Typically, on MSYS, the executables that are run want to be native Win32
where-as on Cygwin they want to be Posix and this will always be the case
and a problem.
Why? Cygwin (the DLL) never refused to run native applications.
MSYS includes the following changes to Cygwin to support using native Win32
programs:
1. Automatic path mangling of command line arguments and environment
variables to Win32 form on the fly for Win32 applications inside bash.exe
That's a bash change which does not affect the underlying Cygwin/MSYS DLL.
2. Ability to change OSNAME with an environment variable (MSYSTEM) to
change it between MSYS and MINGW32 (so people can add to or fix MSYS
programs should they need to).
Ditto.
3. Conversion of output of native Win32 application output from Windows
line endings to Posix line endings - removing trailing '\r' symbol - in
bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as expected.
Ditto.
4. Replaced Cygwin symlinks with copying (we can investigate an option for
mklink symlinks on Vista and above but this is a topic for discussion -
MSYS compliant software tend to work around most ln-as-cp issues when
possible anyway).
I said my share about what I think of copying files when the application
expects to get a symlink. It's wrong. It's dangerous. You still have
the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
CYGWIN=winsymlinks:nativestrict options available when using Cygwin
unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
5. Add -W option to bash.exe's pwd command for compatibility with old
MSYS.
Bash again, the underlying Cygwin DLL is not affected.
6. Perhaps remove /cygdrive prefix to simply typing paths. Mostly this is
to retain compatibility with MSYS-enabled software that makes assumptions
about /c/ being equivalent to C:/
It's not necessary at all to change the Cygwin/MSYS2 DLL to make this
happen. Just add this to /etc/fstab:
none / cygdrive binary,posix=0,user 0 0
Stop all Cygwin processes, login to your bash and try this:
$ cd /c
$ ls
$Recycle.Bin Documents and Settings ProgramData System Volume Information
bootmgr pagefile.sysPython32 Users
BOOTNXT PerfLogsrhcygwin Windows
cygwinProgram Files swapfile.sys
cygwin64 Program Files (x86) Symbols
7. Minor changes to other userland programs (such as Perl so it reports
msys as $^O) which again helps to retain compatibility.
Again, some tool, doesn't affect the Cygwin DLL.
The reality is that MSYS exists and it's really old and getting in the way
of developers, and MSYS2 is needed to replace this. I'm surprised therefore
at the negative reaction, but really hope that MSYS2 can be viewed as a
complimentary off-shot from Cygwin (even *hopefully* by the Cygwin
developers!).
I'm not negative. I'm just defending the integrity of the Cygwin DLL.
Again, I'm perfectly happy if you provide an MSYS2 distro containing
special tools, like a tweaked bash and an entire, Mingw-centric
toolchain arrangement, as long as you keep the underlying Cygwin DLL
intact as provided upstream. Also, don't change the name of the DLL and
the target name of the toolchain ({i686/x86_64}-pc-cygwin).
Everyone would have an advantage of this:
- There would be only one source of the underlying POSIX-providing DLL.
Central repository, only one source to care about, no merging and
tweaking hassle.
- The DLL name stays intact, thus every tool built in and for the MSYS2
environment would run in a Cygwin distro environment as well.
- The toolchain name stays intact. You can just grab the latest gcc and
binutils sources and build them for the upstream supported
${arch}-pc-cygwin target and it would create files running in both
environments.
- While the normal Mingw/MSYS2 user would not have to look into the
Cygwin distro since the MSYS2 distro provides what he or she needs,
the more demanding user of MSYS2 would have free access to all tools
provided by the Cygwin distro with thousands of tools and applications,
not to mention a fully
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 12 12:47, Corinna Vinschen wrote: 6. Perhaps remove /cygdrive prefix to simply typing paths. Mostly this is to retain compatibility with MSYS-enabled software that makes assumptions about /c/ being equivalent to C:/ It's not necessary at all to change the Cygwin/MSYS2 DLL to make this happen. Just add this to /etc/fstab: none / cygdrive binary,posix=0,user 0 0 Stop all Cygwin processes, login to your bash and try this: $ cd /c $ ls $Recycle.Bin Documents and Settings ProgramData System Volume Information bootmgr pagefile.sysPython32 Users BOOTNXT PerfLogsrhcygwin Windows cygwinProgram Files swapfile.sys cygwin64 Program Files (x86) Symbols I forgot to provide a link to the User's Guide describing the mount table and the cygdrive prefix handling: http://cygwin.com/cygwin-ug-net/using.html#mount-table http://cygwin.com/cygwin-ug-net/using.html#cygdrive The mount command also has changed from how it worked in earlier Cygwin versions: http://cygwin.com/cygwin-ug-net/using-utils.html#mount HTH, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
--
Alexpux
Отправлено с помощью Sparrow (http://www.sparrowmailapp.com/?sig)
среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
Hi Алексей,
On Jun 11 21:10, Алексей Павлов wrote:
Cygwin and MSYS have significantly different goals (even if MSYS is
entirely based on Cygwin).
My understanding is that MSYS is the minimal shell required to run
autotools and get sources from internet from different repositories.
I'm again puzzled as to the mixup between the underlying POSIX DLL
called Cygwin/MSYS2, and the full distro (The DLL plus all tools) called
Cygwin/MSYS2.
I'm concerned about forking the Cygwin DLL.
I have no problems at all if you create a distro called MSYS2 centered
around the upstream Cygwin DLL.
MSYS is about porting Unix programs to Windows without having a Posix
emulation layer, and then (hopefully!) getting those changes up-streamed.
But Cygwin/MSYS2, the DLL *is* a POSIX layer. You can call it a parrot,
and it's still a POSIX layer.
Typically, on MSYS, the executables that are run want to be native Win32
where-as on Cygwin they want to be Posix and this will always be the case
and a problem.
Why? Cygwin (the DLL) never refused to run native applications.
MSYS includes the following changes to Cygwin to support using native Win32
programs:
1. Automatic path mangling of command line arguments and environment
variables to Win32 form on the fly for Win32 applications inside bash.exe
That's a bash change which does not affect the underlying Cygwin/MSYS DLL.
This is changes in Cygwin dll not in bash. See changes in path.cc, spawn.cc and
new files msys.cc and is msys.cc
2. Ability to change OSNAME with an environment variable (MSYSTEM) to
change it between MSYS and MINGW32 (so people can add to or fix MSYS
programs should they need to).
Ditto.
Cygwin dll function uname changes
3. Conversion of output of native Win32 application output from Windows
line endings to Posix line endings - removing trailing '\r' symbol - in
bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as expected.
Ditto.
Yes it is bash changes and they also can be integrated in Cygwin bash I think
4. Replaced Cygwin symlinks with copying (we can investigate an option for
mklink symlinks on Vista and above but this is a topic for discussion -
MSYS compliant software tend to work around most ln-as-cp issues when
possible anyway).
I said my share about what I think of copying files when the application
expects to get a symlink. It's wrong. It's dangerous. You still have
the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
CYGWIN=winsymlinks:nativestrict options available when using Cygwin
unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
Yes it dangerous but native symlinks work need elevated shell and OS Vista+
5. Add -W option to bash.exe's pwd command for compatibility with old
MSYS.
Bash again, the underlying Cygwin DLL is not affected.
You are right
6. Perhaps remove /cygdrive prefix to simply typing paths. Mostly this is
to retain compatibility with MSYS-enabled software that makes assumptions
about /c/ being equivalent to C:/
It's not necessary at all to change the Cygwin/MSYS2 DLL to make this
happen. Just add this to /etc/fstab:
none / cygdrive binary,posix=0,user 0 0
Stop all Cygwin processes, login to your bash and try this:
$ cd /c
$ ls
$Recycle.Bin Documents and Settings ProgramData System Volume Information
bootmgr pagefile.sys Python32 Users
BOOTNXT PerfLogs rhcygwin Windows
cygwin Program Files swapfile.sys
cygwin64 Program Files (x86) Symbols
thanks for it!
7. Minor changes to other userland programs (such as Perl so it reports
msys as $^O) which again helps to retain compatibility.
Again, some tool, doesn't affect the Cygwin DLL.
Not very critical for me because it can be resolved
The reality is that MSYS exists and it's really old and getting in the way
of developers, and MSYS2 is needed to replace this. I'm surprised therefore
at the negative reaction, but really hope that MSYS2 can be viewed as a
complimentary off-shot from Cygwin (even *hopefully* by the Cygwin
developers!).
I'm not negative. I'm just defending the integrity of the Cygwin DLL.
Again, I'm perfectly happy if you provide an MSYS2 distro containing
special tools, like a tweaked bash and an entire, Mingw-centric
toolchain arrangement, as long as you keep the underlying Cygwin DLL
intact as provided upstream. Also, don't change the name of the DLL and
the target name of the toolchain ({i686/x86_64}-pc-cygwin).
Everyone would have an advantage of this:
- There would be only one source of the underlying POSIX-providing DLL.
Central repository, only one source to care about, no merging and
tweaking hassle.
-
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
--
Alexpux
Отправлено с помощью Sparrow (http://www.sparrowmailapp.com/?sig)
среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
Hi Алексей,
On Jun 11 21:10, Алексей Павлов wrote:
Cygwin and MSYS have significantly different goals (even if MSYS is
entirely based on Cygwin).
My understanding is that MSYS is the minimal shell required to run
autotools and get sources from internet from different repositories.
I'm again puzzled as to the mixup between the underlying POSIX DLL
called Cygwin/MSYS2, and the full distro (The DLL plus all tools) called
Cygwin/MSYS2.
I'm concerned about forking the Cygwin DLL.
I have no problems at all if you create a distro called MSYS2 centered
around the upstream Cygwin DLL.
MSYS is about porting Unix programs to Windows without having a Posix
emulation layer, and then (hopefully!) getting those changes up-streamed.
But Cygwin/MSYS2, the DLL *is* a POSIX layer. You can call it a parrot,
and it's still a POSIX layer.
Typically, on MSYS, the executables that are run want to be native Win32
where-as on Cygwin they want to be Posix and this will always be the case
and a problem.
Why? Cygwin (the DLL) never refused to run native applications.
MSYS includes the following changes to Cygwin to support using native Win32
programs:
1. Automatic path mangling of command line arguments and environment
variables to Win32 form on the fly for Win32 applications inside bash.exe
That's a bash change which does not affect the underlying Cygwin/MSYS DLL.
This is changes in Cygwin dll not in bash. See changes in path.cc, spawn.cc and
new files msys.cc and is msys.cc
2. Ability to change OSNAME with an environment variable (MSYSTEM) to
change it between MSYS and MINGW32 (so people can add to or fix MSYS
programs should they need to).
Ditto.
Cygwin dll function uname changes
3. Conversion of output of native Win32 application output from Windows
line endings to Posix line endings - removing trailing '\r' symbol - in
bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as expected.
Ditto.
Yes it is bash changes and they also can be integrated in Cygwin bash I think
4. Replaced Cygwin symlinks with copying (we can investigate an option for
mklink symlinks on Vista and above but this is a topic for discussion -
MSYS compliant software tend to work around most ln-as-cp issues when
possible anyway).
I said my share about what I think of copying files when the application
expects to get a symlink. It's wrong. It's dangerous. You still have
the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
CYGWIN=winsymlinks:nativestrict options available when using Cygwin
unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
Yes it dangerous but native symlinks work need elevated shell and OS Vista+
5. Add -W option to bash.exe's pwd command for compatibility with old
MSYS.
Bash again, the underlying Cygwin DLL is not affected.
You are right
6. Perhaps remove /cygdrive prefix to simply typing paths. Mostly this is
to retain compatibility with MSYS-enabled software that makes assumptions
about /c/ being equivalent to C:/
It's not necessary at all to change the Cygwin/MSYS2 DLL to make this
happen. Just add this to /etc/fstab:
none / cygdrive binary,posix=0,user 0 0
Stop all Cygwin processes, login to your bash and try this:
$ cd /c
$ ls
$Recycle.Bin Documents and Settings ProgramData System Volume Information
bootmgr pagefile.sys Python32 Users
BOOTNXT PerfLogs rhcygwin Windows
cygwin Program Files swapfile.sys
cygwin64 Program Files (x86) Symbols
thanks for it!
7. Minor changes to other userland programs (such as Perl so it reports
msys as $^O) which again helps to retain compatibility.
Again, some tool, doesn't affect the Cygwin DLL.
Not very critical for me because it can be resolved
The reality is that MSYS exists and it's really old and getting in the way
of developers, and MSYS2 is needed to replace this. I'm surprised therefore
at the negative reaction, but really hope that MSYS2 can be viewed as a
complimentary off-shot from Cygwin (even *hopefully* by the Cygwin
developers!).
I'm not negative. I'm just defending the integrity of the Cygwin DLL.
Again, I'm perfectly happy if you provide an MSYS2 distro containing
special tools, like a tweaked bash and an entire, Mingw-centric
toolchain arrangement, as long as you keep the underlying Cygwin DLL
intact as provided upstream. Also, don't change the name of the DLL and
the target name of the toolchain ({i686/x86_64}-pc-cygwin).
Everyone would have an advantage of this:
- There would be only one source of the underlying POSIX-providing DLL.
Central repository, only one source to care about, no merging and
tweaking hassle.
- The DLL
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
2013/6/12 LRN lrn1...@gmail.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12.06.2013 14:47, Corinna Vinschen wrote:
Hi Алексей,
On Jun 11 21:10, Алексей Павлов wrote:
MSYS includes the following changes to Cygwin to support using native Win32
programs:
1. Automatic path mangling of command line arguments and environment
variables to Win32 form on the fly for Win32 applications inside bash.exe
That's a bash change which does not affect the underlying Cygwin/MSYS DLL.
You misinterpreted that.
The mangling is done in msys-2.dll, it's done every time a process is
spawned. The parent checks the dependencies of the child, and if child
does NOT depend on msys-2.dll (that is, if child is not a MSYS
application), the parent will spawn it with mangled environment (thus
the child will not get POSIX paths in envvars, such as PATH) mangled and
arguments (thus the code that invokes the spawning functionality is free
to give POSIX paths in the arguments to the child, but the actual child
will get appropriate DOS paths in the arguments instead).
Try doing this in Cygwin:
$ echo 123 ~/test.txt
$ $WINDIR/notepad.exe ~/test.txt
I expect that this wouldn't work, unless Cygwin expands ~ to a DOS path.
Or this (obviously, fix the path to sh.exe for your machine):
$ echo A=%PATH% C:\Cygwin\bin\sh.exe --login -i -c echo B=$PATH;
percent=%; $COMSPEC //C echo C=${percent}PATH${percent}
When i do this in MSYS, i get something like this:
A=C:\Windows\system32;C:\Windows
B=.:/usr/local/bin:/mingw/bin:/bin:/c/Windows/system32:/c/Windows
C=.;f:\msys05\local\bin;F:\mingw05\bin;f:\msys05\bin;c:\Windows\system32;c:\Windows
I'm not sure about the implementation details, you'd have to ask alexey
(namely, is that a change in fork() or exec()? What about posix_spawn()?).
hmm, to translate environment on process-start for
none-cygwin-processes looks to me like a feature belonging in general
to cygwin-dll, isn't it?
If not done, then I see it more as a bug there then a good argument
for cloning it.
Kai
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 15:57, Ray Donnelly wrote: I wonder if it would be possible to have a plugin system to allow for the behaviour changes we need to cygwin.dll, so msys.dll exists and only handles those parts and cygwin.dll loads that as a plugin, if there's no plugin specified then everything proceeds as 'normal cygwin'. I don't see how this is better than simply adding the necessary code to Cygwin DLL and adding a setting for switching that code on and off. For that to truly make sense, you have to design a complete plugin system for Cygwin, with multiple plug points, a generic way for plugins to affect Cygwin (plugin API), a way to solve plugin conflicts... No, that's too complex. If Cygwin DLL is aware of Msys plugin dll, explicitly loads it, gives it particular data, and makes assumptions about the way Msys modifies Cygwin state - that's not really a plugin anymore. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRuGRpAAoJEOs4Jb6SI2CwK5wH/0qkypWqpzpE045wvrzsztcO xywLV7P3JvGzx9e/T8SX84n1mV8R0RPbMPmLuRX+i1aarmdJoIG10o5nch2uVucp 4QmjMUAV54LYl2venCNCvbuBaX2Qru1y+XNQFvayDciLiBYejIMXKRfHeziM9KQV juJKnFFTxNuEeB8XZQfe9K0tcUdKiA8jTHU+ZmBx5/KCxDF8si5BFjppvfJyNY2U SjCtGPffiHdDPxKlCGYaprqfQWid8VFoteKj4xmpn8uMU+EzENEXtRCDKOQ8tviW EnRyfih8swDB4AP7k17+KocK3hqj6BEbPZ+0C7mFBwRlI38tbUp0OPwhq1qHgkQ= =ZfyY -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 12 16:00, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 14:47, Corinna Vinschen wrote: Hi Алексей, On Jun 11 21:10, Алексей Павлов wrote: MSYS includes the following changes to Cygwin to support using native Win32 programs: 1. Automatic path mangling of command line arguments and environment variables to Win32 form on the fly for Win32 applications inside bash.exe That's a bash change which does not affect the underlying Cygwin/MSYS DLL. You misinterpreted that. The mangling is done in msys-2.dll, it's done every time a process is spawned. The parent checks the dependencies of the child, and if child does NOT depend on msys-2.dll (that is, if child is not a MSYS application), the parent will spawn it with mangled environment (thus the child will not get POSIX paths in envvars, such as PATH) mangled and arguments This is default in Cygwin for a long time. When Cygwin starts, a small number of variables is converted from Windows to POSIX style, namely PATH, HOME, LD_LIBRARY_PATH, TMPDIR, TMP, and TEMP. If a Cygwin process execve's a non-Cygwin process, the whole thing is done backwards. This is not done for any other variable, and in no direction, because trying to recognize other variable's content as path and then converting it to the other style is pure speculation on the DLL's part. The result is broken as often as not. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 12 15:50, Alexpux wrote:
среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
On Jun 11 21:10, Алексей Павлов wrote:
MSYS includes the following changes to Cygwin to support using native
Win32
programs:
1. Automatic path mangling of command line arguments and environment
variables to Win32 form on the fly for Win32 applications inside bash.exe
That's a bash change which does not affect the underlying Cygwin/MSYS DLL.
This is changes in Cygwin dll not in bash. See changes in path.cc, spawn.cc
and new files msys.cc and is msys.cc
You wrote it's a bash change. As a bash change I can understand it, as
a Cygwin change not so much. This is pure speculating on the DLL side
again. You simply don't know exactly if something is a path and in what
form the argument is used by the called application. If in doubt, use
cygpath.
2. Ability to change OSNAME with an environment variable (MSYSTEM) to
change it between MSYS and MINGW32 (so people can add to or fix MSYS
programs should they need to).
Ditto.
Cygwin dll function uname changes
Sigh.
3. Conversion of output of native Win32 application output from Windows
line endings to Posix line endings - removing trailing '\r' symbol - in
bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as expected.
Ditto.
Yes it is bash changes and they also can be integrated in Cygwin bash I think
man dos2unix
4. Replaced Cygwin symlinks with copying (we can investigate an option for
mklink symlinks on Vista and above but this is a topic for discussion -
MSYS compliant software tend to work around most ln-as-cp issues when
possible anyway).
I said my share about what I think of copying files when the application
expects to get a symlink. It's wrong. It's dangerous. You still have
the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
CYGWIN=winsymlinks:nativestrict options available when using Cygwin
unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
Yes it dangerous but native symlinks work need elevated shell and OS Vista+
Again, if you need a copy, use cp, not ln -s. It's plainly a bug in the
scripts or tools you're using, if they use ln -s (or symlink(2)) when
called in a Mingw environment. Neither of them must rely on symlinks.
I'm not negative. I'm just defending the integrity of the Cygwin DLL.
Again, I'm perfectly happy if you provide an MSYS2 distro containing
special tools, like a tweaked bash and an entire, Mingw-centric
toolchain arrangement, as long as you keep the underlying Cygwin DLL
intact as provided upstream. Also, don't change the name of the DLL and
the target name of the toolchain ({i686/x86_64}-pc-cygwin).
Everyone would have an advantage of this:
- There would be only one source of the underlying POSIX-providing DLL.
Central repository, only one source to care about, no merging and
tweaking hassle.
- The DLL name stays intact, thus every tool built in and for the MSYS2
environment would run in a Cygwin distro environment as well.
- The toolchain name stays intact. You can just grab the latest gcc and
binutils sources and build them for the upstream supported
${arch}-pc-cygwin target and it would create files running in both
environments.
- While the normal Mingw/MSYS2 user would not have to look into the
Cygwin distro since the MSYS2 distro provides what he or she needs,
the more demanding user of MSYS2 would have free access to all tools
provided by the Cygwin distro with thousands of tools and applications,
not to mention a fully function X server with X clients.
That's all I'm trying to say. I don't see a good reason to change the
Cygwin DLL. Use it as is and build your Mingw-targeting environment
around it. I'm here to help if something doesn't work out as you need
it. Maybe we find another, working solution, without having to fork
Cygwin.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
Ok, We're back to asking for a plugin with a clearly defined interface for
env. var and path translation; despite LRNs reasonable objections I think
it might be the only acceptable solution?
.. that way we can continue to speculate (as MSYS always has) about what's
a path and what isn't and also use the cygwin.dll unmodified.
Otherwise we're at an impasse.
On Wed, Jun 12, 2013 at 3:00 PM, Corinna Vinschen vinsc...@redhat.comwrote:
On Jun 12 15:50, Alexpux wrote:
среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
On Jun 11 21:10, Алексей Павлов wrote:
MSYS includes the following changes to Cygwin to support using
native Win32
programs:
1. Automatic path mangling of command line arguments and environment
variables to Win32 form on the fly for Win32 applications inside
bash.exe
That's a bash change which does not affect the underlying Cygwin/MSYS
DLL.
This is changes in Cygwin dll not in bash. See changes in path.cc,
spawn.cc and new files msys.cc and is msys.cc
You wrote it's a bash change. As a bash change I can understand it, as
a Cygwin change not so much. This is pure speculating on the DLL side
again. You simply don't know exactly if something is a path and in what
form the argument is used by the called application. If in doubt, use
cygpath.
2. Ability to change OSNAME with an environment variable (MSYSTEM) to
change it between MSYS and MINGW32 (so people can add to or fix MSYS
programs should they need to).
Ditto.
Cygwin dll function uname changes
Sigh.
3. Conversion of output of native Win32 application output from
Windows
line endings to Posix line endings - removing trailing '\r' symbol -
in
bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as
expected.
Ditto.
Yes it is bash changes and they also can be integrated in Cygwin bash I
think
man dos2unix
4. Replaced Cygwin symlinks with copying (we can investigate an
option for
mklink symlinks on Vista and above but this is a topic for
discussion -
MSYS compliant software tend to work around most ln-as-cp issues when
possible anyway).
I said my share about what I think of copying files when the
application
expects to get a symlink. It's wrong. It's dangerous. You still have
the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
CYGWIN=winsymlinks:nativestrict options available when using Cygwin
unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
Yes it dangerous but native symlinks work need elevated shell and OS
Vista+
Again, if you need a copy, use cp, not ln -s. It's plainly a bug in the
scripts or tools you're using, if they use ln -s (or symlink(2)) when
called in a Mingw environment. Neither of them must rely on symlinks.
I'm not negative. I'm just defending the integrity of the Cygwin DLL.
Again, I'm perfectly happy if you provide an MSYS2 distro containing
special tools, like a tweaked bash and an entire, Mingw-centric
toolchain arrangement, as long as you keep the underlying Cygwin DLL
intact as provided upstream. Also, don't change the name of the DLL and
the target name of the toolchain ({i686/x86_64}-pc-cygwin).
Everyone would have an advantage of this:
- There would be only one source of the underlying POSIX-providing DLL.
Central repository, only one source to care about, no merging and
tweaking hassle.
- The DLL name stays intact, thus every tool built in and for the MSYS2
environment would run in a Cygwin distro environment as well.
- The toolchain name stays intact. You can just grab the latest gcc and
binutils sources and build them for the upstream supported
${arch}-pc-cygwin target and it would create files running in both
environments.
- While the normal Mingw/MSYS2 user would not have to look into the
Cygwin distro since the MSYS2 distro provides what he or she needs,
the more demanding user of MSYS2 would have free access to all tools
provided by the Cygwin distro with thousands of tools and applications,
not to mention a fully function X server with X clients.
That's all I'm trying to say. I don't see a good reason to change the
Cygwin DLL. Use it as is and build your Mingw-targeting environment
around it. I'm here to help if something doesn't work out as you need
it. Maybe we find another, working solution, without having to fork
Cygwin.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 12 15:11, Ray Donnelly wrote: Ok, We're back to asking for a plugin with a clearly defined interface for env. var and path translation; despite LRNs reasonable objections I think it might be the only acceptable solution? .. that way we can continue to speculate (as MSYS always has) about what's a path and what isn't and also use the cygwin.dll unmodified. Otherwise we're at an impasse. First, may I politely ask, if this is really necessary, or if everybody thinks it's necessary just because the old MSYS did so. Does anybody have a real world example which requires this, and isn't easily fixed by using cygpath at the crucial stage? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
-- Alexpux Отправлено с помощью Sparrow (http://www.sparrowmailapp.com/?sig) среда, 12 июня 2013 г. в 18:33, Corinna Vinschen написал: On Jun 12 15:11, Ray Donnelly wrote: Ok, We're back to asking for a plugin with a clearly defined interface for env. var and path translation; despite LRNs reasonable objections I think it might be the only acceptable solution? .. that way we can continue to speculate (as MSYS always has) about what's a path and what isn't and also use the cygwin.dll unmodified. Otherwise we're at an impasse. First, may I politely ask, if this is really necessary, or if everybody thinks it's necessary just because the old MSYS did so. Does anybody have a real world example which requires this, and isn't easily fixed by using cygpath at the crucial stage? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public Corinna, the best example - try to use native mingw compiler under Cygwin to build binutils, for example. And you see all issues that MSYS resolve for developers. Regards, Alexey. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
--
Alexpux
Отправлено с помощью Sparrow (http://www.sparrowmailapp.com/?sig)
среда, 12 июня 2013 г. в 18:00, Corinna Vinschen написал:
On Jun 12 15:50, Alexpux wrote:
среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
On Jun 11 21:10, Алексей Павлов wrote:
MSYS includes the following changes to Cygwin to support using native
Win32
programs:
1. Automatic path mangling of command line arguments and environment
variables to Win32 form on the fly for Win32 applications inside
bash.exe
That's a bash change which does not affect the underlying Cygwin/MSYS DLL.
This is changes in Cygwin dll not in bash. See changes in path.cc, spawn.cc
and new files msys.cc and is msys.cc
You wrote it's a bash change. As a bash change I can understand it, as
a Cygwin change not so much. This is pure speculating on the DLL side
again. You simply don't know exactly if something is a path and in what
form the argument is used by the called application. If in doubt, use
cygpath.
But It works in MSYS for many years.
2. Ability to change OSNAME with an environment variable (MSYSTEM) to
change it between MSYS and MINGW32 (so people can add to or fix MSYS
programs should they need to).
Ditto.
Cygwin dll function uname changes
Sigh.
3. Conversion of output of native Win32 application output from Windows
line endings to Posix line endings - removing trailing '\r' symbol - in
bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as expected.
Ditto.
Yes it is bash changes and they also can be integrated in Cygwin bash I
think
man dos2unix
It can't be fixed by dos2unix because this issue is during configure and build
steps
4. Replaced Cygwin symlinks with copying (we can investigate an option
for
mklink symlinks on Vista and above but this is a topic for discussion -
MSYS compliant software tend to work around most ln-as-cp issues when
possible anyway).
I said my share about what I think of copying files when the application
expects to get a symlink. It's wrong. It's dangerous. You still have
the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
CYGWIN=winsymlinks:nativestrict options available when using Cygwin
unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
Yes it dangerous but native symlinks work need elevated shell and OS Vista+
Again, if you need a copy, use cp, not ln -s. It's plainly a bug in the
scripts or tools you're using, if they use ln -s (or symlink(2)) when
called in a Mingw environment. Neither of them must rely on symlinks.
And I need patch every configure script and Makefile to fix it?
I'm not negative. I'm just defending the integrity of the Cygwin DLL.
Again, I'm perfectly happy if you provide an MSYS2 distro containing
special tools, like a tweaked bash and an entire, Mingw-centric
toolchain arrangement, as long as you keep the underlying Cygwin DLL
intact as provided upstream. Also, don't change the name of the DLL and
the target name of the toolchain ({i686/x86_64}-pc-cygwin).
Everyone would have an advantage of this:
- There would be only one source of the underlying POSIX-providing DLL.
Central repository, only one source to care about, no merging and
tweaking hassle.
- The DLL name stays intact, thus every tool built in and for the MSYS2
environment would run in a Cygwin distro environment as well.
- The toolchain name stays intact. You can just grab the latest gcc and
binutils sources and build them for the upstream supported
${arch}-pc-cygwin target and it would create files running in both
environments.
- While the normal Mingw/MSYS2 user would not have to look into the
Cygwin distro since the MSYS2 distro provides what he or she needs,
the more demanding user of MSYS2 would have free access to all tools
provided by the Cygwin distro with thousands of tools and applications,
not to mention a fully function X server with X clients.
That's all I'm trying to say. I don't see a good reason to change the
Cygwin DLL. Use it as is and build your Mingw-targeting environment
around it. I'm here to help if something doesn't work out as you need
it. Maybe we find another, working solution, without having to fork
Cygwin.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Redundant declarations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A log is attached. There are more stuff like that. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRuIq4AAoJEOs4Jb6SI2Cw1fcH/2jxbZOSdJ40eODKak/qjxMp 9M/pLQ2ySG29sx2uPRQ7muJidnkeNryb+/td5jwYR2kaEA9jMYJ0JU6hd8Xz/ftG FGg8b1q75n0dNCuADbJSj5joDampYrvMuQGkS7Pbb4VG4MsRrTq4q8jTC+LayUsk keUGLS29/kRX63wyg2Qvzi++SrcYVfTm/PeDYZj/ZJnCYQKvG/JoHLHXkynmB67r ysFd1GHj7de9ivxjA5Kq2c6GLufRmUSGBIK6aCjijjGjmkCClucjWmZnK7BvSM4h xe5mhetHza0FedvGvtJSm4VhLc4iHGWZ9zxjpoH90SYSwuWJ2+nypTl1AI39DdI= =EtOL -END PGP SIGNATURE- redundant.log.xz Description: Binary data -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 17:50, Corinna Vinschen wrote: On Jun 12 16:00, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 14:47, Corinna Vinschen wrote: Hi Алексей, On Jun 11 21:10, Алексей Павлов wrote: MSYS includes the following changes to Cygwin to support using native Win32 programs: 1. Automatic path mangling of command line arguments and environment variables to Win32 form on the fly for Win32 applications inside bash.exe That's a bash change which does not affect the underlying Cygwin/MSYS DLL. You misinterpreted that. The mangling is done in msys-2.dll, it's done every time a process is spawned. The parent checks the dependencies of the child, and if child does NOT depend on msys-2.dll (that is, if child is not a MSYS application), the parent will spawn it with mangled environment (thus the child will not get POSIX paths in envvars, such as PATH) mangled and arguments This is default in Cygwin for a long time. When Cygwin starts, a small number of variables is converted from Windows to POSIX style, namely PATH, HOME, LD_LIBRARY_PATH, TMPDIR, TMP, and TEMP. If a Cygwin process execve's a non-Cygwin process, the whole thing is done backwards. This is not done for any other variable, and in no direction, because trying to recognize other variable's content as path and then converting it to the other style is pure speculation on the DLL's part. The result is broken as often as not. I can't say anything about variables (i can easily imagine cases where not converting variables would break the build process, but i can't name a package that does need it - because i never tried to compile anything without that feature, and i don't remember it misfiring on me and converting something that shouldn't have been converted). However, the fact that command line arguments are not converted (at least you didn't mention anything about converting arguments; i assume they are left untouched; my googling also supports that assumption) means that command line arguments like these: - -I/mingw/lib/glib-2.0/include /src/mingw-w64/mingw-w64-libraries/winpthreads/src/clock.c will not be converted, which makes it next to impossible to use W32 tools in conjunction with autotools (ok, the /src thing can be avoided by carefully using relative paths only, but i can't say how much things will slip past that and bite you, if mangling is switched off). You are also incorrect in assuming that the probability of MSys correctly guessing that something should be mangled is 0.5 (as often as not, as you put it). In my experience, the probability of a correct guess goes up to 0.9 and above. The logic is quite complex (see [1] for the list of rules MSYS1 uses; see MSYS2 source for the list of rules MSYS2 uses). There ARE cases when you don't want MSys to mangle things, but it does anyway, and the result is unsatisfactory. In these cases buildsystem has to be patched. Mostly it's when something that looks like a path (such as a prefix, i.e /mingw) is used in a construction like -DSOMEPREFIX=\/mingw\. The problem is solved by using config.h instead of -D (since the contents of files are not mangled). The reverse is also true - sometimes buildsystems will generate source files on the fly (usually - by processing .in files and substituting @VARIABLES@), and will insert absolute paths to files into generated code, i.e. fopen (/src/libcdio/blah/blah/foobar.data, r) (usually it's for testcases that are not designed to be relocatable anyway). This can be fixed directly (using relative names explicitly), or worked around by calling configure relatively (i.e. cd builddir ; ../srcdir/configure arguments - assuming that builddir and srcdir are siblings) when doing OOTSD builds (in which case all names will be relative no matter what). There are also selected cases where something looks like a path, but isn't one. One example that comes to mind is xmlcatalog.exe, which is given arguments like -//OASIS//ELEMENTS DocBook Information Pool V4.2//EN, which look like paths, but shouldn't be mangled. The solution is to use msys version of xmlcatalog (that fixes some other problems as well) instead of mingw version. Same goes for git. As i mentioned earlier in this thread, one of the things that msysGit devs did to their fork of MSYS1 was to slightly alter the mangling code to not to mangle some things (some kind of git refs, i forgot the specifics). Again, this is fixed by using real msys-git that needs no mangling. But most of the time things just work™ [1] http://www.mingw.org/wiki/Posix_path_conversion - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRuJTKAAoJEOs4Jb6SI2CwLwoIAL6GWU8LrXwO5WWvmlGzK/RF U+PRw62X9WVkyMY1IvHtHoMPlXjuAuphbZtH7NQGspECZtdUQLyQfacD47IvavGz jDQVXLUe4SdwQVcv4QLVOr3KC4YY0QFZqBfis3e8egRGqoHfI28+WynJU9X463CC
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
Am 12.06.2013 17:33, schrieb LRN: On 12.06.2013 17:50, Corinna Vinschen wrote: On Jun 12 16:00, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 14:47, Corinna Vinschen wrote: Hi Алексей, On Jun 11 21:10, Алексей Павлов wrote: MSYS includes the following changes to Cygwin to support using native Win32 programs: 1. Automatic path mangling of command line arguments and environment variables to Win32 form on the fly for Win32 applications inside bash.exe That's a bash change which does not affect the underlying Cygwin/MSYS DLL. You misinterpreted that. The mangling is done in msys-2.dll, it's done every time a process is spawned. The parent checks the dependencies of the child, and if child does NOT depend on msys-2.dll (that is, if child is not a MSYS application), the parent will spawn it with mangled environment (thus the child will not get POSIX paths in envvars, such as PATH) mangled and arguments This is default in Cygwin for a long time. When Cygwin starts, a small number of variables is converted from Windows to POSIX style, namely PATH, HOME, LD_LIBRARY_PATH, TMPDIR, TMP, and TEMP. If a Cygwin process execve's a non-Cygwin process, the whole thing is done backwards. This is not done for any other variable, and in no direction, because trying to recognize other variable's content as path and then converting it to the other style is pure speculation on the DLL's part. The result is broken as often as not. I can't say anything about variables (i can easily imagine cases where not converting variables would break the build process, but i can't name a package that does need it - because i never tried to compile anything without that feature, and i don't remember it misfiring on me and converting something that shouldn't have been converted). However, the fact that command line arguments are not converted (at least you didn't mention anything about converting arguments; i assume they are left untouched; my googling also supports that assumption) means that command line arguments like these: -I/mingw/lib/glib-2.0/include /src/mingw-w64/mingw-w64-libraries/winpthreads/src/clock.c will not be converted, which makes it next to impossible to use W32 tools in conjunction with autotools (ok, the /src thing can be avoided by carefully using relative paths only, but i can't say how much things will slip past that and bite you, if mangling is switched off). You are also incorrect in assuming that the probability of MSys correctly guessing that something should be mangled is 0.5 (as often as not, as you put it). In my experience, the probability of a correct guess goes up to 0.9 and above. The logic is quite complex (see [1] for the list of rules MSYS1 uses; see MSYS2 source for the list of rules MSYS2 uses). There ARE cases when you don't want MSys to mangle things, but it does anyway, and the result is unsatisfactory. In these cases buildsystem has to be patched. Mostly it's when something that looks like a path (such as a prefix, i.e /mingw) is used in a construction like -DSOMEPREFIX=\/mingw\. The problem is solved by using config.h instead of -D (since the contents of files are not mangled). The reverse is also true - sometimes buildsystems will generate source files on the fly (usually - by processing .in files and substituting @VARIABLES@), and will insert absolute paths to files into generated code, i.e. fopen (/src/libcdio/blah/blah/foobar.data, r) (usually it's for testcases that are not designed to be relocatable anyway). This can be fixed directly (using relative names explicitly), or worked around by calling configure relatively (i.e. cd builddir ; ../srcdir/configure arguments - assuming that builddir and srcdir are siblings) when doing OOTSD builds (in which case all names will be relative no matter what). There are also selected cases where something looks like a path, but isn't one. One example that comes to mind is xmlcatalog.exe, which is given arguments like -//OASIS//ELEMENTS DocBook Information Pool V4.2//EN, which look like paths, but shouldn't be mangled. The solution is to use msys version of xmlcatalog (that fixes some other problems as well) instead of mingw version. Same goes for git. As i mentioned earlier in this thread, one of the things that msysGit devs did to their fork of MSYS1 was to slightly alter the mangling code to not to mangle some things (some kind of git refs, i forgot the specifics). Again, this is fixed by using real msys-git that needs no mangling. But most of the time things just work™ [1] http://www.mingw.org/wiki/Posix_path_conversion To add a little bit to this discussion. I just did a native gcc x86_64-w64-mingw32 3-stage bootstrap using the MSYS2 version dated 10.06.. It worked out of the box, without any issues. That wasn't possible with the old MSYS because of it's 32-bitness and it's impossible with resent cygwin. Cheers Rainer
Re: [Mingw-w64-public] Mingw-builds
On Jun 7, 2013 2:17 AM, Алексей Павлов alex...@gmail.com wrote: Hi everyone! We release on-line installer for our builds. You can download it from mingw-builds-install.exe. This installer automatically receive file with all our builds and you can choose what version you want to install. Thanks for providing that service! It should be very useful for users. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 12, 2013 11:53 AM, Rainer Emrich sf.rai...@emrich-ebersheim.de wrote: Am 12.06.2013 17:33, schrieb LRN: On 12.06.2013 17:50, Corinna Vinschen wrote: On Jun 12 16:00, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 14:47, Corinna Vinschen wrote: Hi Алексей, On Jun 11 21:10, Алексей Павлов wrote: MSYS includes the following changes to Cygwin to support using native Win32 programs: 1. Automatic path mangling of command line arguments and environment variables to Win32 form on the fly for Win32 applications inside bash.exe That's a bash change which does not affect the underlying Cygwin/MSYS DLL. You misinterpreted that. The mangling is done in msys-2.dll, it's done every time a process is spawned. The parent checks the dependencies of the child, and if child does NOT depend on msys-2.dll (that is, if child is not a MSYS application), the parent will spawn it with mangled environment (thus the child will not get POSIX paths in envvars, such as PATH) mangled and arguments This is default in Cygwin for a long time. When Cygwin starts, a small number of variables is converted from Windows to POSIX style, namely PATH, HOME, LD_LIBRARY_PATH, TMPDIR, TMP, and TEMP. If a Cygwin process execve's a non-Cygwin process, the whole thing is done backwards. This is not done for any other variable, and in no direction, because trying to recognize other variable's content as path and then converting it to the other style is pure speculation on the DLL's part. The result is broken as often as not. I can't say anything about variables (i can easily imagine cases where not converting variables would break the build process, but i can't name a package that does need it - because i never tried to compile anything without that feature, and i don't remember it misfiring on me and converting something that shouldn't have been converted). However, the fact that command line arguments are not converted (at least you didn't mention anything about converting arguments; i assume they are left untouched; my googling also supports that assumption) means that command line arguments like these: -I/mingw/lib/glib-2.0/include /src/mingw-w64/mingw-w64-libraries/winpthreads/src/clock.c will not be converted, which makes it next to impossible to use W32 tools in conjunction with autotools (ok, the /src thing can be avoided by carefully using relative paths only, but i can't say how much things will slip past that and bite you, if mangling is switched off). You are also incorrect in assuming that the probability of MSys correctly guessing that something should be mangled is 0.5 (as often as not, as you put it). In my experience, the probability of a correct guess goes up to 0.9 and above. The logic is quite complex (see [1] for the list of rules MSYS1 uses; see MSYS2 source for the list of rules MSYS2 uses). There ARE cases when you don't want MSys to mangle things, but it does anyway, and the result is unsatisfactory. In these cases buildsystem has to be patched. Mostly it's when something that looks like a path (such as a prefix, i.e /mingw) is used in a construction like -DSOMEPREFIX=\/mingw\. The problem is solved by using config.h instead of -D (since the contents of files are not mangled). The reverse is also true - sometimes buildsystems will generate source files on the fly (usually - by processing .in files and substituting @VARIABLES@), and will insert absolute paths to files into generated code, i.e. fopen (/src/libcdio/blah/blah/foobar.data, r) (usually it's for testcases that are not designed to be relocatable anyway). This can be fixed directly (using relative names explicitly), or worked around by calling configure relatively (i.e. cd builddir ; ../srcdir/configure arguments - assuming that builddir and srcdir are siblings) when doing OOTSD builds (in which case all names will be relative no matter what). There are also selected cases where something looks like a path, but isn't one. One example that comes to mind is xmlcatalog.exe, which is given arguments like -//OASIS//ELEMENTS DocBook Information Pool V4.2//EN, which look like paths, but shouldn't be mangled. The solution is to use msys version of xmlcatalog (that fixes some other problems as well) instead of mingw version. Same goes for git. As i mentioned earlier in this thread, one of the things that msysGit devs did to their fork of MSYS1 was to slightly alter the mangling code to not to mangle some things (some kind of git refs, i forgot the specifics). Again, this is fixed by using real msys-git that needs no mangling. But most of the time things just work™ [1] http://www.mingw.org/wiki/Posix_path_conversion To add a little bit to this discussion. I just did a native gcc x86_64-w64-mingw32 3-stage bootstrap using the MSYS2 version dated 10.06.. It
