Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 18:51, Alexpux wrote: среда, 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: 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? To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance. So it might turn out that `ln -s' hack would only affect corner-cases (where people just write `ln -s' in makefiles and such). Later today, when i get a new MSYS2 build (based upon the latest Cygwin with fixed symlinks in case of a different cygdrive prefix), i'll hack AC_PROG_LN_S to allow MSYS2's `ln -s' to be used, and will check if that works (i expect that it would). I could also replace /usr/bin/ln with a wrapper script that would log all invocations of `ln' with `-s' to count exactly how much it is being used (that said, it won't cover things like `lndir' which is use when needed). Also, to make sure correct things end up being archived: you need a special privilege to create symlinks. Administrators have it by default, but you can give it to users as well. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRwWbqAAoJEOs4Jb6SI2CwpN8H/jgHGRp8BshfIEzqZhk2XC4O SvxbqmzOteuE8Hg5bhlTaL0S5KNY4Riy1DZBQgXZc6m/Gtno8U9IQEVqmm3O+o1H HomWxvQojTnp6Ur1GYuNpfwXmAFzZq3zOB40H3Zd717B7Y7vwrT8EcgjbUsJYiSN xVYTWlKxU0v+lQ+R84V4ISAaJDjNJFRAHW5zJ9pmHU2zV+bwAnUzZtxMYRoHByuv 09nYmXrdb5kr6xQPehonG1ENjjPAI8v5KCfag8Q25DdqTTq1pnWDXsif9e7CfF1e IsYSEaz6kJe1vgoGZ5EioW2qISwwk3IHMPZqQLOTQY7n4GVMi9sC9+ef+VVHMBM= =jKoK -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 19 12:08, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 18:51, Alexpux wrote: среда, 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: 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? To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance. On Cygwin? Not that I'm aware of. I tested the AC_PROG_LN_S macro on Cygwin and the LN_S setting is 'ls -s' afterwards. That's with autoconf-2.69. So it might turn out that `ln -s' hack would only affect corner-cases (where people just write `ln -s' in makefiles and such). Later today, when i get a new MSYS2 build (based upon the latest Cygwin with fixed symlinks in case of a different cygdrive prefix), i'll hack AC_PROG_LN_S to allow MSYS2's `ln -s' to be used, and will check if that works (i expect that it would). I could also replace /usr/bin/ln with a wrapper script that would log all invocations of `ln' with `-s' to count exactly how much it is being used (that said, it won't cover things like `lndir' which is use when needed). What about leaving the symlink(2) function alone and rather just replace the ln(1) tool with a wrapper which calls cp(1) in case of the -s option instead, some ln.orig.exe otherwise? Corinna -- 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 19.06.2013 12:57, Corinna Vinschen wrote: On Jun 19 12:08, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 18:51, Alexpux wrote: среда, 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: 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? To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance. On Cygwin? Not that I'm aware of. I tested the AC_PROG_LN_S macro on Cygwin and the LN_S setting is 'ls -s' afterwards. That's with autoconf-2.69. My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S. So it might turn out that `ln -s' hack would only affect corner-cases (where people just write `ln -s' in makefiles and such). Later today, when i get a new MSYS2 build (based upon the latest Cygwin with fixed symlinks in case of a different cygdrive prefix), i'll hack AC_PROG_LN_S to allow MSYS2's `ln -s' to be used, and will check if that works (i expect that it would). I could also replace /usr/bin/ln with a wrapper script that would log all invocations of `ln' with `-s' to count exactly how much it is being used (that said, it won't cover things like `lndir' which is use when needed). What about leaving the symlink(2) function alone and rather just replace the ln(1) tool with a wrapper which calls cp(1) in case of the -s option instead, some ln.orig.exe otherwise? No idea. Any proposal will have to be tested first. Alexey just gave me a new snapshot, i'll test nativestrict there, and then we'll see. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRwXqnAAoJEOs4Jb6SI2CwYfEIAMHKLfAZ7w2ntsvhG6tvyycV H2dalZ+qHCAMSmUL5XPmxPANnQVpWi+iiA2S4wo01vZ5zi2A15FcQL0oFgv84Wfl xeUkU3VhvLGzbtYhbCW8Cgru9omQqn/+wlAp6GLS4T0XXns89XhxbpJbkJtZdhLk eO+9cofHDG52MNm+w1mv74p9BZQgUEZtDvdZWo76JtOL1skm/E/ERO24Bem19jYV MdBplXftiWOs/rO0+Er00nsM/3wyjpWeO2+I4Z0Im7lAIB0bysxu8geoONBCyjoJ RaL+IqSAPUE44SnzlL+6nsOSAPMZkNK6CRvNhs5eUcjjc16e4wD9H/sl2IBfsEo= =EFgP -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 19 13:32, LRN wrote: On 19.06.2013 12:57, Corinna Vinschen wrote: On Jun 19 12:08, LRN wrote: To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance. On Cygwin? Not that I'm aware of. I tested the AC_PROG_LN_S macro on Cygwin and the LN_S setting is 'ls -s' afterwards. That's with autoconf-2.69. My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S. _AS_LN_S_PREPARE also yields `ln -s' on Cygwin. Just tested. What about leaving the symlink(2) function alone and rather just replace the ln(1) tool with a wrapper which calls cp(1) in case of the -s option instead, some ln.orig.exe otherwise? No idea. Any proposal will have to be tested first. Alexey just gave me a new snapshot, i'll test nativestrict there, and then we'll see. Btw., I've created a snapshot immediately after I had applied my patch. If you're not chilled by a Cygwin install, you can test this stuff quicker. The 32 bit developer snapshots are on http://cygwin.com/snapshots, the 64 bit test version can be installed via ftp://cygwin.com/pub/cygwin/64bit/setup64.exe HTH, Corinna -- 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 19.06.2013 13:55, Corinna Vinschen wrote: On Jun 19 13:32, LRN wrote: On 19.06.2013 12:57, Corinna Vinschen wrote: On Jun 19 12:08, LRN wrote: To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance. On Cygwin? Not that I'm aware of. I tested the AC_PROG_LN_S macro on Cygwin and the LN_S setting is 'ls -s' afterwards. That's with autoconf-2.69. My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S. _AS_LN_S_PREPARE also yields `ln -s' on Cygwin. Just tested. It shouldn't. Probably. I think. It (is/should be) impossible to create an NTFS symlink to non-existing target in Cygwin or MSys (since the target must exist to be able to create an link of the right type). Are you sure that your _AS_LN_S_PREPARE does this: # _AS_LN_S_PREPARE # # Don't use conftest.sym to avoid file name issues on DJGPP, where this # would yield conftest.sym.exe for DJGPP 2.04. And don't use `conftest' # as base name to avoid prohibiting concurrency (e.g., concurrent # config.statuses). On read-only media, assume 'cp -pR' and hope we # are just running --help anyway. m4_defun([_AS_LN_S_PREPARE], [rm -f conf$$ conf$$.exe conf$$.file if test -d conf$$.dir; then rm -f conf$$.dir/conf$$.file else rm -f conf$$.dir mkdir conf$$.dir 2/dev/null fi if (echo conf$$.file) 2/dev/null; then if ln -s conf$$.file conf$$ 2/dev/null; then as_ln_s='ln -s' # ... but there are two gotchas: # 1) On MSYS, both `ln -s file dir' and `ln file dir' fail. # 2) DJGPP 2.04 has no symlinks; `ln -s' creates a wrapper executable. # In both cases, we have to default to `cp -pR'. ln -s conf$$.file conf$$.dir 2/dev/null test ! -f conf$$.exe || as_ln_s='cp -pR' elif ln conf$$.file conf$$ 2/dev/null; then as_ln_s=ln else as_ln_s='cp -pR' fi else as_ln_s='cp -pR' fi rm -f conf$$ conf$$.exe conf$$.dir/conf$$.file conf$$.file rmdir conf$$.dir 2/dev/null ])# _AS_LN_S_PREPARE and that you're using winsymlinks:nativestrict? Otherwise it's difficult for me to imagine how it would work for you. Note that here it tries to create a symlink that points to itself. I know, because i've tried on my Debian machine. What about leaving the symlink(2) function alone and rather just replace the ln(1) tool with a wrapper which calls cp(1) in case of the -s option instead, some ln.orig.exe otherwise? No idea. Any proposal will have to be tested first. Alexey just gave me a new snapshot, i'll test nativestrict there, and then we'll see. Btw., I've created a snapshot immediately after I had applied my patch. If you're not chilled by a Cygwin install, you can test this stuff quicker. The mere thought of installing Cygwin on my machine sends shivers through my spine. I'll keep using MSYS2 for now. Maybe later, when i gather enough courage...After all, someone will have to check if there's any performance gain in using MSys over cross-compiling from Cygwin. P.S. Hopefully, mingw-w64 users are not annoyed by our slightly off-topic discussion. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRwYeuAAoJEOs4Jb6SI2Cwqz0H/0iIQP5XwA/1PPrac63sqrRa LQvOUE7l0XILQhgUWxEus4I3tOd8NS6V1Qi4j24p8wxo1ZY8R3GlMll6FzL9WW5o ZvSAq3p3TyFcnwRxmhob6QOKc571dJiMtVhHZthHqRWZ6McF04NsF0nGlDmUqyi8 5Vwv7X5gFb/v6/3+ajnS0Wa+TbfoLJJguFoe1uaYSbujFq/MN8JRYXNr396yXeUL xJnTu3tGHNs3pslkmNjwDbMyBsMr1ckRKAi/sbqiHdVZ1pDCSsWqKfo221Pv4wm1 Ysg/T+UZHNT60kRHqa/8UQ0S1BbIxvNsC0CfNQ+/qb2phYaJE/IDiCXmoVNdsos= =hQNL -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 19 14:28, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.06.2013 13:55, Corinna Vinschen wrote: On Jun 19 13:32, LRN wrote: On 19.06.2013 12:57, Corinna Vinschen wrote: On Jun 19 12:08, LRN wrote: To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance. On Cygwin? Not that I'm aware of. I tested the AC_PROG_LN_S macro on Cygwin and the LN_S setting is 'ls -s' afterwards. That's with autoconf-2.69. My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S. _AS_LN_S_PREPARE also yields `ln -s' on Cygwin. Just tested. It shouldn't. Probably. I think. It (is/should be) impossible to create an NTFS symlink to non-existing target in Cygwin or MSys (since the target must exist to be able to create an link of the right type). Are you sure that your _AS_LN_S_PREPARE does this: yes. [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. Btw., I've created a snapshot immediately after I had applied my patch. If you're not chilled by a Cygwin install, you can test this stuff quicker. The mere thought of installing Cygwin on my machine sends shivers through my spine. I'll keep using MSYS2 for now. Maybe later, when i gather enough courage... :) Corinna -- 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 19 12:34, Corinna Vinschen wrote: On Jun 19 14:28, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.06.2013 13:55, Corinna Vinschen wrote: On Jun 19 13:32, LRN wrote: On 19.06.2013 12:57, Corinna Vinschen wrote: On Jun 19 12:08, LRN wrote: To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance. On Cygwin? Not that I'm aware of. I tested the AC_PROG_LN_S macro on Cygwin and the LN_S setting is 'ls -s' afterwards. That's with autoconf-2.69. My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S. _AS_LN_S_PREPARE also yields `ln -s' on Cygwin. Just tested. It shouldn't. Probably. I think. It (is/should be) impossible to create an NTFS symlink to non-existing target in Cygwin or MSys (since the target must exist to be able to create an link of the right type). Are you sure that your _AS_LN_S_PREPARE does this: yes. [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. As a sidenote: What's really sad is the fact that a native symlink contains the information if the target is a file or directory, and worse, that non-Cygwin tools fail if the file/directory information in the symlink is wrong. That alone disallows to create native symlinks to non-existing targets, since you never know whether the target will be file or dir. I'm totally baffled how a simple functionality like creating symlinks can be so screwed up, with no hope in sight. Corinna -- 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)
2013/6/19 Corinna Vinschen vinsc...@redhat.com On Jun 19 12:34, Corinna Vinschen wrote: On Jun 19 14:28, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.06.2013 13:55, Corinna Vinschen wrote: On Jun 19 13:32, LRN wrote: On 19.06.2013 12:57, Corinna Vinschen wrote: On Jun 19 12:08, LRN wrote: To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance. On Cygwin? Not that I'm aware of. I tested the AC_PROG_LN_S macro on Cygwin and the LN_S setting is 'ls -s' afterwards. That's with autoconf-2.69. My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S. _AS_LN_S_PREPARE also yields `ln -s' on Cygwin. Just tested. It shouldn't. Probably. I think. It (is/should be) impossible to create an NTFS symlink to non-existing target in Cygwin or MSys (since the target must exist to be able to create an link of the right type). Are you sure that your _AS_LN_S_PREPARE does this: yes. [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. As a sidenote: What's really sad is the fact that a native symlink contains the information if the target is a file or directory, and worse, that non-Cygwin tools fail if the file/directory information in the symlink is wrong. That alone disallows to create native symlinks to non-existing targets, since you never know whether the target will be file or dir. I'm totally baffled how a simple functionality like creating symlinks can be so screwed up, with no hope in sight. I'm sorry, but all documentation I can find about NTFS reparse points and softlinks etc. say explicitely that you can create a softlink to a nonexistent file: http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx So either something is XP specific and not clearly showing on MSDN, or I'm misunderstanding the problem. Ruben Corinna -- 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 -- 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 19.06.2013 15:54, Ruben Van Boxem wrote: 2013/6/19 Corinna Vinschen vinsc...@redhat.com On Jun 19 12:34, Corinna Vinschen wrote: On Jun 19 14:28, LRN wrote: [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. As a sidenote: What's really sad is the fact that a native symlink contains the information if the target is a file or directory, and worse, that non-Cygwin tools fail if the file/directory information in the symlink is wrong. That alone disallows to create native symlinks to non-existing targets, since you never know whether the target will be file or dir. I'm totally baffled how a simple functionality like creating symlinks can be so screwed up, with no hope in sight. I'm sorry, but all documentation I can find about NTFS reparse points and softlinks etc. say explicitely that you can create a softlink to a nonexistent file: http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx So either something is XP specific and not clearly showing on MSDN, or I'm misunderstanding the problem. A file link to non-existing file - yes (mklink). A directory link to non-existing directory - yes (mklink /D). An untyped link to non-existing filesystem object - no, because NTFS doesn't support untyped symlinks. Cygwin emulates untyped linking (ln -s) by checking the type of the target and creating the link of the right type. If the target doesn't exist, you're screwed. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRwZ2TAAoJEOs4Jb6SI2Cw0wkH/RKnvQvxdw+CPt0Fxc5RXhFj ENOLaPOAvroTSPHaQPLozmjE/6pyqluQE48Z0qRpB2/hIEu/a1NbulZ3hfMXo9ke 6o+W7vEzqyRup/hxa97rETp7ThryTlaRr4/qbZ4PaccXAiEVge4SuOowQ454RgLj 4CdMsr5L/n4T2Bh8M6hkvy6O9a4yNUB4QNsDIgDpP5MPXMa3azYLCeId5OgaKwpZ ZQUSHEAcxp8K5db+wU8RBJDe3zJ0YdQwWasbGY3BLVCDqevWRXn6yRAbmeGbPO4Y /1ZL6wOq0v9BR8TLk99ZTex0LiOGXrWiHXAE9P8Q+KQ+zFwBJd7k9MEr5YIsURY= =NNHe -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)
2013/6/19 LRN lrn1...@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.06.2013 15:54, Ruben Van Boxem wrote: 2013/6/19 Corinna Vinschen vinsc...@redhat.com On Jun 19 12:34, Corinna Vinschen wrote: On Jun 19 14:28, LRN wrote: [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. As a sidenote: What's really sad is the fact that a native symlink contains the information if the target is a file or directory, and worse, that non-Cygwin tools fail if the file/directory information in the symlink is wrong. That alone disallows to create native symlinks to non-existing targets, since you never know whether the target will be file or dir. I'm totally baffled how a simple functionality like creating symlinks can be so screwed up, with no hope in sight. I'm sorry, but all documentation I can find about NTFS reparse points and softlinks etc. say explicitely that you can create a softlink to a nonexistent file: http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx So either something is XP specific and not clearly showing on MSDN, or I'm misunderstanding the problem. A file link to non-existing file - yes (mklink). A directory link to non-existing directory - yes (mklink /D). An untyped link to non-existing filesystem object - no, because NTFS doesn't support untyped symlinks. Cygwin emulates untyped linking (ln -s) by checking the type of the target and creating the link of the right type. If the target doesn't exist, you're screwed. Call me naive, but why not create the link to non-existent ... thing (which should possible, just choose file or directory; it doesn't matter because its not there)... then when the actual thing is created, change the link to conform to the new filesystem state? You can keep track as the symlink info is contained in the information retrieved by GetFileAttributesEx. This setup might require bookkeeping though, not entirely well-versed in this stuff. Ruben - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRwZ2TAAoJEOs4Jb6SI2Cw0wkH/RKnvQvxdw+CPt0Fxc5RXhFj ENOLaPOAvroTSPHaQPLozmjE/6pyqluQE48Z0qRpB2/hIEu/a1NbulZ3hfMXo9ke 6o+W7vEzqyRup/hxa97rETp7ThryTlaRr4/qbZ4PaccXAiEVge4SuOowQ454RgLj 4CdMsr5L/n4T2Bh8M6hkvy6O9a4yNUB4QNsDIgDpP5MPXMa3azYLCeId5OgaKwpZ ZQUSHEAcxp8K5db+wU8RBJDe3zJ0YdQwWasbGY3BLVCDqevWRXn6yRAbmeGbPO4Y /1ZL6wOq0v9BR8TLk99ZTex0LiOGXrWiHXAE9P8Q+KQ+zFwBJd7k9MEr5YIsURY= =NNHe -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 -- 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 19.06.2013 16:11, Ruben Van Boxem wrote: 2013/6/19 LRN lrn1...@gmail.com On 19.06.2013 15:54, Ruben Van Boxem wrote: 2013/6/19 Corinna Vinschen vinsc...@redhat.com On Jun 19 12:34, Corinna Vinschen wrote: On Jun 19 14:28, LRN wrote: [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. As a sidenote: What's really sad is the fact that a native symlink contains the information if the target is a file or directory, and worse, that non-Cygwin tools fail if the file/directory information in the symlink is wrong. That alone disallows to create native symlinks to non-existing targets, since you never know whether the target will be file or dir. I'm totally baffled how a simple functionality like creating symlinks can be so screwed up, with no hope in sight. I'm sorry, but all documentation I can find about NTFS reparse points and softlinks etc. say explicitely that you can create a softlink to a nonexistent file: http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx So either something is XP specific and not clearly showing on MSDN, or I'm misunderstanding the problem. A file link to non-existing file - yes (mklink). A directory link to non-existing directory - yes (mklink /D). An untyped link to non-existing filesystem object - no, because NTFS doesn't support untyped symlinks. Cygwin emulates untyped linking (ln -s) by checking the type of the target and creating the link of the right type. If the target doesn't exist, you're screwed. Call me naive, but why not create the link to non-existent ... thing (which should possible, just choose file or directory; it doesn't matter because its not there)... then when the actual thing is created, change the link to conform to the new filesystem state? You can keep track as the symlink info is contained in the information retrieved by GetFileAttributesEx. This setup might require bookkeeping though, not entirely well-versed in this stuff. Ruben I was thinking along the same lines some minute ago. Sadly, that isn't really an option for me, since i need this to work for W32 apps, and they don't have access that bookkeeping code. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRwaItAAoJEOs4Jb6SI2CwycAIAOCBYUCPLcKnD2ZW3tLfRlFQ 0wV84vBcFtkKuhY++zmdKQXKEWjxfXyerkgU9N92GvGR8lyVNaLF/uvV5IoMhcJR er9oG+L0UAIYTvxveAcbRhiODii21Jsahw3LK+hIjc3+IBBCfGTbMGNbnOVuRm5u bpUMWzF/vcTAyT0oh8vixWURAGzg63bDE8X2kKoHVbp4akzLRvdlJ17MmL+y+zQi LNBjpS1B4B1IzUFPXpC/ipi2SU+Avv8srGFWogufG3HrVqiuyH2oaPICZCktl23j XfJ7nvVTrzc0P0/9MoKk4lojdGm6NXMzOxcC59IRNJunt2/kG+eQdH01NKc8pmg= =GwQF -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 19 16:01, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.06.2013 15:54, Ruben Van Boxem wrote: 2013/6/19 Corinna Vinschen vinsc...@redhat.com On Jun 19 12:34, Corinna Vinschen wrote: On Jun 19 14:28, LRN wrote: [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. As a sidenote: What's really sad is the fact that a native symlink contains the information if the target is a file or directory, and worse, that non-Cygwin tools fail if the file/directory information in the symlink is wrong. That alone disallows to create native symlinks to non-existing targets, since you never know whether the target will be file or dir. I'm totally baffled how a simple functionality like creating symlinks can be so screwed up, with no hope in sight. I'm sorry, but all documentation I can find about NTFS reparse points and softlinks etc. say explicitely that you can create a softlink to a nonexistent file: http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx So either something is XP specific and not clearly showing on MSDN, or I'm misunderstanding the problem. A file link to non-existing file - yes (mklink). A directory link to non-existing directory - yes (mklink /D). An untyped link to non-existing filesystem object - no, because NTFS doesn't support untyped symlinks. Cygwin emulates untyped linking (ln -s) by checking the type of the target and creating the link of the right type. If the target doesn't exist, you're screwed. Not really screwed. But if the target doesn't exist, you have the choice between creating a file symlink or a directory symlink, and you just don't know what the target will be. If you create a dir symlink, and the later created target turns out to be a file or vice versa, the *native* tools will be screwed since the path resolution mechanism requires the symlink type to reflect the target type. Cygwin ignores the symlink type and resolve the symlink just by path, so in Cygwin all symlinks will work. Corinna -- 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 6/19/2013 20:11, Ruben Van Boxem wrote: Call me naive, but why not create the link to non-existent ... thing (which should possible, just choose file or directory; it doesn't matter because its not there)... then when the actual thing is created, change the link to conform to the new filesystem state? So how exactly do you find out where the symlink that needs correction was written to? What if the app create a symlink and then check if the target exists before doing something? You can keep track as the symlink info is contained in the information retrieved by GetFileAttributesEx. This setup might require bookkeeping though, not entirely well-versed in this stuff. NTFS streams in directory metadata? signature.asc Description: OpenPGP digital 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 19 14:11, Ruben Van Boxem wrote: 2013/6/19 LRN lrn1...@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.06.2013 15:54, Ruben Van Boxem wrote: 2013/6/19 Corinna Vinschen vinsc...@redhat.com On Jun 19 12:34, Corinna Vinschen wrote: On Jun 19 14:28, LRN wrote: [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. As a sidenote: What's really sad is the fact that a native symlink contains the information if the target is a file or directory, and worse, that non-Cygwin tools fail if the file/directory information in the symlink is wrong. That alone disallows to create native symlinks to non-existing targets, since you never know whether the target will be file or dir. I'm totally baffled how a simple functionality like creating symlinks can be so screwed up, with no hope in sight. I'm sorry, but all documentation I can find about NTFS reparse points and softlinks etc. say explicitely that you can create a softlink to a nonexistent file: http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx So either something is XP specific and not clearly showing on MSDN, or I'm misunderstanding the problem. A file link to non-existing file - yes (mklink). A directory link to non-existing directory - yes (mklink /D). An untyped link to non-existing filesystem object - no, because NTFS doesn't support untyped symlinks. Cygwin emulates untyped linking (ln -s) by checking the type of the target and creating the link of the right type. If the target doesn't exist, you're screwed. Call me naive, but why not create the link to non-existent ... thing (which should possible, just choose file or directory; it doesn't matter because its not there)... then when the actual thing is created, change the link to conform to the new filesystem state? The POSIX calls are stateless. When the target of a symlink gets created, you don't even know if a symlink to the target has been created at all, let alone by the same process. You can keep track as the symlink info is contained in the information retrieved by GetFileAttributesEx. Not really. With GetFileAttributesEx you only get the fact if a file is a reparse point or not. If it's a symlink requires further checking. Even with the underlying native NtQueryInformationFile you can get all the hardlinks pointing to the same file (same file ID), but not all symlinks pointing to a file. This setup might require bookkeeping though, not entirely well-versed in this stuff. This kind of bookkeeping opens a can of worms. In theory you'd have to maintain a shared memory region of potentially indefinite size to keep track of dangling symlinks in calls to symlink(2). To utilize this shared mem region, *all* Cygwin processes calling open(2) or mkdir(2) would have to check if the path to the new file or directory is in the shared list of dangling symlinks and, if so, call a helper function which recreates the symlink with the correct type and remove the dangling symlink from the list. One problem here is the fact, that the shared memory region is only maintained as long as at least one Cygwin process is still running since shared mem regions disappear when the last handle to them is closed. If you start Cygwin tools from CMD like this C:\ C:\cygwin\bin\ln -s foo bar C:\ C:\cygwin\bin\mkdir bar then there's no Cygwin process running between the lifetime of ln and mkdir. So the shared mem region doesn't exist anymore when mkdir is called and the whole excerise is moot. And there's another problem with this approach. Unfortunately you can't overwrite symlinks atomically. You have to remove the old symlink and create a new one. In the time between removing and recreation, another process could have made a wrong decision based on the non-existence of the symlink. You could eliminate this problem by deleting and recreating the symlink in an NTFS transaction, but very, very unfortunately Microsoft has announced to drop NTFS transactions from future versions of NTFS(*). Corinna (*) This a an extrem pity, because transactions are necessary in some scenarios to overcome non-POSIXy behaviour of some system calls. -- 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 19 14:36, Corinna Vinschen wrote: On Jun 19 16:01, LRN wrote: Cygwin emulates untyped linking (ln -s) by checking the type of the target and creating the link of the right type. If the target doesn't exist, you're screwed. Not really screwed. But if the target doesn't exist, you have the choice between creating a file symlink or a directory symlink, and you just don't know what the target will be. If you create a dir symlink, and the later created target turns out to be a file or vice versa, the *native* tools will be screwed since the path resolution mechanism requires the symlink type to reflect the target type. Cygwin ignores the symlink type and resolve the symlink just by path, so in Cygwin all symlinks will work. Btw., this is one reason why I don't understand the desire to use native tools. If you can get a working POSIXy build environment for free, why do you want to use native tools which only generate problems you could easily do without weird tweaks to the Cygwin DLL?!? Corinna -- 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)
Usually it's because Cygwin is usually a lot slower than native for IO heavy operations. Projects (such as the Android NDK) that supply Cygwin-based compilers usually try to migrate to native ASAP, viewing the Cygwin-based tools as a stop-gap measure. On Wed, Jun 19, 2013 at 2:05 PM, Corinna Vinschen vinsc...@redhat.comwrote: On Jun 19 14:36, Corinna Vinschen wrote: On Jun 19 16:01, LRN wrote: Cygwin emulates untyped linking (ln -s) by checking the type of the target and creating the link of the right type. If the target doesn't exist, you're screwed. Not really screwed. But if the target doesn't exist, you have the choice between creating a file symlink or a directory symlink, and you just don't know what the target will be. If you create a dir symlink, and the later created target turns out to be a file or vice versa, the *native* tools will be screwed since the path resolution mechanism requires the symlink type to reflect the target type. Cygwin ignores the symlink type and resolve the symlink just by path, so in Cygwin all symlinks will work. Btw., this is one reason why I don't understand the desire to use native tools. If you can get a working POSIXy build environment for free, why do you want to use native tools which only generate problems you could easily do without weird tweaks to the Cygwin DLL?!? Corinna -- 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 -- 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 19 14:14, Ray Donnelly wrote: On Wed, Jun 19, 2013 at 2:05 PM, Corinna Vinschen wrote: Btw., this is one reason why I don't understand the desire to use native tools. If you can get a working POSIXy build environment for free, why do you want to use native tools which only generate problems you could easily do without weird tweaks to the Cygwin DLL?!? Usually it's because Cygwin is usually a lot slower than native for IO heavy operations. Projects (such as the Android NDK) that supply Cygwin-based compilers usually try to migrate to native ASAP, viewing the Cygwin-based tools as a stop-gap measure. Yeah. There's nothing we can do about that if we want to maintain POSIX compatibility as much as possible. SFU suffered from the same problem and they had at least the advantage of being able to use a native fork. Corinna -- 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)
2013/6/19 Corinna Vinschen vinsc...@redhat.com On Jun 19 14:11, Ruben Van Boxem wrote: 2013/6/19 LRN lrn1...@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.06.2013 15:54, Ruben Van Boxem wrote: 2013/6/19 Corinna Vinschen vinsc...@redhat.com On Jun 19 12:34, Corinna Vinschen wrote: On Jun 19 14:28, LRN wrote: [...] and that you're using winsymlinks:nativestrict? No. I'm using any one of the other variations of symlinks. nativestrict was a compromise with my fellow co-maintainer. The default symlinks and winsymlinks:lnk always work, winsymlinks:native falls back to the default symlinks if creating the native symlink doesn't work. winsymlinks:nativestrict is a special case, not the norm. As a sidenote: What's really sad is the fact that a native symlink contains the information if the target is a file or directory, and worse, that non-Cygwin tools fail if the file/directory information in the symlink is wrong. That alone disallows to create native symlinks to non-existing targets, since you never know whether the target will be file or dir. I'm totally baffled how a simple functionality like creating symlinks can be so screwed up, with no hope in sight. I'm sorry, but all documentation I can find about NTFS reparse points and softlinks etc. say explicitely that you can create a softlink to a nonexistent file: http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx So either something is XP specific and not clearly showing on MSDN, or I'm misunderstanding the problem. A file link to non-existing file - yes (mklink). A directory link to non-existing directory - yes (mklink /D). An untyped link to non-existing filesystem object - no, because NTFS doesn't support untyped symlinks. Cygwin emulates untyped linking (ln -s) by checking the type of the target and creating the link of the right type. If the target doesn't exist, you're screwed. Call me naive, but why not create the link to non-existent ... thing (which should possible, just choose file or directory; it doesn't matter because its not there)... then when the actual thing is created, change the link to conform to the new filesystem state? The POSIX calls are stateless. When the target of a symlink gets created, you don't even know if a symlink to the target has been created at all, let alone by the same process. You can keep track as the symlink info is contained in the information retrieved by GetFileAttributesEx. Not really. With GetFileAttributesEx you only get the fact if a file is a reparse point or not. If it's a symlink requires further checking. Even with the underlying native NtQueryInformationFile you can get all the hardlinks pointing to the same file (same file ID), but not all symlinks pointing to a file. This setup might require bookkeeping though, not entirely well-versed in this stuff. This kind of bookkeeping opens a can of worms. In theory you'd have to maintain a shared memory region of potentially indefinite size to keep track of dangling symlinks in calls to symlink(2). To utilize this shared mem region, *all* Cygwin processes calling open(2) or mkdir(2) would have to check if the path to the new file or directory is in the shared list of dangling symlinks and, if so, call a helper function which recreates the symlink with the correct type and remove the dangling symlink from the list. One problem here is the fact, that the shared memory region is only maintained as long as at least one Cygwin process is still running since shared mem regions disappear when the last handle to them is closed. If you start Cygwin tools from CMD like this C:\ C:\cygwin\bin\ln -s foo bar C:\ C:\cygwin\bin\mkdir bar then there's no Cygwin process running between the lifetime of ln and mkdir. So the shared mem region doesn't exist anymore when mkdir is called and the whole excerise is moot. And there's another problem with this approach. Unfortunately you can't overwrite symlinks atomically. You have to remove the old symlink and create a new one. In the time between removing and recreation, another process could have made a wrong decision based on the non-existence of the symlink. You could eliminate this problem by deleting and recreating the symlink in an NTFS transaction, but very, very unfortunately Microsoft has announced to drop NTFS transactions from future versions of NTFS(*). Thanks for all the details. The interop between Windows and POSIX APIs has always interested me somewhere deep down, and I too found Cygwin coming short (no offense, I'm sure it was my fault and I wasn't patient enough or had some wrong assumption). An alternative to TxF is doing that in Kernel mode directly of course:
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 19 15:27, Ruben Van Boxem wrote: 2013/6/19 Corinna Vinschen And there's another problem with this approach. Unfortunately you can't overwrite symlinks atomically. You have to remove the old symlink and create a new one. In the time between removing and recreation, another process could have made a wrong decision based on the non-existence of the symlink. You could eliminate this problem by deleting and recreating the symlink in an NTFS transaction, but very, very unfortunately Microsoft has announced to drop NTFS transactions from future versions of NTFS(*). [...] An alternative to TxF is doing that in Kernel mode directly of course: http://msdn.microsoft.com/en-us/library/windows/hardware/ff565748%28v=vs.85%29.aspx Cygwin already uses the native NT calls as described in this document. Many of them are usable from user space without having to create a kernel driver, see http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc?rev=1.648content-type=text/x-cvsweb-markupcvsroot=src functions start_transaction() and stop_transaction(). However, if future NTFS versions stop supporting transactions, even using the native NT calls will be useless since the filesystem flags will have the FILE_SUPPORTS_TRANSACTIONS flag unset (as on ReFS, for instance). Corinna -- 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 19 15:24, Corinna Vinschen wrote: On Jun 19 14:14, Ray Donnelly wrote: On Wed, Jun 19, 2013 at 2:05 PM, Corinna Vinschen wrote: Btw., this is one reason why I don't understand the desire to use native tools. If you can get a working POSIXy build environment for free, why do you want to use native tools which only generate problems you could easily do without weird tweaks to the Cygwin DLL?!? Usually it's because Cygwin is usually a lot slower than native for IO heavy operations. Projects (such as the Android NDK) that supply Cygwin-based compilers usually try to migrate to native ASAP, viewing the Cygwin-based tools as a stop-gap measure. Yeah. There's nothing we can do about that if we want to maintain POSIX compatibility as much as possible. SFU suffered from the same problem and they had at least the advantage of being able to use a native fork. OTOH, Cygwin got faster over the last year or so, and the 64 bit version will be another bit faster. There's always room for development. Corinna -- 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)
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
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] 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
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 10 13:19, Алексей Павлов wrote: Corinna, I upload 3rdparty sources that I use in MSYS2 to https://sourceforge.net/projects/msys2/files/Sources/ Thank you. Corinna -- 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)
Hi Алексей, On Jun 10 10:19, Corinna Vinschen wrote: On Jun 8 12:49, Алексей Павлов wrote: I recreate git repository on msys2.sf.net. Now master branch point to MSYS2 source and when you go to code page on sf.net you get page with MSYS2 source. Thank you, that's much better. This allows an unaware user to access the correct sources immediately. I noticed that you changed the file information resource in winver.rc: VALUE CompanyName, SourceForge.Net VALUE FileDescription, MSYS\256 POSIX Emulation DLL VALUE FileVersion, STRINGIFY(CYGWIN_VERSION) VALUE InternalName, CYGWIN_DLL_NAME VALUE LegalCopyright, Copyright \251 - see the file MSYS_COPYRIGHT Two questions: - CompanyName SourceForge.Net makes me cringe, since that looks as if SourceForge is the company behind that project. Fortunately the CompanyName value is not printed in the file properties dialog anymore since Vista, but still... would you mind to change that to MSYS or something? - LegalCopyright refers to a file called MSYS_COPYRIGHT, but there's no such file in the source package, nor in the binary package. May I asked to add this file? And a suggestion: - FileDescription contains an (R), Registered Trademark. Is MSYS actually a registered trademark? If not, I would suggest to remove this because it can have negative effects in some legislations. Thanks, Corinna -- 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)
2013/6/11 Corinna Vinschen vinsc...@redhat.com Hi Алексей, On Jun 10 10:19, Corinna Vinschen wrote: On Jun 8 12:49, Алексей Павлов wrote: I recreate git repository on msys2.sf.net. Now master branch point to MSYS2 source and when you go to code page on sf.net you get page with MSYS2 source. Thank you, that's much better. This allows an unaware user to access the correct sources immediately. I noticed that you changed the file information resource in winver.rc: VALUE CompanyName, SourceForge.Net VALUE FileDescription, MSYS\256 POSIX Emulation DLL VALUE FileVersion, STRINGIFY(CYGWIN_VERSION) VALUE InternalName, CYGWIN_DLL_NAME VALUE LegalCopyright, Copyright \251 - see the file MSYS_COPYRIGHT Two questions: - CompanyName SourceForge.Net makes me cringe, since that looks as if SourceForge is the company behind that project. Fortunately the CompanyName value is not printed in the file properties dialog anymore since Vista, but still... would you mind to change that to MSYS or something? - LegalCopyright refers to a file called MSYS_COPYRIGHT, but there's no such file in the source package, nor in the binary package. May I asked to add this file? And a suggestion: - FileDescription contains an (R), Registered Trademark. Is MSYS actually a registered trademark? If not, I would suggest to remove this because it can have negative effects in some legislations. Thanks, Corinna -- 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 Yes this is my mistake it came from old MSYS dll. I fix it today. 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)
Hi Алексей,
On Jun 8 01:56, Алексей Павлов wrote:
2013/6/7 Corinna Vinschen wrote:
A final note: I'm not opposing the fork. Under the GPL it's your
perfect right to do so, as long as you adhere to the license
requirements. But that doesn't mean I have to understand it. If the
DLL and the tools are exactly the same and only differ by name, then,
what's the point? Wouldn't it make more sense to work with us on the
Cygwin project instead?
Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64
IRC. It would be more right way I think but I think you don't interesting
in it. I'm right? That is why I create fork of Cygwin. But if it possible
to support MSYS2 mode in Cygwin sources I think all be happy to not create
many forks an so on.
The problem is this. So far I'm wondering what MSYS2 is about. It
doesn't add any useful functionality over Cygwin. And if so, why not
integrate it into Cygwin instead and only have one project for
everybody? JonY already maintains the mingw-w64 32 and 64 bit cross
toolchains as part of the Cygwin distro, so there's nothing missing for
those who want to create native applications.
Forking makes sense in some scenarios, especially if there's a big rift
between the development targets of the developers, or licensing
problems. But for a start, I don't see this here, unless I'm missing
something.
Granted, right now MSYS2 adds code which is entirely unacceptable for
Cygwin. For instance the symlink(2) function *copying* files, even
recursively if the target is a directory. I don't grok the reason for
this.
So here's a user or script innocently calling
ln -s /cygdrive/c/Windows /
which is something I do often to have easier access to the Windows
directory for certain tasks. But I definitely don't want a copy of the
Windows directory. If it's about compatibility with native tools, the
change still doesn't makes sense.
- Either it's Cygwin/MSYS2 tools needing the symlink, then a Cygwin
symlinks works fine,
- or you need a copy of a certain subtree, then you should have called
cp, rather than ln -s,
- or you need a Windows symlink, then you should have created a
native symlink using the new Cygwin capability to create native
symlinks using the CYGWIN=winsymlinks:native{strict} setting.
The latter would be much more feasible as default setting, while on old
pre-Vista systems, it would be much more feasible to fail gracefully, or
to use Cygwin's method to create a Windows .lnk file instead.
emotional mode
Other than that I'm rather puzzled as to what MSYS2 is about, other than
to duplicate developer efforts and to split communities. Apart from
your perfect right to fork, you might nevertheless understand that I'm a
bit annoyed. Especially given the code base. Me and Kai were working
hard for months to create a 64 bit version of Cygwin, and while our
Cygwin 64 bit distro is still in test mode, you simply rip off the code
and just release your own MSYS2 distro from there.
I can't help to feel exploited.
/emotional mode
Back to the technical stuff. Again, I don't understand the reason for
the fork, please explain. What is it, codewise, you really miss in
Cygwin? What non-code problems is MSYS2 trying to fix?
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 11 13:26, Corinna Vinschen wrote: Other than that I'm rather puzzled as to what MSYS2 is about, other than to duplicate developer efforts and to split communities. Apart from your perfect right to fork, you might nevertheless understand that I'm a bit annoyed. Especially given the code base. Me and Kai were working hard for months to create a 64 bit version of Cygwin, [...] ...and don't forget all the other people who helped to find and fix porting bugs in the 64 bit Cygwin version, the maintainers who helped building the 64 bit test distro and who are sending patches upstream, etc. 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)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11.06.2013 15:26, Corinna Vinschen wrote:
Hi Алексей,
On Jun 8 01:56, Алексей Павлов wrote:
2013/6/7 Corinna Vinschen wrote:
A final note: I'm not opposing the fork. Under the GPL it's your
perfect right to do so, as long as you adhere to the license
requirements. But that doesn't mean I have to understand it. If the
DLL and the tools are exactly the same and only differ by name, then,
what's the point? Wouldn't it make more sense to work with us on the
Cygwin project instead?
Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64
IRC. It would be more right way I think but I think you don't interesting
in it. I'm right? That is why I create fork of Cygwin. But if it possible
to support MSYS2 mode in Cygwin sources I think all be happy to not create
many forks an so on.
The problem is this. So far I'm wondering what MSYS2 is about.
MSYS is about mixing W32 tools (mingw-gcc, binutils) headers and
libraries with *nixy (or cygwinny, if you prefer) buildtools and
scripts, with the aim of building W32 libraries and applications.
In Cygwin (or when running a real GNU system) you have to use a
cross-compiler to build W32 binaries.
In MSYS you don't have to. That's it.
Granted, right now MSYS2 adds code which is entirely unacceptable for
Cygwin. For instance the symlink(2) function *copying* files, even
recursively if the target is a directory. I don't grok the reason for
this.
So here's a user or script innocently calling
ln -s /cygdrive/c/Windows /
which is something I do often to have easier access to the Windows
directory for certain tasks. But I definitely don't want a copy of the
Windows directory. If it's about compatibility with native tools, the
change still doesn't makes sense.
- Either it's Cygwin/MSYS2 tools needing the symlink, then a Cygwin
symlinks works fine,
- or you need a copy of a certain subtree, then you should have called
cp, rather than ln -s,
- or you need a Windows symlink, then you should have created a
native symlink using the new Cygwin capability to create native
symlinks using the CYGWIN=winsymlinks:native{strict} setting.
The latter would be much more feasible as default setting, while on old
pre-Vista systems, it would be much more feasible to fail gracefully, or
to use Cygwin's method to create a Windows .lnk file instead.
Now that you know what MSYS is about, it should be obvious that crude
symlink-by-copying is necessary to satisfy W32 tools, which cannot use
cygwin symlinks or Windows .lnk files.
Windows symlinks (when using NT 6 and newer) are fine (well, they are
not POSIXly, but they may turn out to be better than dumb copying (for
the purpose of using them when building software), i'll try to test that
later), MSYS1 had no way of creating them, and thus this was not an
option. Now it is an option, and maybe a good default too.
- --
O ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJRtw15AAoJEOs4Jb6SI2CwJbMIALMwC7zDIHRjRpKlFX/Zuk6k
kt6s1/mstnSK6+WJdN5H2BxO2bXfxSBZDSiiwLXxe0UmTkdqFejQoO0JXiUiGwdM
ne8KBy4EAdL4hxiEfhyiJhmAdZoEXktJMrlCX5AdFP22EueSc97D1hy12zM8EiMr
rPHVe/0hL5sJ2Yk9LE0eAghMwEMIrnicAIWuyi9hpMG9U3IFAUf6GFLkV8ocT3Ga
LO+rDDhuLclwpAIJ7p1FX4BwIgnzbCyYxZ9u8rlRB16cntIaJkzwNuxLmYKRjlra
ZqiZKxayenMQBhiF/Q1OMjOOCBdi4DGoppsDffVgnGvLGA6fQG7ZDcIW5vCZqbI=
=iQw0
-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)
I for one am hugely appreciative of all the hard work that Corinna, Kai,
redhat, the mingw-w64 team and also Alexey has put into both Cygwin and
MSYS2.
Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we
can reasonably do on MSYS2 (credits, thanks printed at each login,
explanations of where MSYS2 comes from and links to Cygwin etc) to make the
fork-pill easier to swallow, I'm sure Alexey will be happy to do (though I
can't speak for him of course!)
MSYS itself was a fork of Cygwin ages ago, and it's really showing its age.
If you accept that there's any value in MSYS, then I hope you can see the
need we in the MSYS using section of the mingw-w64 community have for an
updated versoin. As an example, we can't build Qt with MSYS because MSYS
Perl is at version 5.8.8. MSYS itself was badly fragmented by the msysgit
project which uses an even earlier version of MSYS than the latest one
which is also missing important tools such as install.exe and something
has to be done to improve this situation. Our hope is that MSYS2 can be
adopted by that project and that MSYS never rots as badly as it has done.
If we can get down to a proper technical discussion on what's different and
why, then we can maybe think about some way of working together?
So many thanks everybody for the hard work and dedication.
On Tue, Jun 11, 2013 at 12:43 PM, LRN lrn1...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11.06.2013 15:26, Corinna Vinschen wrote:
Hi Алексей,
On Jun 8 01:56, Алексей Павлов wrote:
2013/6/7 Corinna Vinschen wrote:
A final note: I'm not opposing the fork. Under the GPL it's your
perfect right to do so, as long as you adhere to the license
requirements. But that doesn't mean I have to understand it. If the
DLL and the tools are exactly the same and only differ by name, then,
what's the point? Wouldn't it make more sense to work with us on the
Cygwin project instead?
Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64
IRC. It would be more right way I think but I think you don't
interesting
in it. I'm right? That is why I create fork of Cygwin. But if it
possible
to support MSYS2 mode in Cygwin sources I think all be happy to not
create
many forks an so on.
The problem is this. So far I'm wondering what MSYS2 is about.
MSYS is about mixing W32 tools (mingw-gcc, binutils) headers and
libraries with *nixy (or cygwinny, if you prefer) buildtools and
scripts, with the aim of building W32 libraries and applications.
In Cygwin (or when running a real GNU system) you have to use a
cross-compiler to build W32 binaries.
In MSYS you don't have to. That's it.
Granted, right now MSYS2 adds code which is entirely unacceptable for
Cygwin. For instance the symlink(2) function *copying* files, even
recursively if the target is a directory. I don't grok the reason for
this.
So here's a user or script innocently calling
ln -s /cygdrive/c/Windows /
which is something I do often to have easier access to the Windows
directory for certain tasks. But I definitely don't want a copy of the
Windows directory. If it's about compatibility with native tools, the
change still doesn't makes sense.
- Either it's Cygwin/MSYS2 tools needing the symlink, then a Cygwin
symlinks works fine,
- or you need a copy of a certain subtree, then you should have called
cp, rather than ln -s,
- or you need a Windows symlink, then you should have created a
native symlink using the new Cygwin capability to create native
symlinks using the CYGWIN=winsymlinks:native{strict} setting.
The latter would be much more feasible as default setting, while on old
pre-Vista systems, it would be much more feasible to fail gracefully, or
to use Cygwin's method to create a Windows .lnk file instead.
Now that you know what MSYS is about, it should be obvious that crude
symlink-by-copying is necessary to satisfy W32 tools, which cannot use
cygwin symlinks or Windows .lnk files.
Windows symlinks (when using NT 6 and newer) are fine (well, they are
not POSIXly, but they may turn out to be better than dumb copying (for
the purpose of using them when building software), i'll try to test that
later), MSYS1 had no way of creating them, and thus this was not an
option. Now it is an option, and maybe a good default too.
- --
O ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJRtw15AAoJEOs4Jb6SI2CwJbMIALMwC7zDIHRjRpKlFX/Zuk6k
kt6s1/mstnSK6+WJdN5H2BxO2bXfxSBZDSiiwLXxe0UmTkdqFejQoO0JXiUiGwdM
ne8KBy4EAdL4hxiEfhyiJhmAdZoEXktJMrlCX5AdFP22EueSc97D1hy12zM8EiMr
rPHVe/0hL5sJ2Yk9LE0eAghMwEMIrnicAIWuyi9hpMG9U3IFAUf6GFLkV8ocT3Ga
LO+rDDhuLclwpAIJ7p1FX4BwIgnzbCyYxZ9u8rlRB16cntIaJkzwNuxLmYKRjlra
ZqiZKxayenMQBhiF/Q1OMjOOCBdi4DGoppsDffVgnGvLGA6fQG7ZDcIW5vCZqbI=
=iQw0
-END PGP SIGNATURE-
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 11 15:43, LRN wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11.06.2013 15:26, Corinna Vinschen wrote:
Hi Алексей,
On Jun 8 01:56, Алексей Павлов wrote:
2013/6/7 Corinna Vinschen wrote:
A final note: I'm not opposing the fork. Under the GPL it's your
perfect right to do so, as long as you adhere to the license
requirements. But that doesn't mean I have to understand it. If the
DLL and the tools are exactly the same and only differ by name, then,
what's the point? Wouldn't it make more sense to work with us on the
Cygwin project instead?
Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64
IRC. It would be more right way I think but I think you don't interesting
in it. I'm right? That is why I create fork of Cygwin. But if it possible
to support MSYS2 mode in Cygwin sources I think all be happy to not create
many forks an so on.
The problem is this. So far I'm wondering what MSYS2 is about.
MSYS is about mixing W32 tools (mingw-gcc, binutils) headers and
libraries with *nixy (or cygwinny, if you prefer) buildtools and
scripts, with the aim of building W32 libraries and applications.
In Cygwin (or when running a real GNU system) you have to use a
cross-compiler to build W32 binaries.
In MSYS you don't have to. That's it.
And why exactly is that a problem? The cross compiler is creating
the exact same code as a native-like compile with the same version.
If you really want that badly, you could get this by not installing
the Cygwin gcc4 package but rather installing matching hardlinks or
symlinks in the /bin directory. This hardly explains the requirment
for a fork.
[...]
- or you need a Windows symlink, then you should have created a
native symlink using the new Cygwin capability to create native
symlinks using the CYGWIN=winsymlinks:native{strict} setting.
The latter would be much more feasible as default setting, while on old
pre-Vista systems, it would be much more feasible to fail gracefully, or
to use Cygwin's method to create a Windows .lnk file instead.
Now that you know what MSYS is about,
You're not telling me that *this* is what MSYS2 is about, right?
Not seriously.
it should be obvious that crude
symlink-by-copying is necessary to satisfy W32 tools, which cannot use
cygwin symlinks or Windows .lnk files.
Not really. If you need a copy, call cp. That's what it is for.
Faking symlinks by copying is just bad. So you create a symlink by
copying. Next you change the original. The consumers of the symlink
will never see this change. This is just... bad.
Windows symlinks (when using NT 6 and newer) are fine (well, they are
not POSIXly, but they may turn out to be better than dumb copying (for
the purpose of using them when building software), i'll try to test that
later), MSYS1 had no way of creating them, and thus this was not an
option. Now it is an option, and maybe a good default too.
And then, if you;re using them as default, the question returns. Why
not use Cygwin with this option rather than the fork? ou can simply set
up your default environment with the CYGWIN=winsymlinks:native{strict}
option and you're all set.
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 11 12:58, Ray Donnelly wrote: I for one am hugely appreciative of all the hard work that Corinna, Kai, redhat, the mingw-w64 team and also Alexey has put into both Cygwin and MSYS2. Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we I fail to see that. MSYS2 is basically to run a Mingw compiler and to have a POSIX-like shell. How is that something Cygwin doesn't provide anyway?!? can reasonably do on MSYS2 (credits, thanks printed at each login, explanations of where MSYS2 comes from and links to Cygwin etc) to make the fork-pill easier to swallow, I'm sure Alexey will be happy to do (though I can't speak for him of course!) MSYS itself was a fork of Cygwin ages ago, and it's really showing its age. If you accept that there's any value in MSYS, then I hope you can see the need we in the MSYS using section of the mingw-w64 community have for an updated versoin. As an example, we can't build Qt with MSYS because MSYS Perl is at version 5.8.8. MSYS itself was badly fragmented by the msysgit project which uses an even earlier version of MSYS than the latest one which is also missing important tools such as install.exe and something has to be done to improve this situation. Our hope is that MSYS2 can be adopted by that project and that MSYS never rots as badly as it has done. If we can get down to a proper technical discussion on what's different and why, then we can maybe think about some way of working together? So many thanks everybody for the hard work and dedication. My stance is that everything you can do with MSYS2 you can do with Cygwin anyway, so the reason for the fork escapes me. If it's all about symlinks as copies, then I think this was a really bad idea from the start. In the old times Cygwin did the same (albeit not recursively) when creating hardlinks on FAT and FAT32. But that was a bad idea from the start as well, which is why later versions of Cygwin returned an error EPERM instead. So, yes, I'm more than willing to discuss the technical reasons for forking Cygwin, but there's nothing yet which couldn't be handled by a change to the environment setup alone. Alternatively, I could understand if you would build some micro-distro around Cygwin which handles the default setup of the environment differently so it's more matching your Mingw workflow. 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)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 15:58, Ray Donnelly wrote: MSYS itself was badly fragmented by the msysgit project which uses an even earlier version of MSYS than the latest one which is also missing important tools such as install.exe and something has to be done to improve this situation. Our hope is that MSYS2 can be adopted by that project and that MSYS never rots as badly as it has done. Just to make sure that facts (or my interpretation of them, anyway) are on the table: The so-called msysGit project is somewhat misnamed. The git that they build and distribute is actually a mingw-git (that is, a W32 git built with mingw-gcc and not linked to msys-1.dll), which is achieved by heaping lots of W32-specific patches on top of upstream git. With parts of MSYS1 bundled in. I'm not sure why they initially bundled MSYS1 with that git. They probably figured that without a *nix'y shell git doesn't feel git'ty. Or maybe git has mandatory shell scripts somewhere, and they needed bash to run them. mingw-git didn't exist back then (and they didn't switch to it later, when it appeared), so they had to update that bundled MSYS1 manually, and it went stale quickly as a result. Anyway, bundling a copy of MSYS1 wasn't enough for them, they also forked MSYS1 a bit (added partial unicode support, altered MSYS mangling to fit the needs of git better, etc). So far i haven't seen any arguments in favor of git being a W32 application rather than MSYS application. I was able to build msys-git (true msys-git, built with msys-gcc and msys headers, linked to msys-1.dll) recently, and it worked well enough for me. With MSYS2 that is not even a problem anymore, since MSYS2 inherits everything Cygwin has (including a well-maintained version of git). Therefore i hope that msysGit will simply die. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtxcsAAoJEOs4Jb6SI2Cwmr8H/3umAgeku/ModbMrJ39o2CAf c9+AfYLvYi9BaBA2BVSpOvqw4DwH+lE1N7Sf/v2dM/x/ufuPz/jSNWEJLSAEVAmW Jr9wUZzTSiQENCd5OiJBpJD68wOcF8wYVvI2f089uuPxDo7r+88FXHkNB6xm15xF 7+ZKxm/6185KMFkupTKVkYU1PvyZwYFcWbxvyuynahcLyLk/Szf4ydJWsNHGUF/r V8gF/Rt33hbsqhCySHWygdR8HkUIBIDvczRwDN9PfcaDu01VuVjSG04TjVBfttjk R21ySWOW/Qd0AopjSw9ndhWsWnx/nhDe/awumJ4o4NlceN3XjdXjODceLnabXoY= =7sz2 -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 Tue, Jun 11, 2013 at 1:25 PM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 15:58, Ray Donnelly wrote: MSYS itself was badly fragmented by the msysgit project which uses an even earlier version of MSYS than the latest one which is also missing important tools such as install.exe and something has to be done to improve this situation. Our hope is that MSYS2 can be adopted by that project and that MSYS never rots as badly as it has done. Just to make sure that facts (or my interpretation of them, anyway) are on the table: The so-called msysGit project is somewhat misnamed. The git that they build and distribute is actually a mingw-git (that is, a W32 git built with mingw-gcc and not linked to msys-1.dll), which is achieved by heaping lots of W32-specific patches on top of upstream git. With parts of MSYS1 bundled in. Yes I think of it as msys-with-git rather than an MSYS git. I'm not sure why they initially bundled MSYS1 with that git. They probably figured that without a *nix'y shell git doesn't feel git'ty. Or maybe git has mandatory shell scripts somewhere, and they needed bash to run them. mingw-git didn't exist back then (and they didn't switch to it later, when it appeared), so they had to update that bundled MSYS1 manually, and it went stale quickly as a result. Anyway, bundling a copy of MSYS1 wasn't enough for them, they also forked MSYS1 a bit (added partial unicode support, altered MSYS mangling to fit the needs of git better, etc). So far i haven't seen any arguments in favor of git being a W32 application rather than MSYS application. I was able to build msys-git (true msys-git, built with msys-gcc and msys headers, linked to msys-1.dll) recently, and it worked well enough for me. With MSYS2 that is not even a problem anymore, since MSYS2 inherits everything Cygwin has (including a well-maintained version of git). Therefore i hope that msysGit will simply die. My main argument for git remaining a native program is that for programs that do a lot of file IO (compilers, git), native is faster than Cygwin, usually by a big margin. If mingw-git supported native symlinks and MSYS2 did too (as you say, via Cygwin) then IMHO that would be the best scenario. I agree however, that the msysGit project should divorce itself into mingw-git and a crappy broken MSYS (which should then die). I guess they had some essential shell script glue (hopefully) in the past, most of which is probably now done in Perl. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtxcsAAoJEOs4Jb6SI2Cwmr8H/3umAgeku/ModbMrJ39o2CAf c9+AfYLvYi9BaBA2BVSpOvqw4DwH+lE1N7Sf/v2dM/x/ufuPz/jSNWEJLSAEVAmW Jr9wUZzTSiQENCd5OiJBpJD68wOcF8wYVvI2f089uuPxDo7r+88FXHkNB6xm15xF 7+ZKxm/6185KMFkupTKVkYU1PvyZwYFcWbxvyuynahcLyLk/Szf4ydJWsNHGUF/r V8gF/Rt33hbsqhCySHWygdR8HkUIBIDvczRwDN9PfcaDu01VuVjSG04TjVBfttjk R21ySWOW/Qd0AopjSw9ndhWsWnx/nhDe/awumJ4o4NlceN3XjdXjODceLnabXoY= =7sz2 -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 -- 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 11.06.2013 16:04, Corinna Vinschen wrote: On Jun 11 15:43, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 15:26, Corinna Vinschen wrote: Hi Алексей, On Jun 8 01:56, Алексей Павлов wrote: 2013/6/7 Corinna Vinschen wrote: A final note: I'm not opposing the fork. Under the GPL it's your perfect right to do so, as long as you adhere to the license requirements. But that doesn't mean I have to understand it. If the DLL and the tools are exactly the same and only differ by name, then, what's the point? Wouldn't it make more sense to work with us on the Cygwin project instead? Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64 IRC. It would be more right way I think but I think you don't interesting in it. I'm right? That is why I create fork of Cygwin. But if it possible to support MSYS2 mode in Cygwin sources I think all be happy to not create many forks an so on. The problem is this. So far I'm wondering what MSYS2 is about. MSYS is about mixing W32 tools (mingw-gcc, binutils) headers and libraries with *nixy (or cygwinny, if you prefer) buildtools and scripts, with the aim of building W32 libraries and applications. In Cygwin (or when running a real GNU system) you have to use a cross-compiler to build W32 binaries. In MSYS you don't have to. That's it. And why exactly is that a problem? The cross compiler is creating the exact same code as a native-like compile with the same version. Cross-compiling is somewhat more tricky. Also do remember that MSYS1 is rather old, cross-compiling was even trickier back then. And Cygwin had - -mno-cygwin for that purpose back then too. AFAIU, it's also tricky to run testsuite when cross-compiling. it should be obvious that crude symlink-by-copying is necessary to satisfy W32 tools, which cannot use cygwin symlinks or Windows .lnk files. Not really. If you need a copy, call cp. That's what it is for. Faking symlinks by copying is just bad. So you create a symlink by copying. Next you change the original. The consumers of the symlink will never see this change. This is just... bad. Indeed, users are able to call cp instead of ln. Buildscripts can't. Buildscripts (which mostly means autotools) are written with the assumption that they will be run on a POSIX system, and thus MSYS has to provide POSIX tools. Just as Cygwin does. Except that Cygwin goes all the way down to the toolchain and compiles Cygwin programs, while MSYS stops early, only providing tools (i.e. things that are only used at build-time), and only those tools that can't be feasibly ported to W32 (i.e. pkg-config and gettext are ported, bison and bash are not; libtool is a borderline case - is a shell script, but it is also very W32-aware). I do understand that Cygwin improved a lot since MSYS1 fork, and that cross-compiling also moved on, so cross-compiling from Cygwin is not as scary as it was years ago (i hope it isn't; i don't use Cygwin, and i don't cross-compile on my Debian machine these days, so that's all just speculation on my part). Still, i'm not convinced that Cygwin is the universal, all-purpose tool that you seem to think it is (SquarePegRoundCygwin). - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtx1xAAoJEOs4Jb6SI2CwWr0H/2gNYeqKZRzZz19yhDiMh6oT JMxIILyuGQ6JcSVQHK3JwAERdhTg7JumShehLaqd2diUOfxjbWvr7xXH8uuQST3g rcPIxQPMG5uTnJuSHuK3j9N2hDGKrpj3KgW+PZOix29hRJkQTnwi/vYs3cYHycv/ RgU0Qe/XbfuchYIEcBIAmgS6NNko2Cnmb2iHBEzTNsIpYdppxxbVorgGO822rzji okv4fqP9hLmS250zWIkhXgfsA/qrhMStItFje2e0MYUtqJNiANWrjgutGWSfx5Dx DENJBTd5GoKWdvjNxzvzA/G++JfRVNNAINnWHE9hSkKRcO7ApENYcHsyX2ma9Lo= =I1A8 -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)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 16:14, Corinna Vinschen wrote: On Jun 11 12:58, Ray Donnelly wrote: I for one am hugely appreciative of all the hard work that Corinna, Kai, redhat, the mingw-w64 team and also Alexey has put into both Cygwin and MSYS2. Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we I fail to see that. MSYS2 is basically to run a Mingw compiler and to have a POSIX-like shell. How is that something Cygwin doesn't provide anyway?!? Cygwin doesn't seem to have the mangling (that is, converting paths like /usr/local/include/glib to C:/foobar/baz/usr/local/include/glib). I'm sure that Alexey will be able to give you a complete list of things that Cygwin can't do, but MSYS2 can (or should be able to) do. Whether these extra features (or behaviour changes, where features already exist, but do not work in the desired way) should be merged into upstream Cygwin (with appropriate options to turn them on and off) or be left out as a fork, is another question which i am not qualified to answer. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtx9GAAoJEOs4Jb6SI2Cw1ckH/iEFDUNxTrIrgpKQ0+l8+7tN nDwAHVQ411KimF5GxQhjoVhw16WV97jDJCDBNx4X+FL1X3m/KQo+yPGSzkWb8SkX jpc9HRugCmTCNVz0vDqj4ELh1NWvt/m5CuuE6te5h1z0pbhwxvE13380MMQ1G6on yw5dkBGZa5unXGZ0TwedcKhIRBnfYMWfn5oTo3WpWqrU1UDdT8Py5VM4lRK01A9c 8jv4RFUCeunARZl3fyfWPZRy33xovlVYFWTcOwBVi4kcHI/C2seuOb6VBRRb+WI4 usy2WpJQrYYcBDWzxt2slXFtyjAQaqS6rsb3ZgdGBze03feYPLsxM5Ur37s7GgU= =WXti -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 11 12:58, Ray Donnelly wrote: I for one am hugely appreciative of all the hard work that Corinna, Kai, redhat, the mingw-w64 team and also Alexey has put into both Cygwin and MSYS2. Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we I fail to see that. MSYS2 is basically to run a Mingw compiler and to have a POSIX-like shell. How is that something Cygwin doesn't provide anyway?!? Before I begin I would like to note that I have never been a member of cygwin or MSYS development community, but that I was using both in the past as a user (several years each). I am one of those who uses MSYS and who does not like cygwin, so perhaps it might be beneficial to provide my point of view. So keep in mind that what follows is only my subjective opinions what MSYS is good for and why it is good to have it. If you want a minimalistic environment where you can use simple unix-like Makefile or run your configure script, MSYS is exactly that. If your shell script or Makefile works in MSYS, you can have a good confidence it will work for others who use MSYS, and probably even for those who use cygwin or who cross-compile on Linux. On the other side, cygwin is very big, complex and ever-changing beast. It is more like another OS embedded in Windows rather then a shell. Almost no people have the same version of the utils because its multi-version and multi-package nature leads exactly to such diversity. That forces them to manage (install, update) the packages from time to time. Having anything working on your machine says nothing about working it elsewhere because the other one may have some package missing (often difficult to detect which one) or in another version. As a developer I want to be focused on my code and not to continually manage packages in the underlying environment. Exactly such experience taught me to avoid using cygwin. There were also other technical reasons which perhaps may be already be fixed. It is few years ago when I tried cygwin last time. The most prominent of those was the problem with end-of-line settings which tended to be different on some machine causing so many troubles with some utilities etc. I just never encountered such problem with MSYS. Please note I do not say cygwin is useless. I'm sure there are many tasks which require its complexity and where its ability to be (re)configured to one's needs is actually an advantage. But for the tasks I do, it is not. Best regards, Morous -- 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 11 16:59, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 16:14, Corinna Vinschen wrote: On Jun 11 12:58, Ray Donnelly wrote: I for one am hugely appreciative of all the hard work that Corinna, Kai, redhat, the mingw-w64 team and also Alexey has put into both Cygwin and MSYS2. Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we I fail to see that. MSYS2 is basically to run a Mingw compiler and to have a POSIX-like shell. How is that something Cygwin doesn't provide anyway?!? Cygwin doesn't seem to have the mangling (that is, converting paths like /usr/local/include/glib to C:/foobar/baz/usr/local/include/glib). Cygwin has the cygwin_path_conv call which allows to convert paths from POSIX to Windows and vice versa, including long paths 260 chars. You can also use Windows path as input. `find C:/' works. I'm sure that Alexey will be able to give you a complete list of things that Cygwin can't do, but MSYS2 can (or should be able to) do. Just as a sidenote, a ChangeLog.MSYS or something like that in the sources would be helpful. 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 11 16:42, m...@morous.org wrote: On Jun 11 12:58, Ray Donnelly wrote: I for one am hugely appreciative of all the hard work that Corinna, Kai, redhat, the mingw-w64 team and also Alexey has put into both Cygwin and MSYS2. Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we I fail to see that. MSYS2 is basically to run a Mingw compiler and to have a POSIX-like shell. How is that something Cygwin doesn't provide anyway?!? Before I begin I would like to note that I have never been a member of cygwin or MSYS development community, but that I was using both in the past as a user (several years each). I am one of those who uses MSYS and who does not like cygwin, so perhaps it might be beneficial to provide my point of view. So keep in mind that what follows is only my subjective opinions what MSYS is good for and why it is good to have it. If you want a minimalistic environment where you can use simple unix-like Makefile or run your configure script, MSYS is exactly that. If your shell script or Makefile works in MSYS, you can have a good confidence it will work for others who use MSYS, and probably even for those who use cygwin or who cross-compile on Linux. On the other side, cygwin is very big, complex and ever-changing beast. We seem to mix two things here. I'm more concerned about a fork of the Cygwin DLL, Cygwin, the underlying POSIX DLL vs. MSYS2, the underlying POSIX DLL. You seem to be taking of Cygwin the distro, vs. MSYS2 the distro and the contained tools. If the Cygwin distro is too big, or too unstable or whatnot for your taste, that's ok. So, if you think that a MSYS2 distro makes sense, because of a different set of tools, more compact, easier to install, more aligned with the requirements of the Mingw developer, than that's fine. But I don't see that this qualifies for a fork of the DLL. Or, FWIW, to implement a parallel toolchain, targeting *exactly* the same target, just with another toolchain name, linked against the same DLL, just using another name, so the tools are non-interoperable. Think about it. You have two sets of exactly the same coreutils (cp, mv, ls, ...) which are non-interoperable just because the DLL they are linked against are named differently? That's just puzzeling. It doesn't help anybody. There were also other technical reasons which perhaps may be already be fixed. A lot has changed since 2002... 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)
2013/6/11 Corinna Vinschen vinsc...@redhat.com: On Jun 11 16:59, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 16:14, Corinna Vinschen wrote: On Jun 11 12:58, Ray Donnelly wrote: I for one am hugely appreciative of all the hard work that Corinna, Kai, redhat, the mingw-w64 team and also Alexey has put into both Cygwin and MSYS2. Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we I fail to see that. MSYS2 is basically to run a Mingw compiler and to have a POSIX-like shell. How is that something Cygwin doesn't provide anyway?!? Cygwin doesn't seem to have the mangling (that is, converting paths like /usr/local/include/glib to C:/foobar/baz/usr/local/include/glib). Cygwin has the cygwin_path_conv call which allows to convert paths from POSIX to Windows and vice versa, including long paths 260 chars. You can also use Windows path as input. `find C:/' works. I'm sure that Alexey will be able to give you a complete list of things that Cygwin can't do, but MSYS2 can (or should be able to) do. Just as a sidenote, a ChangeLog.MSYS or something like that in the sources would be helpful. Corinna Hmm, isn't the maintaining of ChangeLog not mandatory for GPL? Anyway, I have one question about term msys-toolchain. What actual is here the difference to cygwin, if there is any? [I don't speak about the native-Windows Toolchain end-user in general are using]. As msys isn't a known target upstream on gcc/binutils/etc, I would strictly recomment to use here instead cygwin-triplet anyway. 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)
On Jun 11 16:52, LRN wrote: And why exactly is that a problem? The cross compiler is creating the exact same code as a native-like compile with the same version. Cross-compiling is somewhat more tricky. Also do remember that MSYS1 is rather old, cross-compiling was even trickier back then. And Cygwin had - -mno-cygwin for that purpose back then too. AFAIU, it's also tricky to run testsuite when cross-compiling. I'm using the Mingw cross compiler as part of the Cygwin distro a lot for testing purposes. I never had much of a problem. And the -mno-cygwin flag was a hack. I admit freely that I was kind of nervous when everybody around me thought it's a good idea to remove that flag, but I'm certainly not looking back anymore for a long time. it should be obvious that crude symlink-by-copying is necessary to satisfy W32 tools, which cannot use cygwin symlinks or Windows .lnk files. Not really. If you need a copy, call cp. That's what it is for. Faking symlinks by copying is just bad. So you create a symlink by copying. Next you change the original. The consumers of the symlink will never see this change. This is just... bad. Indeed, users are able to call cp instead of ln. Buildscripts can't. Buildscripts (which mostly means autotools) are written with the assumption that they will be run on a POSIX system, and thus MSYS has to provide POSIX tools. Just as Cygwin does. Except that Cygwin goes all the way down to the toolchain and compiles Cygwin programs, while MSYS stops early, only providing tools (i.e. things that are only used at build-time), and only those tools that can't be feasibly ported to W32 (i.e. pkg-config and gettext are ported, bison and bash are not; libtool is a borderline case - is a shell script, but it is also very W32-aware). And what's the exact problem here? If you have a POSIX toolset anyway, it can be easily used from autotools. Why *do* you stop in the middle? The fact that autotools use POSIX tools doesn't mean the end result of your build has to. I do understand that Cygwin improved a lot since MSYS1 fork, and that cross-compiling also moved on, so cross-compiling from Cygwin is not as scary as it was years ago (i hope it isn't; i don't use Cygwin, and i don't cross-compile on my Debian machine these days, so that's all just speculation on my part). Cross-compiling is dead easy these days. For instance, I'm building the Cygwin package and multiple other packages on Linux for years. Yes, there are packages which refuse to configure correctly when trying to cross-build them, but these are simple bugs in the autoconf script, which are rectifiable and, ideally, sent upstream. Still, i'm not convinced that Cygwin is the universal, all-purpose tool that you seem to think it is (SquarePegRoundCygwin). Dunno about that. It seems to me that the peg is only square because it has been mauled with too big a hammer. Creating an incompatible POSIX toolchain with a forked DLL which in principal only differs by name is such a big hammer. Creating a simplified set of tools but using the same underlying DLL without introducing incompatibilites would have been the more friendly way, IMHO, for the developers and the users. 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)
Corrina, My user-based perspectives embedded below for your consideration... On Jun 8 01:56, Алексей Павлов wrote: 2013/6/7 Corinna Vinschen wrote: A final note: I'm not opposing the fork. Under the GPL it's your perfect right to do so, as long as you adhere to the license requirements. But that doesn't mean I have to understand it. If the DLL and the tools are exactly the same and only differ by name, then, what's the point? Wouldn't it make more sense to work with us on the Cygwin project instead? ...SNIP... The problem is this. So far I'm wondering what MSYS2 is about. It doesn't add any useful functionality over Cygwin. And if so, why not integrate it into Cygwin instead and only have one project for everybody? JonY already maintains the mingw-w64 32 and 64 bit cross toolchains as part of the Cygwin distro, so there's nothing missing for those who want to create native applications. You assume too much when you say ..there's nothing missing... from the current Cygwin situation. For example, while scanning the artifacts from JonY's substantial efforts at http://cygwin.mirrors.pair.com/release/gcc4/ having older 4.7.2 support is uninteresting for how I use mingw-w64 based toolchains. Furthermore, JonY's perspective on cross vs native toolchains is very different than mine. Until the mingwbuilds and ruben's mingw-w64 toolchains became available, the auto-built mingw-w64 toolchains were almost unusable for me for a variety of reasons. But is this a problem? No. I simply use mingwbuilds or ruben mingw-64 toolchains and my own tweaks to take advantage of all of JonY's amazing work without having to share JonY's workflow perspectives. It doesn't appear that I have this flexibility if I chose Cygwin. emotional mode Other than that I'm rather puzzled as to what MSYS2 is about, other than to duplicate developer efforts and to split communities. Apart from your perfect right to fork, you might nevertheless understand that I'm a bit annoyed. Especially given the code base. Me and Kai were working hard for months to create a 64 bit version of Cygwin, and while our Cygwin 64 bit distro is still in test mode, you simply rip off the code and just release your own MSYS2 distro from there. I can't help to feel exploited. /emotional mode While I'm glad you summarized your emotional views (sadly, too often our emotions are dismissed as somehow irrelevant (!?) and only technical or analytical views are acceptable or correct in a discussion), I truly hope you don't feel exploited. I view things very differently and think you and Kai should feel honored that someone with a different perspective than yours respected your and Kai's work enough to use it as the foundation for MSYS2, and open up the discussion on this list early in the MSYS2 development. I view Alexey's efforts as sharing rather than ripping off and think his work is very much a complement to the work that you and Kai have done. Back to the technical stuff. Again, I don't understand the reason for the fork, please explain. What is it, codewise, you really miss in Cygwin? What non-code problems is MSYS2 trying to fix? It's been a very long time since I used Cygwin, but this discussion will cause me to go back and look at Cygwin again. That said, the following are user-perspective reasons why I currently don't use Cygwin: 1) I build native applications rather than apps dependent upon the Cygwin DLL. 2) I dislike Cygwin's `setup.exe` gui installation helper. I automate the stitching together of MSYS functionality with multiple mingw-w64 and mingw.org (non cross) toolchains to create custom toolchains. Cygwin's integrated `gcc4` support from JonY does not work for me, but I'm very thankful I can take advantage of JonY's tremendous efforts in other ways. In fact, I'm working on a tool that will use window's recent symlink behavior to easily switch toolchains via a dir symlink to locations like `C:\DevTools\mingw` in which the MSYS/MSYS2 goodies live in `C:\DevTools\bin` and the toolchains get symlinked and switched under `C:\DevTools\mingw` by a tool that works similar to MKLINK. The bottom line is that while my workflow does not appear to be a good match for Cygwin's primary use cases, I greatly benefit from MSYS (and likely MSYS2) creative and targeted use of underlying Cygwin capabilities. Even though I don't directly use Cygwin, I thank you for all your hard work and hope to always have the option of using a maintained MSYS or MSYS2 bag-o-goodies. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://jonforums.github.io/ | http://thecodeshop.github.io/ twitter: @jonforums -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
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. MSYS is about porting Unix programs to Windows without having a Posix emulation layer, and then (hopefully!) getting those changes up-streamed. 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. 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 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). 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. 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). 5. Add -W option to bash.exe's pwd command for compatibility with old MSYS. 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:/ 7. Minor changes to other userland programs (such as Perl so it reports msys as $^O) which again helps to retain compatibility. 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!). 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)
Hi Алексей, On Jun 8 12:49, Алексей Павлов wrote: I recreate git repository on msys2.sf.net. Now master branch point to MSYS2 source and when you go to code page on sf.net you get page with MSYS2 source. Thank you, that's much better. This allows an unaware user to access the correct sources immediately. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ 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)
Corinna, I upload 3rdparty sources that I use in MSYS2 to https://sourceforge.net/projects/msys2/files/Sources/ Regards, Alexey. -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ 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)
I recreate git repository on msys2.sf.net. Now master branch point to MSYS2 source and when you go to code page on sf.net you get page with MSYS2 source. -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
On Jun 7 00:17, Алексей Павлов wrote:
Hi, everybody!
I have work on creating MSYS2 based on latest Cygwin sources and now create
archives with alpha version.
Links:
32-bit:
x32-msys2-alpha-20130607.7zhttp://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download
64-bit:
x64-msys2-alpha-20130607.7zhttp://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130607.7z/download
MSYS2 is still using Cygwin like posix paths with /cygdrive prefix.
I would be happy if it can be tested by users who uses MSYS environment.
Information about issues you can send to alex...@gmail.com or in this
thread.
This binary archive has a serious licensing problem.
I checked the git source repository on sourceware and found that there
is absolutely *no* change compared to the Cygwin source repository, none
at all. If you build from the git repo, the resulting DLL will be
basically identical to the 2013-06-06 snapshot from
http://cygwin.com/snapshots/
Also, right now, the accompanying tools and DLLs are named as their
Cygwin counterparts. They still use the original names cygcheck.exe,
cygpath.exe, cyglsa{64}.dll, cygwin-console-helper.exe, cygserver.exe.
Isn't that, to say the least, strange?
But more importantly, in the aforementioned binary archives, the DLL is
called msys-2.0.dll. Additionally, calling `uname -sro' returns
MSYS_NT-6.2-WOW64 2.0.0(0.266/5/3) Msys
rather than
CYGWIN_NT-6.2-WOW64 1.7.20(0.266/5/3) Cygwin
and inspecting the object file shows more tiny changes.
None of them are available in the git source repository.
Therefore the binary package infringes the Cygwin license, or, more
specificially, the underlying GPLv3+.
As representative of the copyright holders, I ask you to fix this ASAP
by providing the exact sources required to build the msys-2.0.dll and
it's accompanying tools in the git repo. I also ask you to adhere to
the GPLv3, section 5a, by adding prominent notices stating that you
modified it, and giving a relevant date, in the sources.
Apart from the Cygwin package, the aforementioned binary archives come
with a lot of binaries from other projects, many of them GPLed. Where's
the source code for them?
For GPLv2 packages you could get away with complying to section 3b, but
that requires to give any of your downloaders the written promise to
provide the source code within the next three years, which is kind of
unrealistic, so you *must* provide equivalent source codes according to
GPLv2, section 3a.
For GPLv3 packages you *must* provide either source codes for all binary
packages as well, or you must maintain clear directions next to the
object code saying where to find the corresponding sources, according to
section 6d. If you made changes to the upstream sources to build the
packages, you also have to adhere to section 5. If the changes are not
upstream, you have to provide the source changes.
For non-GPL packages I suggest to check their licensing requirements as
well, especially in terms of the requirement to provide source code.
Please fix this license infringements as soon as possible and keep us
informed about the progress.
A final note: I'm not opposing the fork. Under the GPL it's your
perfect right to do so, as long as you adhere to the license
requirements. But that doesn't mean I have to understand it. If the
DLL and the tools are exactly the same and only differ by name, then,
what's the point? Wouldn't it make more sense to work with us on the
Cygwin project instead?
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
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)
Hello, On 07 Jun, Corinna Vinschen wrote : I checked the git source repository on sourceware and found that there is absolutely *no* change compared to the Cygwin source repository, none git checkout -b msys-2.1 origin/msys2-1.0-dev There are a lot of changes. 235 to be exact... Best regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ 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 7 17:34, Jean-Baptiste Kempf wrote: Hello, On 07 Jun, Corinna Vinschen wrote : I checked the git source repository on sourceware and found that there is absolutely *no* change compared to the Cygwin source repository, none git checkout -b msys-2.1 origin/msys2-1.0-dev There are a lot of changes. 235 to be exact... Thanks, but that's not easily reachable via the MSYS web page. If you click on the Code link on http://sourceforge.net/projects/msys2/ it leads you to the web view and a git command, which is git clone git://git.code.sf.net/p/msys2/code msys2-code I used this command to fetch the repo and I called `git branch' with the following result: $ git branch * master Now I see that the msys2-1.0-dev branch exists, but is only remotely tracked. It would be more helpful if the default `git pull' command would fetch the branch which represents the msys2 binary package. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ 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 07 Jun, Corinna Vinschen wrote : On Jun 7 17:34, Jean-Baptiste Kempf wrote: Hello, On 07 Jun, Corinna Vinschen wrote : I checked the git source repository on sourceware and found that there is absolutely *no* change compared to the Cygwin source repository, none git checkout -b msys-2.1 origin/msys2-1.0-dev There are a lot of changes. 235 to be exact... Thanks, but that's not easily reachable via the MSYS web page. If you Indeed. Yet, I fail to see how this is a GPL violation. A limitation of SF, probably. Asking for the code would have been faster and saner, IMVHO. http://sourceforge.net/p/msys2/code/ci/msys2-1.0-dev/tarball -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ 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 7 17:57, Jean-Baptiste Kempf wrote: On 07 Jun, Corinna Vinschen wrote : On Jun 7 17:34, Jean-Baptiste Kempf wrote: Hello, On 07 Jun, Corinna Vinschen wrote : I checked the git source repository on sourceware and found that there is absolutely *no* change compared to the Cygwin source repository, none git checkout -b msys-2.1 origin/msys2-1.0-dev There are a lot of changes. 235 to be exact... Thanks, but that's not easily reachable via the MSYS web page. If you Indeed. Yet, I fail to see how this is a GPL violation. A limitation of SF, probably. Asking for the code would have been faster and saner, IMVHO. http://sourceforge.net/p/msys2/code/ci/msys2-1.0-dev/tarball Given the msys2-1.0-dev branch, it's not a GPL violation. However, usually I'd expect that I have access to the sources easily. From the msys2 homepage there's only easy access to the binary packages and the master branch. Sane is in the eye of the beholder. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
