From: Suresh G. <sgo...@ya...> - 2007-09-22 23:20:38
|
Hello, A recent post has the line: > I never planned to make an MSYS build of man; > I always planned to distribute it as a native app. What is a "MSYS application"? I have never really used MSYS -- I used to think that any window's cmd application would run in rxvt and that any application buit from the rxvt command line would run in the Window's cmd shell. Thanks, --Suresh |
From: Brian D. <br...@de...> - 2007-09-23 01:53:55
|
Suresh Govindachar wrote: > A recent post has the line: > > > I never planned to make an MSYS build of man; > > I always planned to distribute it as a native app. > > What is a "MSYS application"? I have never really used > MSYS -- I used to think that any window's cmd application > would run in rxvt and that any application buit from the > rxvt command line would run in the Window's cmd shell. Okay, you seem to be confusing several unrelated concepts. Firstly: a MSYS application is one that uses (links with) the the MSYS runtime (msys-1.0.dll), just like a Cygwin application is one that links to the Cygwin runtime (cygwin1.dll), and a MinGW application is one that links to the native system runtime (msvcrt.dll). Here the "runtime" means the library that implements the basic C library and related support functions. The C library (libc) is a rather low-level thing and so it is not like a regular library in the sense the runtime you pick determines a number of characteristics of the application. In particular, apps using the MinGW runtime get exactly what Windows provides and nothing more. This means that there is no support for most POSIX functions such as fork or select on fds (and so on.) Thus applications built to use the MinGW runtime must be ported to Win32, meaning their source must be modified so that they don't use these POSIX APIs that aren't on native Windows. This porting is a large undertaking and for some applications it is much easier to take a different tack -- to use a runtime that provides implementations of these POSIX APIs so that the source can be compiled unmodified. This is the main goal of Cygwin, to allow any Linux/POSIX app to be build without any source changes (or with trivial build tweaks.) However, there is the fact that building a Cygwin app means it's dependant on the Cygwin runtime DLL and is not a stand-alone binary. (And a whole slew of other issues that aren't really germane to this discussion.) MSYS is also a runtime that provides POSIX emulation. In fact it's just an old copy of Cygwin (from the 1.3 days) that has been forked and modified in certain ways. Specifically, the mount table is moved out of the registry and into a file (/etc/fstab) and code has been added to convert POSIX-filename arguments like /usr/local/foo to Win32-filenames like c:/path/to/foo when invoking native Win32 apps. The whole goal of this is to allow building POSIX build tools like bash, m4, sed, autoconf, perl, etc. which would be hard or impossible to port to Win32 natively. The combination of these tools can be used to run POSIX configure scripts to drive the build process of POSIX software that uses autoconf/libtool/automake/etc. However, the key here is that this MSYS environment is just a driver for native Win32 tools such as the MinGW gcc which produces MinGW binaries. It is very rare and uncommon to actually use MSYS to build MSYS apps, and in fact to do this you have to install a special environment and use a specially modified copy of gcc -- currently a very old 2.95 version. Now, you mentioned cmd and rxvt. Those are totally unrelated to the above discussion; it's just that the MSYS default is rxvt, but you can just as well use a native command prompt (and in fact it's recommended due to pty emulation issues.) More specifically, it's helpful to think in terms of a *shell* and a *terminal*. A shell is what interprets commands, a terminal is what displays things. These are two different things -- you can use a shell without a terminal at all, such as when you run a script with output redirected. And you can use a terminal without a shell, such as the case when you directly invoke a program binary and it outputs to stdout. Windows' cmd.exe is a shell. MSYS' bash.exe is a shell. rxvt is a terminal. The native windows "command prompt" is a terminal. In other words, you can mix and match these in any combination: you could be using the bash shell under rxvt, you could be using the bash shell under a native command prompt. Or you could be using the cmd.exe shell under the native command prompt. You could in theory use the cmd.exe shell under rxvt but this probably doesn't work because of the pty emulation issue, but that's an implementation detail and doesn't change the fundamental separation between shell and terminal. Brian |
From: Eric W. <ewe...@cs...> - 2007-09-23 02:41:02
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf > Of Brian Dessent > Sent: Saturday, September 22, 2007 7:54 PM > To: MinGW Users List > Subject: Re: [Mingw-users] What's a "MSYS app"? > > Okay, you seem to be confusing several unrelated concepts. > > Firstly: <snip detailed explanation> Great explanation! Would this happen to be in the wiki somewhere? If not, it oughtta be... Eric Weddington |
From: Erik L. <e.l...@hc...> - 2007-09-23 10:36:17
|
Eric Weddington wrote: > > Great explanation! > Would this happen to be in the wiki somewhere? If not, it oughtta be... > seconded. Erik. |
From: Suresh G. <sgo...@ya...> - 2007-09-23 15:01:52
|
Eric and Erik wondered about adding things to the Wiki: http://www.mingw.org/MinGWiki/index.php/MinGWiki%20Pages --Suresh |
From: Keith M. <kei...@us...> - 2007-09-23 14:14:05
|
On Sat, 2007-09-22 at 20:40 -0600, Eric Weddington wrote: > > Brian Dessent wrote: > > Okay, you seem to be confusing several unrelated concepts. > > > > Firstly: > <snip detailed explanation> > > Great explanation! Absolutely! Thanks Brian. I just have one minor nit to pick; your final paragraph in particular, and a related reference in a earlier one, are misleading, and potentially confusing, especially for a newbie. Specifically: > > Windows' cmd.exe is a shell. MSYS' bash.exe is a shell. rxvt is a > > terminal. This is absolutely correct; it is, perhaps worth noting that another name for a shell is a CLI, (Command Line Interpreter), while a terminal may also be referred to as a console. > > The native windows "command prompt" is a terminal. This is not correct. The native windows "command prompt" is a shell, (it uses cmd.exe), for which Windows has also provided a console, so that you can communicate with it. You had said earlier: `a terminal is what displays things', which is true, but it is also a rather incomplete description; more accurately: A terminal, or console, is a container in which an application may be run; it provides the machinery for displaying the program's output, and also for receiving input from peripheral devices such as the keyboard or the mouse, and passing this to the program. Beyond providing this I/O machinery, the terminal provides no further functionality of its own; that is the responsibility of whatever program is run within the container provided by the terminal. > > In other words, you can mix and match these in any combination: you > > could be using the bash shell under rxvt, More accurately, you could be running the bash shell *within* the console environment provided by rxvt, but in principle this is correct; however: > > you could be using the bash shell under a native command prompt. While this is true, it isn't what you mean. Literally, this would mean start a native command prompt, (i.e. start cmd.exe in a native console), then start bash.exe or sh.exe as a secondary shell, from the cmd.exe prompt. Of course, what you really mean is run bash.exe or sh.exe in a native *console*, (with cmd.exe playing no part at all). > > Or you could be using the cmd.exe shell under the native command > > prompt. Again, what you really mean here is `using the cmd.exe shell within a native Windows console'; this is precisely the scenario which prevails, when running the native `command prompt'. > > You could in theory use the cmd.exe shell under rxvt but this > > probably doesn't work because of the pty emulation issue, This could probably benefit from further explanation. A `pty' is a `pseudo-teletype' device; in simple terms, it is the mechanism used by the console to connect the physical I/O devices, (the display, keyboard and pointer devices), with the I/O streams of the program running within it. In the rxvt console provided with MSYS, this mechanism is flaky and unreliable, which is why we no longer recommend using it. > > but that's an implementation detail and doesn't change the > > fundamental separation between shell and terminal. > Would this happen to be in the wiki somewhere? If not, it oughtta be... Perhaps one of you would like to add it? Regards, Keith. |
From: Erik L. <e.l...@hc...> - 2007-09-24 21:30:56
|
Keith Marshall wrote: > >> Would this happen to be in the wiki somewhere? If not, it oughtta be... > > Perhaps one of you would like to add it? > Made a start. See links below for changes to the wiki. Keith and Brian: please note: - I pasted Brian's description with *one* global modification: a brain-dead replacement of all occurrences of "command prompt" with "CONSOLE". I think that the brain-dead replacement requires scrutiny by a knowledgeable person. (So as to prevent nonsense). To make it easy to find the possible non-sense, I've made the replacements stand out by leaving "CONSOLE" capitalized. - Keith: your additional remarks in this thread are relatively detailed. Therefore, I think it would be best if you surgically introduced them yourself into the wiki. Thanks, Erik -- Links: http://www.mingw.org/MinGWiki/index.php/MSYS http://www.mingw.org/MinGWiki/index.php/Shells%2C%20terminals%20and%20MSYS |
From: David L. <yak...@ya...> - 2007-09-25 05:26:01
|
--- Erik Leunissen <e.l...@hc...> escribió: > Keith Marshall wrote: > > > >> Would this happen to be in the wiki somewhere? If not, it oughtta be... > > > > Perhaps one of you would like to add it? > > > > Made a start. See links below for changes to the wiki. > > Keith and Brian: please note: > > - I pasted Brian's description with *one* global modification: > a brain-dead replacement of all occurrences of "command prompt" with > "CONSOLE". I think that the brain-dead replacement requires scrutiny by > a knowledgeable person. (So as to prevent nonsense). To make it easy > to find the possible non-sense, I've made the replacements stand out by > leaving "CONSOLE" capitalized. > > - Keith: your additional remarks in this thread are relatively detailed. > Therefore, I think it would be best if you surgically introduced them > yourself into the wiki. > > Thanks, > Nice start. ____________________________________________________________________________________ Sé un Mejor Amante del Cine ¿Quieres saber cómo? ¡Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html |
From: Suresh G. <sgo...@ya...> - 2007-09-23 04:49:40
|
Thank you for the explanation. I had read http://www.mingw.org/mingwfaq.shtml#faq-msys but, until reading your explanation, had no clue as to what MSYS really was and why anyone needed it. This is because I did not have the concept of the "GNU Build System". Since reading your post, I have read up on the GNU build system, Autoconf, Automake, Libtool and Gettext at en.wikipedia.org. Your explanation of MinGW and MSYS, including the contrast with Cygwin and comments on shells and terminals, affords a comprehensive understanding of the process and the tools. --Suresh PS: While at wikipedia, I found out about Alexandre Duret-Lutz's "Autotools Tutorial" introducing Autoconf, Automake, Libtool and Gettext, last updated on 2006-08-12 at http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/autotools.html and downloaded it -- but these are slides, not text. But there is introductory text at: http://news.gmane.org/find-root.php?message_id=%3c2006%2d08%2d12%2d23%2d45%2d50%2b6381%2badl%40gnu.org%3e |
From: David L. <yak...@ya...> - 2007-09-23 08:57:56
|
--- Brian Dessent <br...@de...> escribió: > Suresh Govindachar wrote: > > > A recent post has the line: > > > > > I never planned to make an MSYS build of man; > > > I always planned to distribute it as a native app. > > > > What is a "MSYS application"? I have never really used > > MSYS -- I used to think that any window's cmd application > > would run in rxvt and that any application buit from the > > rxvt command line would run in the Window's cmd shell. > > Okay, you seem to be confusing several unrelated concepts. > > Firstly: a MSYS application is one that uses (links with) the the MSYS > runtime (msys-1.0.dll), just like a Cygwin application is one that links > to the Cygwin runtime (cygwin1.dll), and a MinGW application is one that > links to the native system runtime (msvcrt.dll). Here the "runtime" > means the library that implements the basic C library and related > support functions. [...] > > Brian > Many thanks for giving that full explanation. There were some things that I didn't know and I am glad to be a little "clever" because of this text. David. ____________________________________________________________________________________ Sé un Mejor Amante del Cine ¿Quieres saber cómo? ¡Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html |
From: c.lawson <cl...@am...> - 2007-09-26 11:36:57
|
Hi, I'm a complete noob (though I know Eric W above from another world!) but I *think* this excellent explanation has just explained a problem I'm having. Perhaps you can confirm my understanding and perhaps suggest what I should be doing. There is a Z80 cross compiler called z88dk which has basically been developed in the Linux world but that I'd like to try and use in the Win32 world. So I downloaded and installed MinGW and MSYS and put the z88dk tree in my home directory. If I run their supplied ./build.sh then it uses GCC (as the author had intended) to build the Z80 cross compiler and I end up with an executable zcc.exe (analogous to gcc.exe) and this, in turn, when used will invoke a zcpp.exe which is their take on the C pre-processor. All the binaries seem to build just fine. However the ./build.sh then goes on to invoke the now built zcc/zcpp themseleves to build the "run time libraries" for for compiler distribution. So it's now running a .exe binary that's been built using GCC/MinGW/MSYS to cross compile some C source to Z80 code. However when it comes to the first #include it says "file not found" even though the .h is in theory in the (POSIX) path given. By hacking the source of the compiler I finally discovered that it was simply the fopen()s on the specified .h files in the specified -I paths that were failing. So I then tried the simplest of standalone tests and wrote this as a standalone program to be compiled in MinGW/MSYS by GCC and then run from the $ prompt in my home directory: #include <stdio.h> FILE * fin; int main(void) { char fname[200] = "/msys.bat"; char line[200]; int i; fin = fopen(fname, "r"); if (fin != NULL) { while (!feof(fin)) { fgets(line, 199, fin); fprintf(stderr, line); } } else { fprintf(stderr, "couldn't open %s ?\r\n", fname); } } When built/run this simply reports "couldn't open /msys.bat". If I change char fname[200] = "/msys.bat"; to be the relative path "../../msys.bat" and run from /home/clawson then it "cat"s the file as expected. So it seems that a relative pathname can be opened but an absolute path can't. Obviously if I change the absolute path to be the Win32 style "c:\\msys\\1.0\\msys.bat" then that also works. But I think the key thing here is that the .exe (this test program and the zcc.exe cross compiler) I've built are not "MSYS apps" whereas, for example, if I use "cat /msys.bat" then clearly that works and the supplied cat.exe in MSYS *is* an MSYS app (?) but presumably this is just because of MSYS's command line translation of /msys.bat to something else passed into cat.exe - if it had tried to fopen("/msys.bat") from "inside" it would have faced the same problem as my test program as the linked in code for fopen() cannot handle that style of parth spec.? The reason the cross compiler is failing is that it's trying to open, for example, the POSIX style path /usr/local/lib/z88dk/include/float.h - I guess the bottom line of all this is that this is not going to be possible. So I guess my options are to build the ZCC in Cygwin (which will map that /usr/local/.... to the right Win32 directory at run time using the POSIX translation in cygwin1.dll) or I've got to try and make the entire z88dk tree "Win32 friendly" and where it configures include search paths to be things such as /usr/local... I'd need to fix that up to be c:\msys\1.0\local\... etc.? Do I have any other options? BTW sorry for the long post and I hope this isn't considered a "thread hijack" as I really do think my problem here is that the zcc.exe I'm building isn't an "MSYS app" but kind of needs to be ?? Cliff Lawson PS while I've had Cygwin on my machine for yonks (principally to act as an X11R6 terminal to Linux servers) I thought MinGW was a "better" option for producing standlone binaries that didn't need cygwin1.dll to be available but maybe that's exactly what I need? -- View this message in context: http://www.nabble.com/What%27s-a-%22MSYS-app%22--tf4502598.html#a12883094 Sent from the MinGW - User mailing list archive at Nabble.com. |
From: David L. <yak...@ya...> - 2007-09-26 12:19:59
|
--- "c.lawson" <cl...@am...> escribió: > > Hi, > > I'm a complete noob (though I know Eric W above from another world!) but I > *think* this excellent explanation has just explained a problem I'm having. > Perhaps you can confirm my understanding and perhaps suggest what I should > be doing. > [...] > > Cliff Lawson > > This is not a solution to your problem, but when I encounter issues about file acces I use FileMonitor.exe (ProcessMonitor for Vista) from SysInternals (Now I think it's part of M$) to know what is happening with that file. It will show you the real path that the application is trying to open the file from. ____________________________________________________________________________________ Sé un Mejor Amante del Cine ¿Quieres saber cómo? ¡Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html |
From: Brian D. <br...@de...> - 2007-09-26 12:22:58
|
Brian Dessent wrote: > Also correct. I see this on the mailing list a lot, where someone says > "hey I can 'ls /usr/local/foo/bar' but when my app tries to open it, it > fails." That's because ls (and cat, bash, etc) are MSYS apps but your > app is not. And here I meant to add that of course even if your app is not a MSYS app, it will still work to do "someapp /usr/local/foo/bar" since the MSYS runtime knows how to translate arguments into Win32 paths when invoking a non-MSYS binary. So for most things this distinction doesn't matter, only when the filename is derived internally or from a configuration file, not from command line arguments. Brian |
From: Suresh G. <sgo...@ya...> - 2007-09-27 17:03:58
|
>Brian Dessent wrote: > >> Also correct. I see this on the mailing list a lot, where >> someone says "hey I can 'ls /usr/local/foo/bar' but when my app >> tries to open it, it fails." That's because ls (and cat, bash, >> etc) are MSYS apps but your app is not. and elaborated: > And here I meant to add that of course even if your app is not a > MSYS app, it will still work to do "someapp /usr/local/foo/bar" > since the MSYS runtime knows how to translate arguments into > Win32 paths when invoking a non-MSYS binary. So for most things > this distinction doesn't matter, only when the filename is > derived internally or from a configuration file, not from > command line arguments. gnu global ( http://www.gnu.org/software/global/globaldoc.html#SEC15 ) requires less-370 or later. I found a Windows' less-406 at http://www.greenwoodsoftware.com/less/download.html _Confirming_ the discussion in this thread, the windows' less does work inside msys' bash if called from outside msys (and becomes non-functional inside msys-bash if moved to msys-bin). So to use gnu-global with less, I am thinking of removing msys-bin/less and putting windows' less in the path but outside msys. Is there a better way? For example, should I not remove msys-less but just put windows' less in path before msys-less? Thanks, --Suresh |
From: Brian D. <br...@de...> - 2007-09-23 14:21:50
|
Keith Marshall wrote: > prompt. Of course, what you really mean is run bash.exe or sh.exe in a > native *console*, (with cmd.exe playing no part at all). Yes, I realized after I wrote that that I should have used "console" for "command prompt" throughout, so forever I ever muddied the waters with that imprecise term. Brian |
From: Brian D. <br...@de...> - 2007-09-26 12:17:41
|
"c.lawson" wrote: > When built/run this simply reports "couldn't open /msys.bat". If I change > char fname[200] = "/msys.bat"; to be the relative path "../../msys.bat" and > run from /home/clawson then it "cat"s the file as expected. > > So it seems that a relative pathname can be opened but an absolute path > can't. Obviously if I change the absolute path to be the Win32 style > "c:\\msys\\1.0\\msys.bat" then that also works. Right, this test app is a MinGW app and so it doesn't know about MSYS's path conversions. > But I think the key thing here is that the .exe (this test program and the > zcc.exe cross compiler) I've built are not "MSYS apps" whereas, for example, > if I use "cat /msys.bat" then clearly that works and the supplied cat.exe in > MSYS *is* an MSYS app (?) but presumably this is just because of MSYS's > command line translation of /msys.bat to something else passed into cat.exe > - if it had tried to fopen("/msys.bat") from "inside" it would have faced > the same problem as my test program as the linked in code for fopen() cannot > handle that style of parth spec.? Also correct. I see this on the mailing list a lot, where someone says "hey I can 'ls /usr/local/foo/bar' but when my app tries to open it, it fails." That's because ls (and cat, bash, etc) are MSYS apps but your app is not. > So I guess my options are to build the ZCC in Cygwin (which will map that > /usr/local/.... to the right Win32 directory at run time using the POSIX > translation in cygwin1.dll) or I've got to try and make the entire z88dk > tree "Win32 friendly" and where it configures include search paths to be > things such as /usr/local... I'd need to fix that up to be > c:\msys\1.0\local\... etc.? Well, if the application embeds paths into source code or configuration files then obviously it's not going to work unless they are Win32 paths. But fortunately, most all apps from the POSIX world all take a standard set of configure parameters, so this just means you need to give it Win32 paths. You will often see the following idiom: ./configure --prefix=`cd /usr/local && pwd -W` This is functionally equivalent to just specifying --prefix=/usr/local (which is the default autoconf prefix if none is specified, BTW) however the path is converted to Win32 form first, as the -W option of pwd means to display the current working directory in Win32 form. The resulting binary should thus be looking for c:/some/path/to/msys/1.0/usr/local instead of /usr/local. This doesn't always work. There are several ways that this can be a problem: - If the app is POSIXy then its filename manipulation code might get confused by the drive letter and colon. You might be able to work around this by using an absolute path without a drive letter (both a valid Win32 path and a valid POSIX path), as long as everything is on the same drive. - POSIXy Makefiles sometimes expect to be able to construct a valid path by prepending one path to another, such as with the DESTDIR variable in "make install" targets. This kind of thing doesn't work with Win32 paths with drive letters, so you can't use DESTDIR if you configure with Win32 paths. You can however use the "override prefix at 'make install' time" method if you need to install files to a temporary staging area. - By configuring with a Win32 prefix you hardcode that specific location into the binary (again, assuming that the app somehow embeds configured locations into files or code.) This is a problem if you want to distribute your program to other people as it's very lame to require them to install it in a specific drive letter and directory. Here is where being a MSYS/Cygwin app saves you a tremendous amount of frustration, because these runtimes maintain a mount table that maps POSIX locations to actual filesystem locations, so the app can be configured and packaged to be installed with a prefix of e.g. /usr but the actual location will depend on where the user has chosen to locate /usr on their machine. But for native MinGW apps you have no such mount table to rely on, so if you want to make your app relocatable you have to handle it yourself. Bruno Haible wrote a lot of code for gettext/libintl to accomplish this in a cross-platform manner and has made it available in a gnulib module, I believe. But it might be overkill if supporting several dozen Unix platforms is not a goal. In the specific case of gcc, this is supposed to be handled internally -- gcc already has code to handle relocation, so you might be able to just use that. Brian |