Menu
▾
▴
mingw-w64-public
|
From: Алексей П. <al...@gm...> - 2013-06-06 20:17:33
|
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.7z<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download> 64-bit: x64-msys2-alpha-20130607.7z<http://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 al...@gm... or in this thread. Regards, Alexey. |
|
From: Martin M. <mi...@mo...> - 2013-06-07 06:29:21
Attachments:
which
|
Hi Alexey,
I have just tried the 64-bit package on Win 7. I unpacked it it into
C:\msys as a replacement of my old MSYS package (not sure where it came
from). It could be an old MSYS package from the mingw project). I am
using console2 [1], which is set to use the following command as my shell:
c:\msys\bin\bash.exe --login -i
I have some issues with it:
* With your package, my $HOME/.profile is completely ignored.
* Command "which" is missing. My old MSYS package was having it
implemented as a script (attached).
* Many commands (e.g. ls, basename, ...) start with writing the
following error message to stderr:
0 [main] basename 3784 stdio_init: couldn't make stderr distinct
from stdout
It is funny because "ls 2>/dev/null" suppresses it so it seems the two
are distinct after all...
* The package contains some remnants from your machine which should be
probably cleaned before releasing:
-- home/alexey
-- shortcuts "mintty.exe-____.lnk" or "MSys2.lnk", both pointing
somewhere into C:\test
But other then that, I was able to use it to build my projects after
some twiddling with $PATH to override the gcc toolchain used in the
package. Perhaps it would be better to not include "gcc.exe" and related
without the platform triplet in the package as (arguably) most people
would prefer use these from their mingw-w64, mingw-builds or other gcc
toolchain package as the default one.
[1] https://sourceforge.net/projects/console
Regards,
Morous
On 6.6.2013 22: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.7z
> <http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download>
> 64-bit: x64-msys2-alpha-20130607.7z
> <http://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 al...@gm...
> <mailto:al...@gm...> or in this thread.
>
> 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
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
|
|
From: Алексей П. <al...@gm...> - 2013-06-07 06:52:41
|
2013/6/7 Martin Mitáš <mi...@mo...> > > Hi Alexey, > > I have just tried the 64-bit package on Win 7. I unpacked it it into > C:\msys as a replacement of my old MSYS package (not sure where it came > from). It could be an old MSYS package from the mingw project). I am using > console2 [1], which is set to use the following command as my shell: > c:\msys\bin\bash.exe --login -i > > Thanks for testing! My package contains Console2 in /lib/Console2. There you can fix config.xml to your location. New builds of Console2 you can download from: https://github.com/cbucher/console/wiki/Downloads > > I have some issues with it: > > * With your package, my $HOME/.profile is completely ignored. > > Ok I try to figure problem. * Command "which" is missing. My old MSYS package was having it > implemented as a script (attached). > > Ok I add this script to next snapshot. > * Many commands (e.g. ls, basename, ...) start with writing the following > error message to stderr: > 0 [main] basename 3784 stdio_init: couldn't make stderr distinct > from stdout > > It is funny because "ls 2>/dev/null" suppresses it so it seems the two are > distinct after all... > > Maybe: http://stackoverflow.com/questions/11868017/couldnt-make-stderr-distinct-from-stdout-when-running-cygwin-commands MSYS2 make builded with dos paths support. But I can't see your errors on my machine. Also try to execute under bash "sh /etc/postinstall/000-msys-post-install.sh" > * The package contains some remnants from your machine which should be > probably cleaned before releasing: > -- home/alexey > -- shortcuts "mintty.exe-____.lnk" or "MSys2.lnk", both pointing > somewhere into C:\test > > This is shortcuts is for minty.exe (in bin directory) and for console2 (in lib/Console2). You can fix them and start MSYS2 from this shortcuts. > > > But other then that, I was able to use it to build my projects after > some twiddling with $PATH to override the gcc toolchain used in the > package. Perhaps it would be better to not include "gcc.exe" and related > without the platform triplet in the package as (arguably) most people would > prefer use these from their mingw-w64, mingw-builds or other gcc toolchain > package as the default one. > > Next snapshots I will upload without msys gcc, binutils, headers and libraries. > > [1] https://sourceforge.net/**projects/console<https://sourceforge.net/projects/console> New console builds https://github.com/cbucher/console/wiki/Downloads > > Regards, > Morous > > > > > > On 6.6.2013 22: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.7z >> <http://sourceforge.net/**projects/msys2/files/Alpha-** >> versions/32-bit/x32-msys2-**alpha-20130607.7z/download<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download> >> > >> 64-bit: x64-msys2-alpha-20130607.7z >> <http://sourceforge.net/**projects/msys2/files/Alpha-** >> versions/64-bit/x64-msys2-**alpha-20130607.7z/download<http://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 al...@gm... >> <mailto:al...@gm...> or in this thread. >> >> 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<http://p.sf.net/sfu/servicenow-d2d-j> >> >> >> >> ______________________________**_________________ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.**sourceforge.net<Min...@li...> >> https://lists.sourceforge.net/**lists/listinfo/mingw-w64-**public<https://lists.sourceforge.net/lists/listinfo/mingw-w64-public> >> >> > > ------------------------------------------------------------------------------ > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > |
|
From: Martin M. <mi...@mo...> - 2013-06-07 17:10:43
|
> > * Many commands (e.g. ls, basename, ...) start with writing the > > following error message to stderr: > > 0 [main] basename 3784 stdio_init: couldn't make stderr > > distinct from stdout > > > > It is funny because "ls 2>/dev/null" suppresses it so it seems the > > two are distinct after all... > > Maybe: > http://stackoverflow.com/questions/11868017/couldnt-make-stderr-distinct-from-stdout-when-running-cygwin-commands > MSYS2 make builded with dos paths support. But I can't see your errors > on my machine. > Also try to execute under bash "sh > /etc/postinstall/000-msys-post-install.sh" Yep, running the postinstall script did help. However it may be the 1st step on a dangerous road. I believe people who prefer MSYS instead of cygwin are those appreciating its simplicity, including the install process: Just unpack it and use it. Be careful to not create something what provides less features then cygwin, while being as complex as cygwin to install and use. > > * The package contains some remnants from your machine which > > should be probably cleaned before releasing: > > -- home/alexey > > -- shortcuts "mintty.exe-____.lnk" or "MSys2.lnk", both > > pointing somewhere into C:\test > > This is shortcuts is for minty.exe (in bin directory) and for console2 > (in lib/Console2). You can fix them and start MSYS2 from this shortcuts. Consider that every potential user probably knows how to create a shortcut, creating it is about the same amount of work as fixing it, and if he wants it, he may have different idea where to place it (e.g. desktop). And it seems strange to distribute broken shortcuts on the first place. If you really want them, then at least they should point to some directory which can be considered default for MSYS installation (e.g. C:\msys instead of C:\test). Regards, Morous |
|
From: Алексей П. <al...@gm...> - 2013-06-07 21:06:47
|
2013/6/7 Martin Mitáš <mi...@mo...> > > > * Many commands (e.g. ls, basename, ...) start with writing the > > > following error message to stderr: > > > 0 [main] basename 3784 stdio_init: couldn't make stderr > > > distinct from stdout > > > > > > It is funny because "ls 2>/dev/null" suppresses it so it seems the > > > two are distinct after all... > > > > Maybe: > > > http://stackoverflow.com/questions/11868017/couldnt-make-stderr-distinct-from-stdout-when-running-cygwin-commands > > MSYS2 make builded with dos paths support. But I can't see your errors > > on my machine. > > Also try to execute under bash "sh > > /etc/postinstall/000-msys-post-install.sh" > > Yep, running the postinstall script did help. However it may be the 1st > step on a dangerous road. I believe people who prefer MSYS instead of > cygwin are those appreciating its simplicity, including the install > process: Just unpack it and use it. Be careful to not create something > what provides less features then cygwin, while being as complex as > cygwin to install and use. > > I think the problem is in the /etc/passwd file that can be populated from system. > > > * The package contains some remnants from your machine which > > > should be probably cleaned before releasing: > > > -- home/alexey > > > -- shortcuts "mintty.exe-____.lnk" or "MSys2.lnk", both > > > pointing somewhere into C:\test > > > > This is shortcuts is for minty.exe (in bin directory) and for console2 > > (in lib/Console2). You can fix them and start MSYS2 from this shortcuts. > > Consider that every potential user probably knows how to create a > shortcut, creating it is about the same amount of work as fixing it, and > if he wants it, he may have different idea where to place it (e.g. > desktop). > > And it seems strange to distribute broken shortcuts on the first place. > If you really want them, then at least they should point to some > directory which can be considered default for MSYS installation (e.g. > C:\msys instead of C:\test). > > Sorry, but I only compress my working directory where I have some my stuff. In next snapshots I remove all shortcuts. |
|
From: Алексей П. <al...@gm...> - 2013-06-10 18:58:01
|
New snapshots released.
In this version I split MSYS2 into two parts: MSYS2 (for using with mingw
compilers) and DEVELOP (msys-gcc, msys-binutils, win32api, libraries,
headers).
Links:
32 bit:
x32-msys2-alpha-20130610.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130610.tar.xz/download>
32 bit develop:
x32-msys2-alpha-20130610-develop.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130610-develop.tar.xz/download>
64 bit:
x64-msys2-alpha-20130610.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130610.tar.xz/download>
64 bit develop:
x64-msys2-alpha-20130610-develop.tar.xz<http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130610-develop.tar.xz/download>
This snapshots resolve problems with trailing "/r" symbols when using mingw
compilers. Perl rebuilded with new patch and now it show that it builded
for msys. Also this snapshots fix issue:
https://sourceforge.net/p/mingw/bugs/1963/
Regards,
Alexey.
|
|
From: Alexpux <ale...@gm...> - 2013-06-07 06:40:59
|
07.06.2013, в 10:13, Martin Mitáš <mi...@mo...> написал(а): > > Hi Alexey, > > I have just tried the 64-bit package on Win 7. I unpacked it it into C:\msys as a replacement of my old MSYS package (not sure where it came from). It could be an old MSYS package from the mingw project). I am using console2 [1], which is set to use the following command as my shell: > c:\msys\bin\bash.exe --login -i > Thanks for testing! My package contains Console2 in /lib/Console2. There you can fix config.xml to your location. New builds of Console2 you can download from: https://github.com/cbucher/console/wiki/Downloads > > I have some issues with it: > > * With your package, my $HOME/.profile is completely ignored. > > * Command "which" is missing. My old MSYS package was having it implemented as a script (attached). > Ok I add this script to next snapshot. > * Many commands (e.g. ls, basename, ...) start with writing the following error message to stderr: > 0 [main] basename 3784 stdio_init: couldn't make stderr distinct from stdout > > It is funny because "ls 2>/dev/null" suppresses it so it seems the two are distinct after all… > Try to execute from bash "sh /etc/postinstall/000-msys-post-install.sh" > * The package contains some remnants from your machine which should be probably cleaned before releasing: > -- home/alexey > -- shortcuts "mintty.exe-____.lnk" or "MSys2.lnk", both pointing somewhere into C:\test > > This shortcuts is for minty.exe (in bin directory) and for console2 (in lib/Console2) > > But other then that, I was able to use it to build my projects after > some twiddling with $PATH to override the gcc toolchain used in the package. Perhaps it would be better to not include "gcc.exe" and related without the platform triplet in the package as (arguably) most people would prefer use these from their mingw-w64, mingw-builds or other gcc toolchain package as the default one. > Next snapshots I will upload without gcc,binutils,headers and libraries to avoid conflicts with MinGW compilers. Regards, Alexey. |
|
From: LRN <lr...@gm...> - 2013-06-07 10:35:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.06.2013 10:40, Alexpux wrote: > > 07.06.2013, в 10:13, Martin Mitáš <mi...@mo...> написал(а): >> >> But other then that, I was able to use it to build my projects >> after some twiddling with $PATH to override the gcc toolchain used >> in the >> package. Perhaps it would be better to not include "gcc.exe" and related >> without the platform triplet in the package as (arguably) most people >> would prefer use these from their mingw-w64, mingw-builds or other gcc >> toolchain package as the default one. >> > Next snapshots I will upload without gcc,binutils,headers and libraries > to avoid conflicts with MinGW compilers. > No-o-o-o-o-o! Seriously though, msys-gcc (in msys1) is also called gcc.exe, and there's nothing wrong in having it in /usr/bin, as long as you also have /mingw/bin/gcc.exe, and /mingw/bin is put before /usr/bin in your PATH. Not having a gcc.exe for msys-gcc will prevent some programs from confusing it with mingw-gcc, but might also break some corner-cases (some buildscripts and whatnot that look for 'gcc', not 'i686-pc-msys-gcc' or somesuch). Now, this is all coming down to the package management issue - right now alpha snapshots are supplied as one big archive. Obviously, in the future they will come in packages, and people will have an option of not installing msys-gcc if they don't need it (most people don't; i do). For now you may wish to consider having a base msys package (which contains almost everything) and a developer msys package (which contains things that are needed for compiling msys packages - i.e. msys-gcc, msys headers, static or import libraries from /usr/lib/, msys-autotools etc). - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRsbdlAAoJEOs4Jb6SI2Cw0eUIAJ1p/xQvtkSqvnMYXkgIzbSa afZ0pB2tScDSKh8Zrj0B0daAtmDVmaizU1eo1FrYtyWfTUff3a2l2scDs2mEJ7Lp hF9oLxe+8Q41J0aXnpd0OxbUQo90WeiTKkml2pscORg64nwwOa6Fxd656Go9/JSg c/0T9lJlcGIbSpe75lwl9cBHt1y3UtGJb5VCQNzxGPOrOqwF3v6Fsho9ZhZeXJiy Jfn+M+fWsMuyPD4sR6CGRRpdiakumXkwkGS6bxCBInQ1RBx023EgUOSiK1SV0udV 5gypXfo9PtRLyMisa5cOAc5g7w6cckiLLvif48PPnC0t/WVm73HTe816s8r6C8Q= =e/yB -----END PGP SIGNATURE----- |
|
From: Corinna V. <vin...@re...> - 2013-06-07 15:24:40
|
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.7z<http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download> > 64-bit: x64-msys2-alpha-20130607.7z<http://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 al...@gm... 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 |
|
From: Алексей П. <al...@gm...> - 2013-06-07 21:56:44
|
2013/6/7 Corinna Vinschen <vin...@re...> > 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.7z< > http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download > > > > 64-bit: x64-msys2-alpha-20130607.7z< > http://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 al...@gm... 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. > > I have msys2-1.0-dev branch in git repo as you see. Branch master is Cygwin code that I sync with source ware and then merge into MSYS branch. I create git repository on MSYS2.sf.net only today and do not have time yet to set it properly. 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? > > I still doesn't have packages with source code but I try to upload all source code archives with patches in a week. > 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? > > Some times ago we discuss about adding MSYS 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 MSYS mode in Cygwin sources I think all be happy to not create many forks an so on. Regards, Alexey. |
|
From: Corinna V. <vin...@re...> - 2013-06-11 11:27:00
|
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
|
|
From: Corinna V. <vin...@re...> - 2013-06-11 11:37:08
|
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 |
|
From: LRN <lr...@gm...> - 2013-06-11 11:44:27
|
-----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-----
|
|
From: Ray D. <min...@gm...> - 2013-06-11 11:58:11
|
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 <lr...@gm...> 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-----
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Mingw-w64-public mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
|
|
From: Corinna V. <vin...@re...> - 2013-06-11 12:04:42
|
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
|
|
From: Jon <jon...@gm...> - 2013-06-11 16:24:19
|
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 |
|
From: Алексей П. <al...@gm...> - 2013-06-11 18:10:55
|
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. |
|
From: Corinna V. <vin...@re...> - 2013-06-12 10:47:34
|
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.sys Python32 Users BOOTNXT PerfLogs rhcygwin Windows cygwin Program 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 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. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat |
|
From: Corinna V. <vin...@re...> - 2013-06-12 10:56:12
|
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.sys Python32 Users > BOOTNXT PerfLogs rhcygwin Windows > cygwin Program 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 |
|
From: Alexpux <al...@gm...> - 2013-06-12 11:52:56
|
-- 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 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. > > > Thanks, > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > |
|
From: Alexpux <al...@gm...> - 2013-06-12 11:53:30
|
-- 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 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. > > > Thanks, > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > |
|
From: Ray D. <min...@gm...> - 2013-06-12 11:58:02
|
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'. Would you be willing to consider something like this Corinna? On Wed, Jun 12, 2013 at 12:50 PM, Alexpux <al...@gm...> wrote: > > > -- > 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 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. > > > Thanks, > 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 > Min...@li... > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > |
|
From: LRN <lr...@gm...> - 2013-06-12 12:07:41
|
-----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----- |
|
From: Corinna V. <vin...@re...> - 2013-06-12 14:00:19
|
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 |
|
From: Alexpux <al...@gm...> - 2013-06-12 14:51:58
|
-- 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X