From: Steve D. P. <mai...@st...> - 2001-12-21 21:18:53
|
> When I start bash (with msys.bat) it has > problems with single quotes('). > It says: ': no a valid identifier. > > Also in the /etc/profile it does a for loop, > but it gives me the following messages: > > 'ash: /etc/profile: line 20: syntax error near unexpected token `do > 'ash: /etc/profile: line 20: `for i in /etc/profile.d/*.sh ; do > > is this normal? Well, not that this actually HELPS... but I'm getting the same thing. It worked flawlessly while I still had my Cygwin installation in my system's PATH, but this started as soon as I removed Cygwin from my system altogether. Ehh, at least that's confirmation that it's not just something flaky with your machine alone. Steve P.S. If it matters, my box is Win2K, Service Pack 2 |
From: Earnie B. <ear...@ya...> - 2001-12-22 15:20:46
|
"Steve D. Perkins" wrote: > > > When I start bash (with msys.bat) it has > > problems with single quotes('). > > It says: ': no a valid identifier. > > > > Also in the /etc/profile it does a for loop, > > but it gives me the following messages: > > > > 'ash: /etc/profile: line 20: syntax error near unexpected token `do > > 'ash: /etc/profile: line 20: `for i in /etc/profile.d/*.sh ; do > > > > is this normal? > > Well, not that this actually HELPS... but I'm getting the same thing. > It worked flawlessly while I still had my Cygwin installation in my system's > PATH, but this started as soon as I removed Cygwin from my system > altogether. Ehh, at least that's confirmation that it's not just something > flaky with your machine alone. > I'm out of the office until January 7th. I won't be doing much online until then. However, what is the `uname -a' output? Do you have \r\n line endings in the /etc/profile file? If so, use the dtou.exe I attached yesterday. Remember, only msys-1.0.dll dependent binaries are to go into the /bin directory. > Steve > > P.S. If it matters, my box is Win2K, Service Pack 2 > I doubt it, but I still use WinNT 4. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Steve D. P. <mai...@st...> - 2001-12-22 16:37:17
|
> I'm out of the office until January 7th. I won't be doing much online > until then. However, what is the `uname -a' output? Uname -a gives me: MSYS_NT-5.0 SERVER 1.0.2(0.46/3/2) 2001-12-07 14:07 i686 unknown I have NO idea why the "i686" is showing up there, my home system is an old Pentium I. Just out of curiosity I tried replacing my "i386" distribution with the MSYS "i686" package, but of course I got operating system errors when I tried to start rxvt. This goes back to what I just said in my email to the [MinGW-editor] mailing list... this "i386 vs. i686" verbiage is REALLY going to confuse some people if not explained carefully (especially with uname -a returning values like the above). > Do you have \r\n > line endings in the /etc/profile file? If so, use the dtou.exe I > attached yesterday. Remember, only msys-1.0.dll dependent binaries are > to go into the /bin directory. Ah-ha! I think the problem here is that I just subscribed to the MSYS mailing list yesterday evening, so I've been sending posts in response to what I'm reading in the Geocrawler archive. Of course, SourceForge (god bless 'em!) has something like a TWELVE HOUR delay before things appear in the archive... so I was continuing this discussion unknowing that you had already posted a resolution. At any rate, my symptoms disappeared after converting /etc/profile from DOS format to UNIX format using a feature in UltraEdit (my favorite text editor). Unfortunately, I (and everyone who reads this down the road) am unable to get that "dtou" file you attached to your last email... as the archives do not store attachments. Can you post a link to whatever website/source you got it from yourself, so that people reading the archive down the road will be able to benefit from the resolution of this problem? |
From: Earnie B. <ear...@ya...> - 2001-12-23 00:50:40
|
"Steve D. Perkins" wrote: > > > I'm out of the office until January 7th. I won't be doing much online > > until then. However, what is the `uname -a' output? > > Uname -a gives me: > > MSYS_NT-5.0 SERVER 1.0.2(0.46/3/2) 2001-12-07 14:07 i686 unknown > > I have NO idea why the "i686" is showing up there, my home system is an > old Pentium I. Pentium == i686. The value is returned from a Win32 API. See winsup/cygwin/uname.cc for the source. > Just out of curiosity I tried replacing my "i386" > distribution with the MSYS "i686" package, but of course I got operating > system errors when I tried to start rxvt. That would be expected. > This goes back to what I just > said in my email to the [MinGW-editor] mailing list... this "i386 vs. i686" > verbiage is REALLY going to confuse some people if not explained carefully > (especially with uname -a returning values like the above). > Uname would return i386 on an i386, i486 on an i486, i586 on an i586, etc. > > Do you have \r\n > > line endings in the /etc/profile file? If so, use the dtou.exe I > > attached yesterday. Remember, only msys-1.0.dll dependent binaries are > > to go into the /bin directory. > > Ah-ha! I think the problem here is that I just subscribed to the MSYS > mailing list yesterday evening, so I've been sending posts in response to > what I'm reading in the Geocrawler archive. Of course, SourceForge (god > bless 'em!) has something like a TWELVE HOUR delay before things appear in > the archive... so I was continuing this discussion unknowing that you had > already posted a resolution. > Ok, that makes sense. I wondered why you hadn't caught it in the archives. Since you're reading old archives have you noticed the 1.0.3 snapshot dll? You'll want to replace your 1.0.2 dll with it since it takes care of some scenarios I hadn't thought of originally. > At any rate, my symptoms disappeared after converting /etc/profile from > DOS format to UNIX format using a feature in UltraEdit (my favorite text > editor). Unfortunately, I (and everyone who reads this down the road) am > unable to get that "dtou" file you attached to your last email... as the > archives do not store attachments. Can you post a link to whatever > website/source you got it from yourself, so that people reading the archive > down the road will be able to benefit from the resolution of this problem? > A package is on the round tuit list. I wasn't aware that Geocrawler didn't store attachments. That'll be a PITA. I'll have to move this package up on the priority. Perhaps I can steal a moment or two from family life during the next couple of weeks. ;). Earnie. P.S.: What's your first impressions of MSYS. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Steve D. P. <mai...@st...> - 2001-12-23 04:40:02
|
> Pentium == i686. The value is returned from a Win32 API. See > winsup/cygwin/uname.cc for the source. ... > Uname would return i386 on an i386, i486 on an i486, i586 on an i586, > etc. Ehh, I don't want to venture too far off on a tangent here... but shouldn't a first-generation Pentium processor like mine show up as an "i586"? I mean, it's only one generation up from the 486... the "Pentium" brand-name itself comes from the Latin for "5". I would expect that the BIOS or Win32 API would return "i686" if I had a Pentium Pro or Pentium II. Okay, I'm going to be the idiot who just comes out and asks this... what is the purpose of the "i686" version of MSYS? I'VE been reading mentions in the mailing lists about next-generation 64-bit processesors, and I'M still confused... I imagine that newbies will be completely thrown for a loop. If the "i686" release is a 64-bit build, where does this name come from? If my assumptions are totally off-base, and it's instead a 32-bit build targeted for Pentium processors and up, why doesn't it work on my system... since uname -a is returning the "i686" string? > Ok, that makes sense. I wondered why you hadn't caught it in the > archives. Since you're reading old archives have you noticed the 1.0.3 > snapshot dll? You'll want to replace your 1.0.2 dll with it since it > takes care of some scenarios I hadn't thought of originally. Done that. > A package is on the round tuit list. I wasn't aware that Geocrawler > didn't store attachments. That'll be a PITA. You know Earnie, speaking from the perspective of one with a tendency to be long-winded... I admire your efforts towards efficiency in communication! However, since I've started working with you there have been a few occasions where I'm torn between the dilema of admitting that I don't understand some shorthand you've used, or just knowingly nodding in approval and pretending to be on the same page. In this case I'll just confess my ignorance... what's a PITA? :) > I'll have to move this > package up on the priority. It's not a big deal to me personally (as I have my own tools to fix the problem), but it certainly will be one of those things that is asked about a hundred times. Out of curiosity, why DOES Bourne barf all over DOS-style line-returns? I don't believe that Cygwin suffers from the same problem. I'm not saying that it's a huge priority for the short-term, but that will probably need to be addressed eventually. > Perhaps I can steal a moment or two from > family life during the next couple of weeks. ;). Oh man, go enjoy your holiday! However, MY family does it's thing on Thanksgiving rather than Christmas... so it's mostly idle time for me from now until after New Year's. If there's anything specific I can do to help while time is so plentiful, just let me know. Actually, if you REALLY want to steal a moment from your folks over the next few days... you can respond to the questions I'm posing below. That will give me the raw material and insight I need to go off and do my own thing with documentation over the next couple weeks... > P.S.: What's your first impressions of MSYS. Earnie, there will be a special place reserved for you in heaven for what you've done here! This is something that I've been desperately wanting to see for the past couple of years (since first discovering Cygwin), and it's thrilling to finally see it come together. I'm also very excited to learn that such minimal code changes were required to make it happen, as this indicates ease (and likelihood) of maintenance in the long-term. However, in addition to the issues I've mentioned above ("i686" confusion and line-return problems)... there are a few questions I'm struggling to get my arms around before I put serious effort into documentation for this thing. I've pondered over whether this is more appropriate for the [MinGW-editor] list or [MinGW-MSYS], but since I've "got you on the phone" right here anyway... I'm completely lost regarding the directory structure of MSYS, and how it's supposed to integrate with MinGW. Over the past year I've read dozens of different testimonials for integrating MinGW with Cygwin... the Mumit Khan documents, and other arcane and obsolete descriptions for using "-mno-cygwin" with outdated versions of Cygwin. I suspect that the total number of people who have successfully configured such an environment could be counted on one's digits, without taking off the shoes! When I wrote about this in the website's FAQ... I recommended installing Cygwin and MinGW in separate locations, and putting the MinGW "/bin" before Cygwin's in the PATH. I assume that this is universally considered best practices, as my suggestions have yet to be challenged or improved upon in the months they've been online. Now, is the same style of configuration best for integrating MinGW with MSYS... or are the two packages to be more tightly integrated than this? I'm confused by the fact that the msys-tools package contains a "gcc" executable for the MSYS "/bin". Why is that there? If it's supposed to be there, why is there no accompanying "g++"? If it's supposed to be there, why are there no headers and libs bundled with the MSYS package? Running "gcc -print-search-dirs" (using the gcc from msys-tools) displays a search path including several directories within the MSYS system that aren't even there (i.e. "/lib/msys/..."). Is the intended means of using MinGW within MSYS to create these directories and copy headers and libs over? Are things currently setup this way to accommodate future plans, bundling the MinGW compiler with the MSYS environment as a single download? Out of curiosity, why wasn't MSYS packaged without a built-in MinGW in the first place? I'm sorry for throwing these questions out in rapid-fire fashion. If it would be better to wait until after the holidays, that's fine. If it would be better for me to split them up into several small and more specific mailing list postings, that's fine. If it would be easier or faster to go over this in real-time via phone or IM/IRC, I can arrange a time during business hours or otherwise. I just remember the long hours of frustration I once endured because there wasn't any good source of documentation for using MinGW with Cygwin, and I'd like to help out in making MSYS a more accessible system for newbies. I realize that I'm not the most MinGW-experienced guy on the planet, but I'm pretty much the only person outside the core development team whose ever FOLLOWED THROUGH on offers to assist with documentation. I have the time, others have the knowledge, it would be great to put these two resources together and create something that can help people and promote the system. Steve |
From: Earnie B. <ear...@ya...> - 2001-12-24 16:59:25
|
"Steve D. Perkins" wrote: > > > Pentium == i686. The value is returned from a Win32 API. See > > winsup/cygwin/uname.cc for the source. > ... > > Uname would return i386 on an i386, i486 on an i486, i586 on an i586, > > etc. > > Ehh, I don't want to venture too far off on a tangent here... but > shouldn't a first-generation Pentium processor like mine show up as an > "i586"? I mean, it's only one generation up from the 486... the "Pentium" > brand-name itself comes from the Latin for "5". I would expect that the > BIOS or Win32 API would return "i686" if I had a Pentium Pro or Pentium II. > Shrug, like I said it comes from a w32api call. It's actually returns a struct whose values are then conditionalized to return the i686. > Okay, I'm going to be the idiot who just comes out and asks this... what > is the purpose of the "i686" version of MSYS? The i686 version was compiled with the -march=i686 switch set which instructs GCC to use i686 optimizations not found in prior versions of the CPU. The i386 version was compiled with the -march=i386 switch set. > I'VE been reading mentions in > the mailing lists about next-generation 64-bit processesors, and I'M still > confused... It'll require GCC and binutils to come out with a version that supports those optimizations. To further complicate the matter, the current configurations use the build platform for platform specific naming. Therefore when I build and distribute say a GCC compiler the guessed or supplied build system is used as a directory name. This has nothing at all to do with optimizations used by the compiler for a particular CPU. So, a directory of /usr/i686-pc-msys only means that the binaries were created by an i686-pc-msys system, not optimized for it. > I imagine that newbies will be completely thrown for a loop. If > the "i686" release is a 64-bit build, where does this name come from? AFAIK, all ix86 systems thus far are 32 bit beginning with i386. > If my > assumptions are totally off-base, and it's instead a 32-bit build targeted > for Pentium processors and up, why doesn't it work on my system... since > uname -a is returning the "i686" string? > Perhaps we need to debug uname.cc. I'll work with you on this when I get back to the office. > > Ok, that makes sense. I wondered why you hadn't caught it in the > > archives. Since you're reading old archives have you noticed the 1.0.3 > > snapshot dll? You'll want to replace your 1.0.2 dll with it since it > > takes care of some scenarios I hadn't thought of originally. > > Done that. > > > A package is on the round tuit list. I wasn't aware that Geocrawler > > didn't store attachments. That'll be a PITA. > > You know Earnie, speaking from the perspective of one with a tendency to > be long-winded... I admire your efforts towards efficiency in communication! > However, since I've started working with you there have been a few occasions > where I'm torn between the dilema of admitting that I don't understand some > shorthand you've used, or just knowingly nodding in approval and pretending > to be on the same page. In this case I'll just confess my ignorance... > what's a PITA? :) > Pain In The Ass. It's taken me years to get some of the jargon down to. So don't be afraid to ask or do a google.com search. > > I'll have to move this > > package up on the priority. > > It's not a big deal to me personally (as I have my own tools to fix the > problem), but it certainly will be one of those things that is asked about a > hundred times. Out of curiosity, why DOES Bourne barf all over DOS-style > line-returns? I don't believe that Cygwin suffers from the same problem. > I'm not saying that it's a huge priority for the short-term, but that will > probably need to be addressed eventually. > Well Cygwin does too. Bourne and POSIX (IIRC) use the \ for character quoting. It requires two \\ to get one \. A \t is a tab, a \n is a newline, others have other meanings and those that don't have a special meaning just translate back to themselves. > > Perhaps I can steal a moment or two from > > family life during the next couple of weeks. ;). > > Oh man, go enjoy your holiday! However, MY family does it's thing on > Thanksgiving rather than Christmas... so it's mostly idle time for me from > now until after New Year's. If there's anything specific I can do to help > while time is so plentiful, just let me know. > Just continue to learn and document your difficulties so that others can benefit from what you've learned./ > Actually, if you REALLY want to steal a moment from your folks over the > next few days... you can respond to the questions I'm posing below. That > will give me the raw material and insight I need to go off and do my own > thing with documentation over the next couple weeks... > I'll at least read the mail once a day. > > P.S.: What's your first impressions of MSYS. > > Earnie, there will be a special place reserved for you in heaven for > what you've done here! This is something that I've been desperately wanting > to see for the past couple of years (since first discovering Cygwin), and > it's thrilling to finally see it come together. I'm also very excited to > learn that such minimal code changes were required to make it happen, as > this indicates ease (and likelihood) of maintenance in the long-term. > I was surprised at the lack of coding that was needed also. There was more removing of code, actually preprocessor wrapping than there was actual coding. > However, in addition to the issues I've mentioned above ("i686" > confusion and line-return problems)... there are a few questions I'm > struggling to get my arms around before I put serious effort into > documentation for this thing. I've pondered over whether this is more > appropriate for the [MinGW-editor] list or [MinGW-MSYS], but since I've "got > you on the phone" right here anyway... > This is tough to get. It took me a while to understand the differences between the build system created directory names and the optimization switches used by GCC. The two aren't equal but can be perceived to be. > I'm completely lost regarding the directory structure of MSYS, and how > it's supposed to integrate with MinGW. Over the past year I've read dozens > of different testimonials for integrating MinGW with Cygwin... the Mumit > Khan documents, and other arcane and obsolete descriptions for using > "-mno-cygwin" with outdated versions of Cygwin. I suspect that the total > number of people who have successfully configured such an environment could > be counted on one's digits, without taking off the shoes! > I for one have never really mastered the mix of Cygwin and MinGW binaries. Those that have, have to modify the paths within the Makefiles using cygpath. I hope to have removed the need for the modifications to the Makefile for cygpath. However, libtool appears like it'll be a challenge to overcome due to some assumptions made. :( For the MSYS and MinGW interoperatibility, if you have MinGW already installed in say c:\mingw and you install MSYS in c:\msys\1.0. Now, just make sure that c:\mingw\bin is in PATH before you start msys.bat. If you want to refer to the c:\mingw directories from within MSYS then just usr /c/mingw/bin or c:/mingw/bin. The c:/mingw version IIRC doesn't autocomplete from withing bash, a todo. If you wish to refer to the c:\mingw path as /mingw then add a line to /etc/fstab like so `c:\mingw /mingw' and the next time the dll initializes you'll be able to `ls /mingw', etc. > When I wrote about this in the website's FAQ... I recommended installing > Cygwin and MinGW in separate locations, and putting the MinGW "/bin" before > Cygwin's in the PATH. I assume that this is universally considered best > practices, as my suggestions have yet to be challenged or improved upon in > the months they've been online. > Shouldn't need to do this with MSYS as MSYS isn't going to distribute a gcc. The thing to consider about MSYS is that you can't place binaires in c:\msys\1.0\bin unless they depend on the msys-1.0.dll and that isn't likely to happen except for my distribution and someone else ambitious enough to do a GCC build for msys, but they'll need to figure out what to change. > Now, is the same style of configuration best for integrating MinGW with > MSYS... or are the two packages to be more tightly integrated than this? No, it shouldn't be unless you have the msys version of GCC. > I'm confused by the fact that the msys-tools package contains a "gcc" > executable for the MSYS "/bin". Why is that there? Only version 1.0.1 has gcc. I was over ambitious in what I was distributing and in version 1.0.1, that was everything under the Cygwin practically at least from a developer's POV (point of view). In version 1.0.2 I narrowed the distribution to only what a typical configure script needed to execute to the point of hand selecting individual binaries from the packages. I.E., not all of the binaires from any one package are included in the distribution. > If it's supposed to be > there, why is there no accompanying "g++"? If it's supposed to be there, > why are there no headers and libs bundled with the MSYS package? > It's not supposed to be there in version 1.0.2. If it is that's a mistake. > Running "gcc -print-search-dirs" (using the gcc from msys-tools) > displays a search path including several directories within the MSYS system > that aren't even there (i.e. "/lib/msys/..."). Is the intended means of > using MinGW within MSYS to create these directories and copy headers and > libs over? Ok, I just looked again. I don't see anything other than msys\1.0\bin, msys\1.0\doc, msys\1.0\etc, msys\1.0\home (empty) and msys\1.0\mingw (empty) in the binary distribution. I also don't see a gcc in the distribution. Perhaps you've mixed 1.0.1 and 1.0.2. > Are things currently setup this way to accommodate future plans, > bundling the MinGW compiler with the MSYS environment as a single download? No, I don't think that would be wise. > Out of curiosity, why wasn't MSYS packaged without a built-in MinGW in the > first place? > I supplied an empty /mingw directory only as a suggestion of where MinGW might go. Do you think I should remove it for the 1.0.3 distribution? > I'm sorry for throwing these questions out in rapid-fire fashion. Please, don't be sorry. It needs ironed out be before the masses grab it. > If it would be better to wait until after the holidays, that's fine. My family knows that I'm happiest `putin` so this is fine. > If it would > be better for me to split them up into several small and more specific > mailing list postings, that's fine. Not necessary as long as we can manage to keep them toward the goal of understanding MSYS. > If it would be easier or faster to go > over this in real-time via phone or IM/IRC, I can arrange a time during > business hours or otherwise. > Hopefully won't be necessary. But if further down the road we still think it necessary, then I'm open. I don't have an IRC account, is there a good freebie? > I just remember the long hours of frustration I once endured because > there wasn't any good source of documentation for using MinGW with Cygwin, > and I'd like to help out in making MSYS a more accessible system for > newbies. I'm wanting to make it as simple as install MSYS, install MinGW, configure and make. > I realize that I'm not the most MinGW-experienced guy on the > planet, but I'm pretty much the only person outside the core development > team whose ever FOLLOWED THROUGH on offers to assist with documentation. I'm not that "MinGW-experienced" either, just been with it for some length of time and I do notice those that do and those that have good intentions to do. There is a big difference. Without you and Danny I'd be a one man show about now. > I > have the time, others have the knowledge, it would be great to put these two > resources together and create something that can help people and promote the > system. > Perhaps it's time to be more direct. Those that have/had good intentions sometimes just need more hand holding or at least a kick-start in the right direction. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Steve D. P. <mai...@st...> - 2001-12-26 03:52:46
|
> The i686 version was compiled with the -march=i686 switch set which > instructs GCC to use i686 optimizations not found in prior versions of > the CPU. The i386 version was compiled with the -march=i386 switch set. Okay, I'm almost clear now... just wanted to be sure I understand this fully (for the sake of future documentation). Despite the fact that the Win32 (in "uname -a") returns "i686" for a first-generation Pentium, this does NOT mean that this "-march=i686" switch targets the first-generation Pentium. Is it therefore the case that this optimization flag targets the Pentium Pro and up, or the Pentium II and up? I guess I'm a bit confused as to what effect the Pentium Pro had on Intel's numbering system... since it's kind of a "Pentium One-and-a-Half" in terms of timeline! > AFAIK, all ix86 systems thus far are 32 bit beginning with i386. Great, I'm getting on the same page now. I was initially confused as to whether this build was targeting the next-generation 64-bit processor Intel has available for testing... I had seen a few mentions of this in the mailing lists. > Perhaps we need to debug uname.cc. I'll work with you on this when I > get back to the office. Perhaps that is the case. Certainly no crisis, it can wait until next year. > Pain In The Ass. It's taken me years to get some of the jargon down > to. So don't be afraid to ask or do a google.com search. LOL... by "google search", you're essentially telling me to RTFM? :) > Well Cygwin does too. Bourne and POSIX (IIRC) use the \ for character > quoting. It requires two \\ to get one \. A \t is a tab, a \n is a > newline, others have other meanings and those that don't have a special > meaning just translate back to themselves. I understand that, I was just saying that there have been several occasions when I've edited a Cygwin shell script using a Windows-based editor (with the DOS-style line returns)... and Cygwin's bash had no problem processing the script. I was just curious as to why the MSYS incarnation of bash seems less forgiving. Again, not a crisis situation... but something we'll probably hear repeated questions about in the mailing list down the road. > Shouldn't need to do this with MSYS as MSYS isn't going to distribute a > gcc. ... > Only version 1.0.1 has gcc. ... > It's not supposed to be there in version 1.0.2. If it is that's a > mistake. Bingo! The light bulbs are lighting up! Okay, you can disregard my confusion about gcc's search directories, I was not aware that the instance of gcc in question wasn't supposed to be there. The big picture just became MUCH more clear! FYI, there is still a "gcc.exe". It's not in the 1.0.2 MSYS package, but it IS in the latest version of msys-tools available on the SourceForge site right now. There also appears to be the Fortran compiler in that package, along with a "c++.exe" (I'm not sure what the relationship of that executable is to "g++.exe", which isn't there). > > Are things currently setup this way to accommodate future plans, > > bundling the MinGW compiler with the MSYS environment as a single download? > > No, I don't think that would be wise. I'm not sure that I have an opinion on this one way or the other. However, since I know it will be asked allot down the road... do you mind sharing your reasoning there? > > If it would be easier or faster to go > > over this in real-time via phone or IM/IRC, I can arrange a time during > > business hours or otherwise. > > > > Hopefully won't be necessary. But if further down the road we still > think it necessary, then I'm open. I don't have an IRC account, is > there a good freebie? Oh, IRC doesn't work in the manner of requiring you to "register" for an account. Instead, it's a bit more like "ham" amateur radio. You download a freeware/shareware IRC client (the most popular is mIRC, at www.mirc.com), and the participants involved agree on a network and channel to connect. There are a nice handful of these networks open to public use, typically run by universities and other non-profit institutions. Of course, if there's only two or three of us at most that might be connecting at any given time... it would probably be easier to just use one of the popular instant-messenger clients. They are AOL Instant Messenger (http://www.aolinstantmessenger.com), Yahoo Messenger (http://messenger.yahoo.com), and MSN Messenger (http://messenger.msn.com). With my family scattered across the world as they are, I maintain accounts with all of these messenger clients... should the need ever arise for such a thing. > I'm not that "MinGW-experienced" either, just been with it for some > length of time and I do notice those that do and those that have good > intentions to do. There is a big difference. Without you and Danny I'd > be a one man show about now. Ha, yeah... your work is much appreciated by many. Pardon my whining earlier, I had just been banging my head against the desk trying to figure out big picture... knowing that the MSYS gcc.exe I saw wasn't supposed to be there has cleared things up. Of course, all the interaction with family I've had this past week hasn't helped my capacity for dealing with frustration, either! Cheers, Steve |
From: Earnie B. <ear...@ya...> - 2001-12-27 16:49:09
|
"Steve D. Perkins" wrote: > > > The i686 version was compiled with the -march=i686 switch set which > > instructs GCC to use i686 optimizations not found in prior versions of > > the CPU. The i386 version was compiled with the -march=i386 switch set. > > Okay, I'm almost clear now... just wanted to be sure I understand this > fully (for the sake of future documentation). Despite the fact that the > Win32 (in "uname -a") returns "i686" for a first-generation Pentium, this > does NOT mean that this "-march=i686" switch targets the first-generation > Pentium. Is it therefore the case that this optimization flag targets the > Pentium Pro and up, or the Pentium II and up? I guess I'm a bit confused as > to what effect the Pentium Pro had on Intel's numbering system... since it's > kind of a "Pentium One-and-a-Half" in terms of timeline! > There are varying values that for the march switch that include 'pentium' in the context. These were special purpose for those varying differences of the i686. > > AFAIK, all ix86 systems thus far are 32 bit beginning with i386. > > Great, I'm getting on the same page now. I was initially confused as to > whether this build was targeting the next-generation 64-bit processor Intel > has available for testing... I had seen a few mentions of this in the > mailing lists. > Uhm, it can get worse, 64bit emulation can happen on a 32bit CPU. I believe this is what MS XP is doing when the CPU isn't 64bit capable. It is possible that the newer chips being produced are actually 64bit CPU's with 32bit emulation turned on via hardware switches. > > Perhaps we need to debug uname.cc. I'll work with you on this when I > > get back to the office. > > Perhaps that is the case. Certainly no crisis, it can wait until next > year. > > > Pain In The Ass. It's taken me years to get some of the jargon down > > to. So don't be afraid to ask or do a google.com search. > > LOL... by "google search", you're essentially telling me to RTFM? :) > It's more like UTFSE or STFMLA. > > Well Cygwin does too. Bourne and POSIX (IIRC) use the \ for character > > quoting. It requires two \\ to get one \. A \t is a tab, a \n is a > > newline, others have other meanings and those that don't have a special > > meaning just translate back to themselves. > > I understand that, I was just saying that there have been several > occasions when I've edited a Cygwin shell script using a Windows-based > editor (with the DOS-style line returns)... and Cygwin's bash had no problem > processing the script. I was just curious as to why the MSYS incarnation of > bash seems less forgiving. Again, not a crisis situation... but something > we'll probably hear repeated questions about in the mailing list down the > road. > This is yet another TODO. I want MSYS to be able to guess it's file mode at the time of the open. Then the \r\n won't matter. > > Shouldn't need to do this with MSYS as MSYS isn't going to distribute a > > gcc. > ... > > Only version 1.0.1 has gcc. > ... > > It's not supposed to be there in version 1.0.2. If it is that's a > > mistake. > > Bingo! The light bulbs are lighting up! Okay, you can disregard my > confusion about gcc's search directories, I was not aware that the instance > of gcc in question wasn't supposed to be there. The big picture just became > MUCH more clear! > > FYI, there is still a "gcc.exe". It's not in the 1.0.2 MSYS package, > but it IS in the latest version of msys-tools available on the SourceForge > site right now. There also appears to be the Fortran compiler in that > package, along with a "c++.exe" (I'm not sure what the relationship of that > executable is to "g++.exe", which isn't there). > Yea, that'll go away soon. > > > Are things currently setup this way to accommodate future plans, > > > bundling the MinGW compiler with the MSYS environment as a single > download? > > > > No, I don't think that would be wise. > > I'm not sure that I have an opinion on this one way or the other. > However, since I know it will be asked allot down the road... do you mind > sharing your reasoning there? > 1) Differing maintainers. 2) The package is bigger. 3) The package is more likely to be out-of-date with the releases of the pieces. 4) Requires more, `get this package and then upgrade it with this other package' type of responses in the list. > > > If it would be easier or faster to go > > > over this in real-time via phone or IM/IRC, I can arrange a time during > > > business hours or otherwise. > > > > > > > Hopefully won't be necessary. But if further down the road we still > > think it necessary, then I'm open. I don't have an IRC account, is > > there a good freebie? > > Oh, IRC doesn't work in the manner of requiring you to "register" for an > account. Instead, it's a bit more like "ham" amateur radio. You download a > freeware/shareware IRC client (the most popular is mIRC, at www.mirc.com), > and the participants involved agree on a network and channel to connect. > There are a nice handful of these networks open to public use, typically run > by universities and other non-profit institutions. > Thanks for the info. I'll look into this. > Of course, if there's only two or three of us at most that might be > connecting at any given time... it would probably be easier to just use one > of the popular instant-messenger clients. They are AOL Instant Messenger > (http://www.aolinstantmessenger.com), Yahoo Messenger > (http://messenger.yahoo.com), and MSN Messenger (http://messenger.msn.com). > With my family scattered across the world as they are, I maintain accounts > with all of these messenger clients... should the need ever arise for such a > thing. > I've refused to set any of these up so far. > > I'm not that "MinGW-experienced" either, just been with it for some > > length of time and I do notice those that do and those that have good > > intentions to do. There is a big difference. Without you and Danny I'd > > be a one man show about now. > > Ha, yeah... your work is much appreciated by many. Thanks, but I mean that I've not used the MinGW-GCC proactively. > Pardon my whining > earlier, I had just been banging my head against the desk trying to figure > out big picture... knowing that the MSYS gcc.exe I saw wasn't supposed to be > there has cleared things up. I'm glad the fog has lifted. Our working through the problems have given me ample fuel for the next release. > Of course, all the interaction with family > I've had this past week hasn't helped my capacity for dealing with > frustration, either! > Yea, can't live with `em and can't live without `em. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |