From: Jonathan T. <tec...@ka...> - 2005-08-02 23:23:11
|
Hi all, As I mentioned recently, I'm coauthoring a book on C++ which will mention MSYS. I'd like you to look at what I've written to see if it's accurate and easy to understand. I'm especially interested to know if I've mischaracterized MSYS's limitations. I discuss MSYS in two places. First, I compare MinGW with Cygwin: <quote> Cygwin and MinGW represent very different approaches to porting the GNU tools to Windows. Cygwin is an ambitious project to produce a Linux-like environment hosted by Windows; a remarkable assortment of GNU utilities are available as part of the Cygwin distribution. While one of the main goals of Cygwin is to facilitate porting GNU applications to Windows, even if you are not UNIX developer you may soon come to regard the Cygwin tools as indispensable. MinGW, which stands for "Minimalist GNU for Windows," is an attempt to provide a minimal environment for porting GNU applications to Windows. While the full Cygwin installation occupies several Gigabytes, the MinGW distribution is relatively small. Among other things, MinGW includes a runtime environment, a port of GCC, a port of the GNU archiver and linker - part of the GNU binutils package - and a port of the GNU debugger, GDB. It also includes MSYS, a command-line environment capable of executing GNU makefiles and configure scripts. MSYS will be discussed in "Obtaining GNU make." </quote> Next, I talk about running make from the MSYS shell: <quote> If you have worked with both UNIX and Windows, you know that the Windows shell cmd.exe leaves a lot to be desired. Not only is it missing many valuable commands; it also has a limited ability to execute scripts. Since much of make's strength comes from its ability to execute complex shell scripts, forcing it to use cmd.exe limits its usefulness. While it is possible to use make with cmd.exe, it is very difficult to write non-trivial makefiles which work on both UNIX and Windows. MSYS provides the minimal environment necessary to run UNIX-style makefiles and configure scripts on Windows. Among the useful tools it provides are awk, cat, cp, grep, ls, mkdir, mv, rm and sed. MSYS was designed to work with GCC, and it does so beautifully; it has trouble with other Windows toolsets, however, especially if they take command-line options beginning with a slash (/). Where MSYS is minimalist, Cygwin is maximalist. Cygwin make can do everything MSYS make can do, and much more. Portable makefiles, however, restrict themselves to a narrow range of GNU utilities, and MSYS supports all of these </quote> Please let me know what you think. Best Regards, Jonathan Turkanis |
From: Adib T. <tar...@wi...> - 2005-08-03 00:18:06
|
Jonathan Turkanis schrieb: > Hi all, > > As I mentioned recently, I'm coauthoring a book on C++ which will mention MSYS. > I'd like you to look at what I've written to see if it's accurate and easy to > understand. I'm especially interested to know if I've mischaracterized MSYS's > limitations. > > I discuss MSYS in two places. First, I compare MinGW with Cygwin: > > <quote> > > Cygwin and MinGW represent very different approaches to porting the GNU tools to > Windows. Cygwin is an ambitious project to produce a Linux-like environment > hosted by Windows; a remarkable assortment of GNU utilities are available as > part of the Cygwin distribution. While one of the main goals of Cygwin is to > facilitate porting GNU applications to Windows, even if you are not UNIX > developer you may soon come to regard the Cygwin tools as indispensable. > > MinGW, which stands for "Minimalist GNU for Windows," is an attempt to provide a > minimal environment for porting GNU applications to Windows. While the full > Cygwin installation occupies several Gigabytes, the MinGW distribution is > relatively small. Among other things, MinGW includes a runtime environment, a > port of GCC, a port of the GNU archiver and linker - part of the GNU binutils > package - and a port of the GNU debugger, GDB. It also includes MSYS, a > command-line environment capable of executing GNU makefiles and configure > scripts. > > MSYS will be discussed in "Obtaining GNU make." > > </quote> > > Next, I talk about running make from the MSYS shell: > > <quote> > > If you have worked with both UNIX and Windows, you know that the Windows shell > cmd.exe leaves a lot to be desired. Not only is it missing many valuable > commands; it also has a limited ability to execute scripts. Since much of make's > strength comes from its ability to execute complex shell scripts, forcing it to > use cmd.exe limits its usefulness. While it is possible to use make with > cmd.exe, it is very difficult to write non-trivial makefiles which work on both > UNIX and Windows. > > MSYS provides the minimal environment necessary to run UNIX-style makefiles and > configure scripts on Windows. Among the useful tools it provides are awk, cat, > cp, grep, ls, mkdir, mv, rm and sed. MSYS was designed to work with GCC, and it > does so beautifully; it has trouble with other Windows toolsets, however, > especially if they take command-line options beginning with a slash (/). > > Where MSYS is minimalist, Cygwin is maximalist. Cygwin make can do everything > MSYS make can do, and much more. Portable makefiles, however, restrict > themselves to a narrow range of GNU utilities, and MSYS supports all of these > > </quote> > > Please let me know what you think. > > Best Regards, > Jonathan Turkanis > > > I thing it is worth to mention that Cygwin does a compatibily layer in between the applications and the win32 to emulate the POSIX calls whereas MINGW uses native calls (agains MSVCRT) with no emulation at runtime. HTH, Adib. |
From: Jonathan T. <tec...@ka...> - 2005-08-04 19:25:09
|
Adib Taraben wrote: > Jonathan Turkanis schrieb: >> Hi all, >> >> As I mentioned recently, I'm coauthoring a book on C++ which will >> mention MSYS. I'd like you to look at what I've written to see if >> it's accurate and easy to understand. I'm especially interested to >> know if I've mischaracterized MSYS's limitations. > I thing it is worth to mention that Cygwin does a compatibily layer in > between the applications and the win32 to emulate the POSIX calls > whereas MINGW uses native calls (agains MSVCRT) with no emulation at > runtime. I think your right -- this desrves at least one sentence in the discussion section. Since it's a task-oriented C++ book, I can't give a very detailed explanation, though. Thanks, Jonathan |
From: Greg C. <chi...@co...> - 2005-08-03 03:19:42
|
On 2005-8-2 23:22 UTC, Jonathan Turkanis wrote: > > Cygwin and MinGW represent very different approaches to porting the GNU tools to > Windows. Let's talk first about MinGW versus MSYS. MinGW proper, as I understand it, is only a port of gcc and binutils, along with a set of public-domain msw headers and gcc import libraries to support msw system calls. As such, it isn't really very useful for porting non-trivial gnu tools to msw. Its purpose is to let you use gcc to create msw-native binaries. MSYS adds to MinGW other capabilities that, before its advent, only cygwin (or uwin) provided. Its main purpose, as I understand it, is to make ./configure && make work well enough to build many *nix packages (not just gnu packages) without further ado. To that end, it provides many of the command-line utilities, like rm and sed, that are customarily used in makefiles. Cygwin goes a step further by providing a posix runtime. You can build a shell with Cygwin. In MSYS, you can't do that 'normally', e.g., because a *nix shell uses fork() and exec(), which aren't built into msw. Of course, MSYS provides a shell, and I believe it's built in MSYS, but by a 'non-normal' procedure that depends on its own posix runtime. That's where the distinctions start to blur; perhaps we can say that Cygwin pretends it's *nix and 'encourages' you to write posix code, while MSYS's posix support exists mainly so that MSYS can bootstrap itself. Or maybe I've got this wrong, but if so, someone will correct me quickly here. Another blurry distinction: I've heard it said that Cygwin-built apps run slower because of the posix emulation, and that they are subject to the GPL because the posix emulator is GPL'd; I'm not sure whether those things were ever true, but I think they're not necessarily true now, because Cygwin, with the right switches, can avoid those issues and do exactly what a combination of MinGW and MSYS does. And it may be worth noting that these projects aren't nearly as distinct from each other as I believe both are from uwin. I think the msw headers for MinGW actually reside in cygwin's cvs, and MSYS's posix emulator is a fork of Cygwin's. > Cygwin is an ambitious project to produce a Linux-like environment > hosted by Windows; a remarkable assortment of GNU utilities are available as > part of the Cygwin distribution. Plenty of non-GNU utilities, too. MSYS has bash; Cygwin has bash, zsh, ash, and I forget what others, just as one example. > While one of the main goals of Cygwin is to > facilitate porting GNU applications to Windows, even if you are not UNIX > developer you may soon come to regard the Cygwin tools as indispensable. There I actually wouldn't agree. I've built much free GNU/Linux software using MSYS instead of Cygwin. That worked fine for libxml2-2.6.19 and gnu sed-4.0.7, for instance. Then again, maybe this depends on the definition of 'porting'. Much GNU/Linux software can be built on msw without changes (perhaps because it was already written with support for multiple platforms including msw) and doesn't require a posix runtime environment; MSYS suffices for this. For some other software, Cygwin's emulation would make things much simpler. > MinGW, which stands for "Minimalist GNU for Windows," is an attempt to provide a > minimal environment for porting GNU applications to Windows. While the full > Cygwin installation occupies several Gigabytes, the MinGW distribution is > relatively small. Yes, probably a few tens of megabytes if you download everything. > Among other things, MinGW includes a runtime environment, a > port of GCC, a port of the GNU archiver and linker - part of the GNU binutils > package - and a port of the GNU debugger, GDB. It also includes MSYS, a > command-line environment capable of executing GNU makefiles and configure > scripts. I think of MSYS as a separate package, not part of MinGW. You can use MinGW without MSYS--I did for years, before MSYS existed; but I doubt anyone uses MSYS without MinGW. I'm not sure what you mean by "MinGW includes a runtime environment": do you mean bash, or perhaps the posix emulator underlying it? I'd consider those parts of MSYS instead. > MSYS provides the minimal environment necessary to run UNIX-style makefiles and > configure scripts on Windows. Among the useful tools it provides are awk, cat, > cp, grep, ls, mkdir, mv, rm and sed. MSYS was designed to work with GCC, and it > does so beautifully; it has trouble with other Windows toolsets, however, > especially if they take command-line options beginning with a slash (/). Certain msw conventions, like slash as an option prefix, or paths with embedded spaces, conflict with *nix conventions. Those conflicts are a problem with Cygwin as well as MSYS, but the last sentence above almost seems to imply that they're a worse problem for MSYS, which I don't think would be correct. Backslash-delimited paths are typical in the msw world, although as far as I know most msw programs except CMD.EXE and COMMAND.COM happily accept posix paths as command-line arguments. I have the impression that MSYS strives harder than Cygwin to accept paths like 'C:\foo\bar'. |
From: John V. <ja...@gm...> - 2005-08-03 05:10:30
|
On 8/3/05, Greg Chicares <chi...@co...> wrote: > On 2005-8-2 23:22 UTC, Jonathan Turkanis wrote: > > > > Cygwin and MinGW represent very different approaches to porting the GNU= tools to > > Windows. >=20 > Let's talk first about MinGW versus MSYS. >=20 > MinGW proper, as I understand it, is only a port of gcc and binutils, > along with a set of public-domain msw headers and gcc import libraries to > support msw system calls. As such, it isn't really very useful for portin= g > non-trivial gnu tools to msw. Its purpose is to let you use gcc to create > msw-native binaries. >=20 > MSYS adds to MinGW other capabilities that, before its advent, only cygwi= n > (or uwin) provided. Its main purpose, as I understand it, is to make > ./configure && make > work well enough to build many *nix packages (not just gnu packages) > without further ado. To that end, it provides many of the command-line > utilities, like rm and sed, that are customarily used in makefiles. I like to use the following simple descriptions for someone new to GNU on Windows: MSYS is a tool to assist developers familiar to, or needing to use, Unix tools. Any development done using MSYS could be done without it. Cygwin is a platform on top of Windows, bringing it into conformance with POSIX, and encouraging POSIX compliant code. This means that end-users and developers are both running a new platform with additional benefits and problems, and an additional layer of versions. > Cygwin goes a step further by providing a posix runtime. You can build > a shell with Cygwin. In MSYS, you can't do that 'normally', e.g., because > a *nix shell uses fork() and exec(), which aren't built into msw. Of > course, MSYS provides a shell, and I believe it's built in MSYS, but by > a 'non-normal' procedure that depends on its own posix runtime. That's > where the distinctions start to blur; perhaps we can say that Cygwin > pretends it's *nix and 'encourages' you to write posix code, while MSYS's > posix support exists mainly so that MSYS can bootstrap itself. Or maybe > I've got this wrong, but if so, someone will correct me quickly here. >=20 > Another blurry distinction: I've heard it said that Cygwin-built apps > run slower because of the posix emulation, and that they are subject to > the GPL because the posix emulator is GPL'd; I'm not sure whether those > things were ever true, but I think they're not necessarily true now, > because Cygwin, with the right switches, can avoid those issues and do > exactly what a combination of MinGW and MSYS does. Applications that depend on the Cygwin environment are free to use any Windows API's so there is no technical limitation that would make them slower. The only distinction that can be made wrt performance is that where no Win32 equivalent exists, a port using MinGW must provide its own native implementation, that may be faster than the generic layer in Cygwin. The licensing issue is a very important point when recommending options to new users or students, because this means the commercial viability of their knowledge of "Cygwin" is limited to companies that are able to make money from GPL software. non-GPL'd programs should be able to use Cygwin without falling under the GPL by purchasing the "proprietary-use license for the Cygwin library" [1], however the listed Redhat site to purchase this from is no longer available. It may be that the commercial cygwin has been incorporated into Redhat GNUpro [2]. > And it may be worth noting that these projects aren't nearly as distinct > from each other as I believe both are from uwin. I think the msw headers > for MinGW actually reside in cygwin's cvs, and MSYS's posix emulator is > a fork of Cygwin's. And to further muddy the water, it is possible to build using the MinGW compiler, within the Cygwin environment [3]. > > Cygwin is an ambitious project to produce a Linux-like environment > > hosted by Windows; a remarkable assortment of GNU utilities are availab= le as > > part of the Cygwin distribution. >=20 > Plenty of non-GNU utilities, too. MSYS has bash; Cygwin has bash, zsh, > ash, and I forget what others, just as one example. >=20 > > While one of the main goals of Cygwin is to > > facilitate porting GNU applications to Windows, even if you are not UNI= X > > developer you may soon come to regard the Cygwin tools as indispensable= . >=20 > There I actually wouldn't agree. I've built much free GNU/Linux software > using MSYS instead of Cygwin. That worked fine for libxml2-2.6.19 and > gnu sed-4.0.7, for instance. Then again, maybe this depends on the > definition of 'porting'. Much GNU/Linux software can be built on msw > without changes (perhaps because it was already written with support for > multiple platforms including msw) and doesn't require a posix runtime > environment; MSYS suffices for this. For some other software, Cygwin's > emulation would make things much simpler. >=20 > > MinGW, which stands for "Minimalist GNU for Windows," is an attempt to = provide a > > minimal environment for porting GNU applications to Windows. While the = full > > Cygwin installation occupies several Gigabytes, the MinGW distribution = is > > relatively small. >=20 > Yes, probably a few tens of megabytes if you download everything. Notably Cygwin/X, the X windowing environment on top of Cygwin. > > Among other things, MinGW includes a runtime environment, a > > port of GCC, a port of the GNU archiver and linker - part of the GNU bi= nutils > > package - and a port of the GNU debugger, GDB. It also includes MSYS, a > > command-line environment capable of executing GNU makefiles and configu= re > > scripts. >=20 > I think of MSYS as a separate package, not part of MinGW. You can > use MinGW without MSYS--I did for years, before MSYS existed; but > I doubt anyone uses MSYS without MinGW. >=20 > I'm not sure what you mean by "MinGW includes a runtime environment": > do you mean bash, or perhaps the posix emulator underlying it? I'd > consider those parts of MSYS instead. >=20 > > MSYS provides the minimal environment necessary to run UNIX-style makef= iles and > > configure scripts on Windows. Among the useful tools it provides are aw= k, cat, > > cp, grep, ls, mkdir, mv, rm and sed. MSYS was designed to work with GCC= , and it > > does so beautifully; it has trouble with other Windows toolsets, howeve= r, > > especially if they take command-line options beginning with a slash (/)= . >=20 > Certain msw conventions, like slash as an option prefix, or paths > with embedded spaces, conflict with *nix conventions. Those conflicts > are a problem with Cygwin as well as MSYS, but the last sentence above > almost seems to imply that they're a worse problem for MSYS, which I > don't think would be correct. >=20 > Backslash-delimited paths are typical in the msw world, although as > far as I know most msw programs except CMD.EXE and COMMAND.COM happily > accept posix paths as command-line arguments. I have the impression > that MSYS strives harder than Cygwin to accept paths like 'C:\foo\bar'. Earnie and others have indicate that MS-DOS also handles POSIX paths properly as well. I have only tried with CMD.EXE, and have found that argument quoting is required to avoid the command shell from treating the directory separator as an argument separator as well. e.g. CMD> dir "C:/" 1. http://cygwin.com/faq/faq_1.html#SEC4 2. https://www.redhat.com/software/gnupro/ 3. http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html -- John |
From: Jonathan T. <tec...@ka...> - 2005-08-04 20:22:27
|
John Vandenberg wrote: > The licensing issue is a very important point when recommending > options to new users or students, because this means the commercial > viability of their knowledge of "Cygwin" is limited to companies that > are able to make money from GPL software. > > non-GPL'd programs should be able to use Cygwin without falling under > the GPL by purchasing the "proprietary-use license for the Cygwin > library" [1], however the listed Redhat site to purchase this from is > no longer available. It may be that the commercial cygwin has been > incorporated into Redhat GNUpro [2]. Good point. I was going to mention licensing, but forgot. >> And it may be worth noting that these projects aren't nearly as >> distinct from each other as I believe both are from uwin. I think >> the msw headers for MinGW actually reside in cygwin's cvs, and >> MSYS's posix emulator is >> a fork of Cygwin's. > > And to further muddy the water, it is possible to build using the > MinGW compiler, within the Cygwin environment [3]. This link is from 1999; have you tried using MinGW g++ from with Cygwin more recently? >> Backslash-delimited paths are typical in the msw world, although as >> far as I know most msw programs except CMD.EXE and COMMAND.COM >> happily accept posix paths as command-line arguments. I have the >> impression >> that MSYS strives harder than Cygwin to accept paths like >> 'C:\foo\bar'. > > Earnie and others have indicate that MS-DOS also handles POSIX paths > properly as well. I have only tried with CMD.EXE, and have found that > argument quoting is required to avoid the command shell from treating > the directory separator as an argument separator as well. e.g. > >> dir "C:/" As I mentioned in a reply to Greg Chicares, which I just sent, my problem is that command-line options using "/" are interpretted as POSIX-paths. Some Windows tools don't allow command-line options beginning with - instead of /. Thanks for your help. Jonathan |
From: Earnie B. <ea...@us...> - 2005-08-05 10:55:35
|
On 8:21:27 pm 2005-08-04 "Jonathan Turkanis" <tec...@ka...> wrote: > > As I mentioned in a reply to Greg Chicares, which I just sent, my > problem is that command-line options using "/" are interpretted as > POSIX-paths. Some Windows tools don't allow command-line options > beginning with - instead of /. > > Thanks for your help. > And to work around the issue in MSYS you use //switch; e.g. cmd //c dir. Earnie |
From: Jonathan T. <tec...@ka...> - 2005-08-05 18:48:08
|
Earnie Boyd wrote: > On 8:21:27 pm 2005-08-04 "Jonathan Turkanis" > <tec...@ka...> wrote: > >> >> As I mentioned in a reply to Greg Chicares, which I just sent, my >> problem is that command-line options using "/" are interpretted as >> POSIX-paths. Some Windows tools don't allow command-line options >> beginning with - instead of /. >> >> Thanks for your help. >> > > And to work around the issue in MSYS you use //switch; e.g. cmd //c > dir. That work great. Thanks! I'm sorry I missed the explanation in README.rtf. I posted a question about this some time back, but got no response. Usually this means that there's no answer or the question is so stupid it doesn't deserve an answer. I guess I erroneously assumed the former ;-) Jonathan |
From: Jonathan T. <tec...@ka...> - 2005-08-07 21:07:39
|
Jonathan Turkanis wrote: > Earnie Boyd wrote: >> And to work around the issue in MSYS you use //switch; e.g. cmd //c >> dir. > > That work great. Thanks! > > I'm sorry I missed the explanation in README.rtf. I posted a question > about this some time back, but got no response. Greg just pointed out that there were a number of helpful responses to my initial query; I'm sorry I didn't see them earlier. > Usually this means > that there's no answer or the question is so stupid it doesn't > deserve an answer. I guess I erroneously assumed the former ;-) > Jonathan |
From: Jonathan T. <tec...@ka...> - 2005-08-04 20:15:50
|
Greg Chicares wrote: > On 2005-8-2 23:22 UTC, Jonathan Turkanis wrote: >> >> Cygwin and MinGW represent very different approaches to porting the >> GNU tools to Windows. > > Let's talk first about MinGW versus MSYS. > > MinGW proper, as I understand it, is only a port of gcc and binutils, > along with a set of public-domain msw headers and gcc import > libraries to support msw system calls. As such, it isn't really very > useful for porting non-trivial gnu tools to msw. Its purpose is to > let you use gcc to create msw-native binaries. Good point. > MSYS adds to MinGW other capabilities that, before its advent, only > cygwin (or uwin) provided. Its main purpose, as I understand it, is > to make ./configure && make > work well enough to build many *nix packages (not just gnu packages) > without further ado. To that end, it provides many of the command-line > utilities, like rm and sed, that are customarily used in makefiles. Yes, I should mention that MSYS can be used to build non-GNU packages. > Cygwin goes a step further by providing a posix runtime. You can build > a shell with Cygwin. In MSYS, you can't do that 'normally', e.g., > because a *nix shell uses fork() and exec(), which aren't built into > msw. Of course, MSYS provides a shell, and I believe it's built in > MSYS, but by > a 'non-normal' procedure that depends on its own posix runtime. That's > where the distinctions start to blur; perhaps we can say that Cygwin > pretends it's *nix and 'encourages' you to write posix code, while > MSYS's posix support exists mainly so that MSYS can bootstrap itself. > Or maybe I've got this wrong, but if so, someone will correct me > quickly here. For my book, I don't think I need to discuss MSYS's internal POSIX support. >> Cygwin is an ambitious project to produce a Linux-like environment >> hosted by Windows; a remarkable assortment of GNU utilities are >> available as part of the Cygwin distribution. > > Plenty of non-GNU utilities, too. MSYS has bash; Cygwin has bash, zsh, > ash, and I forget what others, just as one example. It's a GNU bash, though, isn't it? $ help GNU bash, version 2.04.0(1)-release (i686-pc-msys) >> While one of the main goals of Cygwin is to >> facilitate porting GNU applications to Windows, even if you are not >> UNIX developer you may soon come to regard the Cygwin tools as >> indispensable. > > There I actually wouldn't agree. I've built much free GNU/Linux > software using MSYS instead of Cygwin. That worked fine for > libxml2-2.6.19 and gnu sed-4.0.7, for instance. Then again, maybe > this depends on the > definition of 'porting'. Much GNU/Linux software can be built on msw > without changes (perhaps because it was already written with support > for multiple platforms including msw) and doesn't require a posix > runtime environment; MSYS suffices for this. For some other software, > Cygwin's emulation would make things much simpler. I think you misunderstood me. I'm not comparing Cygwin to MSYS here; I'm just describing Cygwin. My point is: even if you're not interested in porting UNIX programs, you can still make good use of Cygwin tools. E.g., you can use tar and gzip. Please let me know what part of the text wasn't clear. >> Among other things, MinGW includes a runtime environment, a >> port of GCC, a port of the GNU archiver and linker - part of the GNU >> binutils package - and a port of the GNU debugger, GDB. It also >> includes MSYS, a command-line environment capable of executing GNU >> makefiles and configure scripts. > > I think of MSYS as a separate package, not part of MinGW. Good point; I guess I should rephrase this. The reason I said MinGW "includes" MSYS was that MSYS is described prominently on the MinGW homepage. > You can > use MinGW without MSYS--I did for years, before MSYS existed; me too. > I'm not sure what you mean by "MinGW includes a runtime environment": > do you mean bash, or perhaps the posix emulator underlying it? I'd > consider those parts of MSYS instead. I'm just listing the packages; I'm refering to "MinGW Runtime." >> MSYS provides the minimal environment necessary to run UNIX-style >> makefiles and configure scripts on Windows. Among the useful tools >> it provides are awk, cat, cp, grep, ls, mkdir, mv, rm and sed. MSYS >> was designed to work with GCC, and it does so beautifully; it has >> trouble with other Windows toolsets, however, especially if they >> take command-line options beginning with a slash (/). > > Certain msw conventions, like slash as an option prefix, or paths > with embedded spaces, conflict with *nix conventions. Those conflicts > are a problem with Cygwin as well as MSYS, but the last sentence above > almost seems to imply that they're a worse problem for MSYS, which I > don't think would be correct. I've had two problems using MSYS with non-GNU toolsets: options using slashes are interpretted as file pathanames and modified to point into the MSYS root directory, and command-line tools called "link" are confused with the command for creating filesystem links, even if the tool-name is fully qualified. Right now, I can't replicate the second problem, but I don't know how to solve the first. I posted a message here a few weeks ago and got no response. If someone can show me how to fix the first problem, I can remove the line about MSYS having trouble with certain toolsets. > Backslash-delimited paths are typical in the msw world, although as > far as I know most msw programs except CMD.EXE and COMMAND.COM happily > accept posix paths as command-line arguments. I have the impression > that MSYS strives harder than Cygwin to accept paths like > 'C:\foo\bar'. As I said, it's not a problem with handling DOS-style paths, but with command-line options being treated as POSIX-style paths. Thanks for all your help. Jonathan |
From: Earnie B. <ea...@us...> - 2005-08-05 11:04:49
|
On 8:14:55 pm 2005-08-04 "Jonathan Turkanis" <tec...@ka...> wrote: > > >> Among other things, MinGW includes a runtime environment, a > >> port of GCC, a port of the GNU archiver and linker - part of the > >> GNU binutils package - and a port of the GNU debugger, GDB. It > >> also includes MSYS, a command-line environment capable of > >> executing GNU makefiles and configure scripts. > > > > I think of MSYS as a separate package, not part of MinGW. > > Good point; I guess I should rephrase this. The reason I said MinGW > "includes" MSYS was that MSYS is described prominently on the MinGW > homepage. > I think that MSYS is really a part of MinGW even though it is a separate package; everything on MinGW is a separate package. Even SF agrees and has given MinGW/MSYS special status as an OS Environment; though I think that is a bit of a stretch. MSYS is optional, but so is C/C++. Earnie |
From: Max T. W. <ma...@mt...> - 2005-08-05 14:53:02
|
Jonathan Turkanis wrote: > > As I said, it's not a problem with handling DOS-style paths, but with > command-line options being treated as POSIX-style paths. Sorry if I'm missing some prior discussion, but have you tried using a double forward slash? My own understanding of this is still quite fuzzy but at least in some cases a parameter starting with '//' is NOT translated to a DOS name and the extra '/' is removed. mt...@us... |
From: Jonathan T. <tec...@ka...> - 2005-08-05 18:50:55
|
Max T. Woodbury wrote: > Jonathan Turkanis wrote: >> >> As I said, it's not a problem with handling DOS-style paths, but with >> command-line options being treated as POSIX-style paths. > > Sorry if I'm missing some prior discussion, No, I'm the one who missed some prior discussion ;-) > but have you tried using a > double forward slash? My own understanding of this is still quite > fuzzy but at least in some cases a parameter starting with '//' is > NOT translated to a DOS name and the extra '/' is removed. Jonathan |
From: Greg C. <chi...@co...> - 2005-08-07 16:23:48
|
On 2005-8-4 20:14 UTC, Jonathan Turkanis wrote: > Greg Chicares wrote: > >>On 2005-8-2 23:22 UTC, Jonathan Turkanis wrote: >> >>>Cygwin is an ambitious project to produce a Linux-like environment >>>hosted by Windows; a remarkable assortment of GNU utilities are >>>available as part of the Cygwin distribution. >> >>Plenty of non-GNU utilities, too. MSYS has bash; Cygwin has bash, zsh, >>ash, and I forget what others, just as one example. > > It's a GNU bash, though, isn't it? > > $ help > GNU bash, version 2.04.0(1)-release (i686-pc-msys) Sure. I'm saying that cygwin goes beyond "a remarkable assortment of GNU utilities" ^^^ and provides lots of non-GNU utilities as well. Taking shells as just one example, I can get by with bash, but I prefer zsh for everyday work, and I use ash to test script portability. But your statement is completely true. >>>While one of the main goals of Cygwin is to >>>facilitate porting GNU applications to Windows, even if you are not >>>UNIX developer you may soon come to regard the Cygwin tools as >>>indispensable. >> >>There I actually wouldn't agree. [snip] > > I think you misunderstood me. I'm not comparing Cygwin to MSYS here [...] > Please let me know what part of the text wasn't clear. OK, I thought you were comparing Cygwin to MSYS. >>>Among other things, MinGW includes a runtime environment, a [...] > >>I'm not sure what you mean by "MinGW includes a runtime environment": >>do you mean bash, or perhaps the posix emulator underlying it? I'd >>consider those parts of MSYS instead. > > I'm just listing the packages; I'm refering to "MinGW Runtime." I think the "MinGW Runtime" means the 'mingwex' thing in cvs, which is really just a set of extensions to the C runtime library. "Environment" sounded like a shell to me. >>>MSYS provides the minimal environment necessary to run UNIX-style >>>makefiles and configure scripts on Windows. Among the useful tools >>>it provides are awk, cat, cp, grep, ls, mkdir, mv, rm and sed. MSYS >>>was designed to work with GCC, and it does so beautifully; it has >>>trouble with other Windows toolsets, however, especially if they >>>take command-line options beginning with a slash (/). >> >>Certain msw conventions, like slash as an option prefix, or paths >>with embedded spaces, conflict with *nix conventions. Those conflicts >>are a problem with Cygwin as well as MSYS, but the last sentence above >>almost seems to imply that they're a worse problem for MSYS, which I >>don't think would be correct. > > I've had two problems using MSYS with non-GNU toolsets: options using slashes > are interpretted as file pathanames and modified to point into the MSYS root > directory, and command-line tools called "link" are confused with the command > for creating filesystem links, even if the tool-name is fully qualified. > > Right now, I can't replicate the second problem, but I don't know how to solve > the first. I posted a message here a few weeks ago and got no response. Was it this? 06 Jun 2005 01:21:29 -0600 Spurious pathname tranformations applied to /xxx switches | For instance, /EHsc becomes C:/Tools/msys/1.0/EHsc That started a thread of several messages, but maybe the only one that addressed your question directly was Earnie's of 6 Jun 2005 10:53:08 +0000 , which said: | Does ``make --win32'' help? > If > someone can show me how to fix the first problem, I can remove the line about > MSYS having trouble with certain toolsets. As far as I know, that problem is specific to MSYS, so I'd have to agree with you. >>Backslash-delimited paths are typical in the msw world, although as >>far as I know most msw programs except CMD.EXE and COMMAND.COM happily >>accept posix paths as command-line arguments. I have the impression >>that MSYS strives harder than Cygwin to accept paths like >>'C:\foo\bar'. > > As I said, it's not a problem with handling DOS-style paths, but with > command-line options being treated as POSIX-style paths. OK, yes, that's the other side of the coin--I had missed that, sorry. I think this testcase illustrates what you're discussing: MSYS: $ xcopy /? Invalid parameter - /msys/1.0 $ xcopy '/?' Invalid parameter - /msys/1.0 $ xcopy "/?" Invalid parameter - /msys/1.0 CMD.EXE: C:\Documents and Settings\chicares>xcopy /? [does what is says on the tin] C:\Documents and Settings\chicares>xcopy '/?' Invalid parameter - /?' C:\Documents and Settings\chicares>xcopy "/?" Invalid number of parameters an msw port of zsh: C:/tmp[0]$xcopy /? zsh: no matches found: /? C:/tmp[1]$xcopy '/?' [does what is says on the tin] C:/tmp[0]$xcopy "/?" [does what is says on the tin] |
From: Greg C. <chi...@co...> - 2005-08-07 16:37:12
|
On 2005-8-7 16:23 UTC, Greg Chicares wrote: > > I think this testcase illustrates what you're discussing: > > MSYS: > > $ xcopy /? > Invalid parameter - /msys/1.0 > $ xcopy '/?' > Invalid parameter - /msys/1.0 > $ xcopy "/?" > Invalid parameter - /msys/1.0 I neglected to say that $ xcopy //? works. If a makefile invokes a tool that requires forward-slash options, and you don't want to customize the makefile for MSYS, then consider 'make --win32' (uses CMD.EXE as subshell). |
From: Kris W. <kew...@qn...> - 2005-08-03 14:03:48
|
A couple of people have commented in this thread that Cygwin doesn't have limitations relative to MinGW and I wanted to comment that I haven't found this to be the case. 1) Recently I did some simple compilation benchmarks (compiling and linking some large applications) and found that native win32 compiled (ie with MinGW) toolchain ran anywhere from 10-20% faster than the identical Cygwin toolchain. 2) Memory allocation in Cygwin is limited. There's a registry hack that makes it somewhat better but Cygwin will refuse to allocate all memory in the system so if you're using the toolchain (ld is the biggest pig) on a huge project, you'll hit your head on physical memory limits and won't even touch your swap space. This is very simple to verify. Compile the following code with Cygwin: int main(void) { unsigned int bit=0x40000000, sum=0; char *x; while (bit > 4096) { x = malloc(bit); if (x) sum += bit; bit >>= 1; } printf("%08x bytes (%.1fMb)\n", sum, sum/1024.0/1024.0); return (0); } Before modifying registry: $ ./memory 18736000 bytes (391.2Mb) $ regtool -i set /HKCU/Software/Cygnus\ Solutions/Cygwin/heap_chunk_in_mb 1024 $ regtool -v list /HKCU/Software/Cygnus\ Solutions/Cygwin mounts v2\ (cygnus) Program Options\ (cygnus) heap_chunk_in_mb = 0x00000400 (1024) After: $ ./memory 3fffe000 bytes (1024.0Mb) Note however that this still doesn't take as much memory as it ought to. If you increase the heap_chunk_in_mb any larger, your cygwin environment will stop working so there's no practical way to get more memory. Under MSYS, you get much more: $ ./memory.exe 6a78a000 bytes (1703.5Mb) I suppose it's possible that Cygwin allocator has been rewritten since the last version I checked was 1.5.5 (they're up to 1.5.18). cheers, Kris |
From: Greg C. <chi...@co...> - 2005-08-03 16:31:32
|
On 2005-8-3 14:06 UTC, Kris Warkentin wrote: > > 1) Recently I did some simple compilation benchmarks (compiling and > linking some large applications) and found that native win32 compiled > (ie with MinGW) toolchain ran anywhere from 10-20% faster than the > identical Cygwin toolchain. This is interesting. I wonder what the reason might be. Were you using '-mno-cygwin'? I had thought that option made Cygwin and MinGW equivalent, though I never had a precise idea of what such equivalence might mean. Were you using the same shell in both cases? I suppose different shells might account for a ten or twenty percent difference if makefiles that often invoke subshells are used. |
From: Kris W. <kew...@qn...> - 2005-08-03 18:02:54
|
Greg Chicares wrote: >On 2005-8-3 14:06 UTC, Kris Warkentin wrote: > > >>1) Recently I did some simple compilation benchmarks (compiling and >>linking some large applications) and found that native win32 compiled >>(ie with MinGW) toolchain ran anywhere from 10-20% faster than the >>identical Cygwin toolchain. >> >> > >This is interesting. I wonder what the reason might be. > >Were you using '-mno-cygwin'? I had thought that option made Cygwin >and MinGW equivalent, though I never had a precise idea of what such >equivalence might mean. > >Were you using the same shell in both cases? I suppose different >shells might account for a ten or twenty percent difference if >makefiles that often invoke subshells are used. > Actually, I wasn't compiling win32 binaries at all. I was compiling QNX Neutrino binaraies using a cross compilation toolchain. The point is that all things being equal: bash shell, same version of compiler, linker, etc. (one built with cygwin, one built without), the mingw built toolchain was faster. cheers, Kris |
From: Jonathan T. <tec...@ka...> - 2005-08-07 16:44:16
|
Greg Chicares wrote: > On 2005-8-4 20:14 UTC, Jonathan Turkanis wrote: >> Greg Chicares wrote: >> >>> On 2005-8-2 23:22 UTC, Jonathan Turkanis wrote: >>> >>>> Cygwin is an ambitious project to produce a Linux-like environment >>>> hosted by Windows; a remarkable assortment of GNU utilities are >>>> available as part of the Cygwin distribution. >>> >>> Plenty of non-GNU utilities, too. MSYS has bash; Cygwin has bash, >>> zsh, ash, and I forget what others, just as one example. >> >> It's a GNU bash, though, isn't it? >> >> $ help >> GNU bash, version 2.04.0(1)-release (i686-pc-msys) > > Sure. I'm saying that cygwin goes beyond > "a remarkable assortment of GNU utilities" > ^^^ > and provides lots of non-GNU utilities as well. Taking shells as > just one example, I can get by with bash, but I prefer zsh for > everyday work, and I use ash to test script portability. > > But your statement is completely true. Oops, sorry, I totally misunderstood you. >>> I'm not sure what you mean by "MinGW includes a runtime >>> environment": do you mean bash, or perhaps the posix emulator >>> underlying it? I'd consider those parts of MSYS instead. >> >> I'm just listing the packages; I'm refering to "MinGW Runtime." > > I think the "MinGW Runtime" means the 'mingwex' thing in cvs, > which is really just a set of extensions to the C runtime library. > "Environment" sounded like a shell to me. Yeah, I didn't mean an environment in that sense. But maybe there's no need to mention the MSYS Runtime package. >> I've had two problems using MSYS with non-GNU toolsets: options >> using slashes are interpretted as file pathanames and modified to >> point into the MSYS root directory, and command-line tools called >> "link" are confused with the command for creating filesystem links, >> even if the tool-name is fully qualified. >> >> Right now, I can't replicate the second problem, but I don't know >> how to solve the first. I posted a message here a few weeks ago and >> got no response. > > Was it this? > 06 Jun 2005 01:21:29 -0600 > Spurious pathname tranformations applied to /xxx switches > >> For instance, /EHsc becomes C:/Tools/msys/1.0/EHsc > > That started a thread of several messages, but maybe the only > one that addressed your question directly was Earnie's of > 6 Jun 2005 10:53:08 +0000 , which said: > >> Does ``make --win32'' help? <blush> Somehow I missed these replies. And I was eagerly awaiting them, too. I'm not sure how it happended. </blush> >> As I said, it's not a problem with handling DOS-style paths, but with >> command-line options being treated as POSIX-style paths. > > OK, yes, that's the other side of the coin--I had missed that, sorry. > I think this testcase illustrates what you're discussing: > > MSYS: > > $ xcopy /? > Invalid parameter - /msys/1.0 > $ xcopy '/?' > Invalid parameter - /msys/1.0 > $ xcopy "/?" > Invalid parameter - /msys/1.0 Yeah, that's it. Thanks, Jonathan |
From: Earnie B. <ea...@us...> - 2005-08-08 12:34:29
|
On 4:43:42 pm 2005-08-07 "Jonathan Turkanis" <tec...@ka...> wrote: > Greg Chicares wrote: > > > > I think the "MinGW Runtime" means the 'mingwex' thing in cvs, > > which is really just a set of extensions to the C runtime library. > > "Environment" sounded like a shell to me. > > Yeah, I didn't mean an environment in that sense. But maybe there's > no need to mention the MSYS Runtime package. > The mingw-runtime includes not only mingwex but also the headers and import libraries for MSVCRT.DLL. It is the runtime MinGW uses and supports. Mingwex is the code base that extends MSVCRT.DLL; primarily for support of C99 but also for the little bit of POSIX that exists. Earnie |