From: Luke D. <cod...@ho...> - 2002-09-16 12:04:43
|
>From: "Paul G." <pga...@at...> >Reply-To: pga...@at... >To: min...@li... >Subject: [Mingw-msys] uname question(s?) >Date: Mon, 16 Sep 2002 04:37:26 -0700 > >Hi folks, > > Just been reviewing uname and how it is being used for autoconfistication >(is that >correct term? It's the thing where "uname" is invoked from within a >"./configure" script in >order to determine which OS is actually running, eg: ac_sys_system=`uname >-s`)? > > I am not sure why MINGW32 is coming up as part of uname -s, since MINGW32 >is >not really a "system". It is closer, at least in my mind, to a type of >build environment. The >other half of that ("_NT-4.0" in my case) is a system reference. The sole purpose of MSYS is to allow MinGW to be recognised as a host system by configure. Perhaps your confusion comes from the difference between a "host" system, a "target" system and a "build" system. When you are configuring a piece of software like GCC, the host is the system on which the resulting compiler will run, the target is the system for which the compiler will produce code, and the "build" system is just what is used to build GCC. MSYS is primarily a build system while mingw32 is your host/target, and "uname" tells you what the _host_ system is. As another example, when you use Cygwin it is usually the host, target and build system. I'm sure somebody else can explain it better than I can... > > Msys, on the other hand (Msys.tem?) seems to be more indicative of a >"system" in >the same sort of way that "Cygwin" is a "system". (Cygwin uname -s yields >"Cygwin" as first >six letters). From that standpoint, it almost seems more logical to have >"uname -s" yield >"Msys_NT-4.0" instead of "MINGW32_NT-4.0". If you are building MSYS-hosted software using the mingwDVLPR package, the MSYSTEM environment variable is set (by msys.bat) to the value "MSYS", which in turn causes "uname -a" to return MSYS as the system name. > > Is there a predefined and undocumented limitation to how long the value of >uname - >s can be? I don't know. > > Thanks for your patience. > > Paul G. Luke Dunstan _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
From: Paul G. <pga...@at...> - 2002-09-17 02:14:40
|
On 16 Sep 2002 at 20:04, Luke Dunstan wrote: > > > > >From: "Paul G." <pga...@at...> > >Reply-To: pga...@at... > >To: min...@li... > >Subject: [Mingw-msys] uname question(s?) > >Date: Mon, 16 Sep 2002 04:37:26 -0700 > > > >Hi folks, > > > > Just been reviewing uname and how it is being used for autoconfistication > >(is that > >correct term? It's the thing where "uname" is invoked from within a > >"./configure" script in > >order to determine which OS is actually running, eg: ac_sys_system=`uname > >-s`)? > > > > I am not sure why MINGW32 is coming up as part of uname -s, since MINGW32 > >is > >not really a "system". It is closer, at least in my mind, to a type of > >build environment. The > >other half of that ("_NT-4.0" in my case) is a system reference. > > The sole purpose of MSYS is to allow MinGW to be recognised as a host system > by configure. You mean that Mingw is to "host" what SGI is to host? SGI, in my mind, up until now, has always been considered a system platform, not a "host". I guess the undefined term is "host". I think the confusion arises when I see Windows NT4 vs Mingw32. Windows NT4 is an Operating System or System Platform, Mingw32 is not. Mingw32 does, however, run on an NT4 platform. Mingw32 is not a platform, is it? Paul G. |
From: Luke D. <cod...@ho...> - 2002-09-17 04:30:52
|
>From: "Paul G." <pga...@at...> >Reply-To: pga...@at... >To: min...@li... >Subject: Re: [Mingw-msys] uname question(s?) >Date: Mon, 16 Sep 2002 19:14:55 -0700 > > > >On 16 Sep 2002 at 20:04, Luke Dunstan wrote: > > > > > > > > > >From: "Paul G." <pga...@at...> > > >Reply-To: pga...@at... > > >To: min...@li... > > >Subject: [Mingw-msys] uname question(s?) > > >Date: Mon, 16 Sep 2002 04:37:26 -0700 > > > > > >Hi folks, > > > > > > Just been reviewing uname and how it is being used for >autoconfistication > > >(is that > > >correct term? It's the thing where "uname" is invoked from within a > > >"./configure" script in > > >order to determine which OS is actually running, eg: >ac_sys_system=`uname > > >-s`)? > > > > > > I am not sure why MINGW32 is coming up as part of uname -s, since >MINGW32 > > >is > > >not really a "system". It is closer, at least in my mind, to a type of > > >build environment. The > > >other half of that ("_NT-4.0" in my case) is a system reference. > > > > The sole purpose of MSYS is to allow MinGW to be recognised as a host >system > > by configure. > > You mean that Mingw is to "host" what SGI is to host? > > SGI, in my mind, up until now, has always been considered a system >platform, not a >"host". I guess the undefined term is "host". > > I think the confusion arises when I see Windows NT4 vs Mingw32. Windows >NT4 is >an Operating System or System Platform, Mingw32 is not. Mingw32 does, >however, run on >an NT4 platform. Mingw32 is not a platform, is it? > > Paul G. MinGW is a platform from the point of view of software, because it has a specific runtime library that is different from other Win32 platforms such as Cygwin. From what little I know about this topic, this seems to be similar to other operating systems like Linux which have host strings something like "*linux*libc1" and "*linux*aout" for different runtimes. You could argue that we should use something like *-win32-mingw32 and *-win32-cygwin but it's a bit too late to make those sort of changes. Luke _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
From: Paul G. <pga...@at...> - 2002-09-17 05:01:19
|
On 17 Sep 2002 at 12:29, Luke Dunstan wrote: > > > > >From: "Paul G." <pga...@at...> > >Reply-To: pga...@at... > >To: min...@li... > >Subject: Re: [Mingw-msys] uname question(s?) > >Date: Mon, 16 Sep 2002 19:14:55 -0700 > > > > > > > >On 16 Sep 2002 at 20:04, Luke Dunstan wrote: > > > > > > > > > > > > > > >From: "Paul G." <pga...@at...> > > > >Reply-To: pga...@at... > > > >To: min...@li... > > > >Subject: [Mingw-msys] uname question(s?) > > > >Date: Mon, 16 Sep 2002 04:37:26 -0700 > > > > > > > >Hi folks, > > > > > > > > Just been reviewing uname and how it is being used for > >autoconfistication > > > >(is that > > > >correct term? It's the thing where "uname" is invoked from within a > > > >"./configure" script in > > > >order to determine which OS is actually running, eg: > >ac_sys_system=`uname > > > >-s`)? > > > > > > > > I am not sure why MINGW32 is coming up as part of uname -s, since > >MINGW32 > > > >is > > > >not really a "system". It is closer, at least in my mind, to a type of > > > >build environment. The > > > >other half of that ("_NT-4.0" in my case) is a system reference. > > > > > > The sole purpose of MSYS is to allow MinGW to be recognised as a host > >system > > > by configure. > > > > You mean that Mingw is to "host" what SGI is to host? > > > > SGI, in my mind, up until now, has always been considered a system > >platform, not a > >"host". I guess the undefined term is "host". > > > > I think the confusion arises when I see Windows NT4 vs Mingw32. Windows > >NT4 is > >an Operating System or System Platform, Mingw32 is not. Mingw32 does, > >however, run on > >an NT4 platform. Mingw32 is not a platform, is it? > > > > Paul G. > > MinGW is a platform from the point of view of software, because it has a > specific runtime library that is different from other Win32 platforms such > as Cygwin. I agree. Mingw is a "software" platform. It is not, however, a "system" platform. > From what little I know about this topic, this seems to be > similar to other operating systems like Linux which have host strings > something like "*linux*libc1" and "*linux*aout" for different runtimes. You > could argue that we should use something like *-win32-mingw32 and > *-win32-cygwin but it's a bit too late to make those sort of changes. Actually, that would be overkill, if I haven't already strayed in to that particular territory. If there were any changes that I might argue for then it would be only to change "MINGW32" to "Msys" or "Msystem" under "uname -s". It is still early enough for that as not a lot of packages that I am aware of have been ported for Msys (in addition to the four or five I've completed in the last week or so). The second half of "uname -s" would remain "_NT-4.0", or whatever the OS is supposed to be (could be "_Linux" or "_Solaris" for that matter). It would sure simplify a great deal in terms of determining, when porting software packages for Msys, what exactly should be done based on what is derived from uname -s without making the assumption that Mingw32 is the only compiler package that can be used for Msys. My understanding is that "ideally", Msys should not care which compiler/distro is being used. Defining "MINGW32" as first part of "uname -s" when a compiler/distro (which is _not_ the Mingw32 package) is being used within the Msys environment (eg. OpenWatcom, or the freely available "Borland" compiler). Paul G. |
From: Soren A <sor...@fa...> - 2002-09-19 06:09:27
|
I am glad this discussion is being held. In point of fact this was what I was trying to get at when I posted my article on Sep 10 "Subject: $build_os and other Autotools issues". I had in mind these "larger" issues but didn't know how to directly express them, and then the replies I got were immediately of a practical and mechanical nature, not discussed as connected in any way to "why" (theoretical or abstract-principles oriented) kinds of questions. "Luke Dunstan" <cod...@ho...> is the "alternate voice" in the quoted thread text which follows. "Paul G." <pga...@at...> wrote on Mon, 16 Sep 2002 04:37:26: >> > > > Hi folks, >> > > > >> > > > Just been reviewing uname and how it is being used for autoconfistication >> > > > (is that correct term? It's the thing where "uname" is invoked from >> > > > within a "./configure" script in order to determine which OS is actually running, eg: >> > > > ac_sys_system=`uname -s`)? "[a|A]utoconfiscation" (note the absence of a syllable present in what you wrote above) is the term used for a workflow or taskset in which a developer takes an existing package that does not presently have a GNU Autotools-based build configuration system and supplies one. It implies conversion from nothing or something other than a GNU Autotools build system, to an Autotools build system. People may sometimes speak of "autoconfiscating" a new package (that is just being written), for all I know. But I haven't seen it being used that way. What you are talking about is referred to as determining the canonical system type. It is a step that some but not all GNU Autotools -based configure scripts accomplish via the mechanism ('uname [arg]') you've cited. >> > > > I am not sure why MINGW32 is coming up as part of uname -s, >> > > > since MINGW32 is not really a "system". It is closer, at least >> > > > in my mind, to a type of build environment. The other half of >> > > > that ("_NT-4.0" in my case) is a system reference. As the rest of this thread has revolved around this question I will just note for completeness that as I see it, "MSYS" is the build environment and "MINGW[32]" is the *run-time* environment or "system" (the terminology offered elsewhere in the thread as clarification, involving "host" and "target" and "build", being crucial to bring up in making a complete clarification to you in the context of *nix-like 'configure' approaches). [Luke]: (no I am not quoting a book from the Bible ;-) >> > > The sole purpose of MSYS is to allow MinGW to be recognised as a >> > > host system by configure. That was well put. Without something that does what MSYS does, there would be (was) no way to get a portable, GNU-style 'configure' script to grasp what kind of system the software being configured was going to run on (except by difficult contortions involving Cygwin's shell that sometimes worked and sometimes didn't). By "system" we are talking about the C runtime library and so forth: the variable, platform implementation, vendor-specific "environment" that the binary executable we are going to generate will have to 'interact' with. {snip} >> > I think the confusion arises when I see Windows NT4 vs Mingw32. >> > Windows NT4 is an Operating System or System Platform, Mingw32 is not. Mingw32 >> >does, however, run on >> >an NT4 platform. Mingw32 is not a platform, is it? A not-merely-argumentative correction to your statement: "MinGW" applications do not *only* run (or build) on an NT4 platform. >> MinGW is a platform from the point of view of software, because it has >> a specific runtime library that is different from other Win32 >> platforms such as Cygwin. > > I agree. Mingw is a "software" platform. It is not, however, a > "system" platform. At this point Paul, you just became lost in semantic abstractions. The developers of MinGW can call/describe/label it whatever they want to, and the only thing that really matters from a practical perspective is that all the parties concerned agree on (and sufficiently possess) a common (shared) understanding of what constitutes MinGW. And when I say "can [...] whatever they want to" I actually mean *must*, not something like "because they worked long and hard they deserve to" or "it belongs to them so...". There IS no "norm" or "regular" here because MinGW was at its inception kind of unprecedented. Look, it's _all_ abstractions. MS *invented* something (made it up as they went along) when they chose to market multiple OS's all named "Windows [something]". Did they not?? Why not just release "Windows OS 5" and then "Windows OS 6" and so forth?? -- like another famous desktop Personal Computer company we must all be aware of. And as all or nearly all of us understand, the basic reason is marketing -- not engineering; only one major division really exists -- from an engineering perspective -- within currently-supported Windows platforms, and that's "NT-ish" or "Win9x-ish". MinGW[32] is about creating software that runs 'natively' on the *family* of related OSs released by MS that are called collectively inside that Company's documentation (such as SDKs) "Win32". 32-bit Windows. More specifically it is about C and C++ applications written (or ported) to run on those platforms (or _sub_-platforms if one wants to experiment with a slightly greater degree of semantic precision) without the use of any intervening, non-MS-produced C runtime library (like the Cygwin runtime or the MSYS runtime DLLs). So MinGW was unprecedented and MS makes it up as they go along and Windows [whatever] isn't in any case any variety of Unix; therefore in such a context of invention and null guidelines, it only seems fitting for MinGW to be seen as rightly empowered to make it up as it goes along too. It doesn't fit neatly into conventional categories and that's just fine. What matters is that it works ;-). >> From what little I know about this topic, this seems to be >> similar to other operating systems like Linux which have host strings >> something like "*linux*libc1" and "*linux*aout" for different >> runtimes. You could argue that we should use something like >> *-win32-mingw32 and *-win32-cygwin but it's a bit too late to make >> those sort of changes. I'll just mention that I recall that there was a time (and not really too long ago) when the string "mingw32-msvc" WAS something pertaining to what's being discussed here (configuring builds), broadly speaking. Maybe that was something that gcc itself spit out?? I hope someone will correct me if I am partly wrong (I am sure I am not completely wrong). The earliest MinGWs were linking to crt.dll, not msvcrt.dll. Then that was changed and everything new ported to MinGW or released as new versions of MinGW pieces was built with msvcrt.dll as the basis (C runtime library). After sufficient time passed that old versions of MinGW got 'purged' from users' systems (I am speculating that something along these lines was the thinking when this was discussed), there seemed no longer any need to say "mingw32-msvc" when there was just ONE "mingw[32]" and that was based on "msvc[rt.dll]". > Actually, that would be overkill, if I haven't already strayed in to > that particular territory. > > If there were any changes that I might argue for then it would be only to change > "MINGW32" to "Msys" or "Msystem" under "uname -s". I was wondering myself whether and/or when that was going to happen (as I indicated in my note at the top of this article). Now that I have seen the discussion unfold in this thread I understand (recall) why it doesn't and won't; with the exception of the special cases of certain tools discussed that needed it, all the software being ported to "MinGW[32]" links to msvcrt.dll and not to a special non-MS C runtime needed to provide functionality that's just missing on the Win32 - slash - msvc platform[s]. So now that Paul's floundering (sorry, couldn't resist, no offense <g>) has helped me get clear on the naming of things, I see no good reason for worrying about changing "mingw32" to something else. And I know of one good reason why any proposed "something else" mustn't be a string like "win32" in any case: MinGW32 (whatever it is ;-) owes a great deal to (and is named for) GNU, and RMS at GNU doesn't want GNU ("Free") software to refer to MS products -- platforms, OSs -- by using the string "win". Recent discussion regarding GNU 'make' will have been read elsewhere by some of the readers of this thread; I am referring to those discussions. I am not claiming that MinGW is GNU software in the sense of being official GNU software (it's not), but it is *related to* GNU by being based on tools that ARE official GNU packages. Such a thing as a debt of gratitude shouldn't be ignored. IMO. To the extent that reasonable expediency requires it, of course much work with MinGW has frequently used the string 'win' (as in '-DWIN32') and my point shouldn't be misconstrued as arguing that there's any need to retrace steps and go through some mind-bogglingly wasteful exercize of trying to get the string 'win' or 'WIN' removed from everything pertaining to MinGW. But I certainly wouldn't want (and see that it's not going to happen anyway) some newfangled host / build / target designations to be created in place of 'mingw32' that use "win32" or "win" in them. And BTW, it occurs to me that another reason to refrain from doing so might be to avoid business / legal 'namespace clash' with MS' own products. Hopefully all is clear now; and again, I am glad it came up. Best Regards, Soren A |
From: Paul G. <pga...@at...> - 2002-09-17 04:37:47
|
I'm sure someone may be thinking that I am simply talking/spouting nonsense. It's not nonsense to me. I am simply attempting to understand something. Forgive me if that is a problem. That said, I still have some unanswered questions related to uname, "host", "target", "build", etc. and have no idea where to find references, good reputable, standardized references to those terms. Appreciated your reply Luke. Gave me a better sense of what I am dealing with. Thanks. On 16 Sep 2002 at 8:18, Earnie Boyd wrote: > "Paul G." wrote: [snip] > > I am not sure why MINGW32 is coming up as part of uname -s, since MINGW32 is > > not really a "system". It is closer, at least in my mind, to a type of build environment. The > > other half of that ("_NT-4.0" in my case) is a system reference. > > > > Because that's the way I've designed MSYS. I was not questioning your design decisions. I was wondering how you arrived at the decision to use Mingw32 instead of Msys for the value produced when "uname -s" is invoked. > MSYS is the native > host/build system for mingw32. Ok, so Msys is the "host"/"build system" as opposed to mingw32 (which apparently is a "target"?)? If so, then Msys coincides with what Cygwin is. A "host"/"build system".. "build system" is somewhat confusing as well unless the assumption is that the "build system" is to be synonymous with "platform", which in this case, is clearly not to be considered synonymous with any "platform", ie. Msys is not NT4, Win2k, et. al. Even though it is designed to be used on NT4, Win2k, et. al. Mingw32 seems like it would only be a "build system" as opposed to a "host". Msys, however, could be, in my mind, considered a "host". Again, I am sure there is quite a bit I do not understand. I am simply attempting to establish some parameters to work with in terms of modifying ./configure scripts as the need arises to do so... > Therefore the configure system > understands that it is building the package for a native MINGW32 system. there is the confusion then. Mingw32 is not synonymous with "operating system". The actual (typical) configure script doesn't care about system except as it applies in terms of compiler runtime and setting the appropriate parameters (machine dependencies if they exist) for a particular OS. "Machine" is the same as Operating System. Or is it? What "operating system" in particular is being referenced when someone says a "native Mingw32 system"? NT4 is a clear reference to an "operating system". Considering that Mingw32 is considered a "target" for which someone on a Linux based platform can cross-compile from, I do not see how Mingw32 can be considered a "platform". Mostly because that which makes up "Mingw32" runs on an operating system/platform (eg. NT4, Win2k, Linux, etc.). Isn't the "host" MSYS and "Mingw32" only the "compiler package/distro" which is being assumed for Msys? I don't know. What happens if someone wants to use say OpenWatcom under Msys? It is not a Mingw32 system then, is it? It's still Msys, but it is not Mingw32. > > > Msys, on the other hand (Msys.tem?) seems to be more indicative of a "system" in > > the same sort of way that "Cygwin" is a "system". (Cygwin uname -s yields "Cygwin" as first > > six letters). From that standpoint, it almost seems more logical to have "uname -s" yield > > "Msys_NT-4.0" instead of "MINGW32_NT-4.0". > > > > Well, you have the power to do that now, but you won't be configuring > programs for MINGW32. Ok, so what you are saying is that Msys is Mingw32? > If you want configure to recognize what the > "package" is to be built for then I suggest you just leave it alone. So, uname -s is only supposed to give the "package" (eg. MINGW32), right? From uname --h: $ uname --h Usage: uname [OPTION]... Print certain system information. With no OPTION, same as -s. -a, --all print all information -m, --machine print the machine (hardware) type -n, --nodename print the machine's network node hostname -r, --release print the operating system release ^^^^ yields "1.0.8(0.46/3/2)" (Msys release version, not Mingw32 version) -s, --sysname print the operating system name ^^^^ yields "MINGW32_NT-4.0" (Mingw32 is not OS, NT4 is) -p, --processor print the host processor type -v print the operating system version ^^^^ yields date of Msys build (2002-09-07 16:04) --help display this help and exit --version output version information and exit Report bugs to <bug...@gn...>. [snip] > > Is there a predefined and undocumented limitation to how long the value of uname - > > s can be? > > > > I don't know. Ok. Thanks everyone. Paul G. |
From: Luke D. <cod...@ho...> - 2002-09-17 07:38:31
|
>From: "Paul G." <pga...@at...> >Reply-To: pga...@at... >To: min...@li... >Subject: Re: [Mingw-msys] uname question(s?) >Date: Mon, 16 Sep 2002 22:01:35 -0700 > >On 17 Sep 2002 at 12:29, Luke Dunstan wrote: > > > >From: "Paul G." <pga...@at...> > > >Reply-To: pga...@at... > > >To: min...@li... > > >Subject: Re: [Mingw-msys] uname question(s?) > > >Date: Mon, 16 Sep 2002 19:14:55 -0700 > > > [snip] > > > I think the confusion arises when I see Windows NT4 vs Mingw32. >Windows > > >NT4 is > > >an Operating System or System Platform, Mingw32 is not. Mingw32 does, > > >however, run on > > >an NT4 platform. Mingw32 is not a platform, is it? > > > > > > Paul G. > > > > MinGW is a platform from the point of view of software, because it has a > > specific runtime library that is different from other Win32 platforms >such > > as Cygwin. > > I agree. Mingw is a "software" platform. It is not, however, a "system" >platform. > Whether it is a "real" system platform is not relevant. The output of "uname" is set so that 'configure' knows that you are compiling software that will use the MinGW runtime. It is not there to tell you whether you are using MSYS or any other build environment. > > From what little I know about this topic, this seems to be > > similar to other operating systems like Linux which have host strings > > something like "*linux*libc1" and "*linux*aout" for different runtimes. >You > > could argue that we should use something like *-win32-mingw32 and > > *-win32-cygwin but it's a bit too late to make those sort of changes. > > Actually, that would be overkill, if I haven't already strayed in to that >particular >territory. > > If there were any changes that I might argue for then it would be only to >change >"MINGW32" to "Msys" or "Msystem" under "uname -s". > Again, you must be missing the point of MSYS. MSYS is just used as a build environment for a mingw32-hosted, mingw32-targetted compiler. The Mingw GCC is "mingw32-hosted" because it (GCC itself) is linked with the Mingw runtime (not any Cygwin or MSYS runtime). The Mingw compiler is "mingw32-targetted" because the programs it produces use the Mingw runtime. Since the host and target are the same, Mingw is a native compiler, as opposed to a cross compiler. MSYS is not a compiler. The exception to all this is the msysDVLPR package, which I won't try to explain further unless you understand 100% of what Earnie and I have said so far. [snip] > > My understanding is that "ideally", Msys should not care which >compiler/distro is >being used. Defining "MINGW32" as first part of "uname -s" when a >compiler/distro (which >is _not_ the Mingw32 package) is being used within the Msys environment >(eg. >OpenWatcom, or the freely available "Borland" compiler). > > Paul G. In the default MSYS configuration, Mingw *is* the *only* compiler that can be used. MSYS was designed just for this purpose, so if you are trying to use it for something beyond that, there are no guarantees. As Earnie said, if you must use MSYS with a compiler other than Mingw, you should change the MSYSTEM environment variable. This variable is not documented because it is sort of an "unsupported extension" that you should use only if you know what you are doing ;) If you have any further queries, try to formulate them as just questions and not an argument for how you think things should work. Luke _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
From: Paul G. <pga...@at...> - 2002-09-17 09:53:19
|
On 17 Sep 2002 at 15:38, Luke Dunstan wrote: [snip] > > > MinGW is a platform from the point of view of software, because it has a > > > specific runtime library that is different from other Win32 platforms > >such > > > as Cygwin. > > > > I agree. Mingw is a "software" platform. It is not, however, a "system" > >platform. > > > > Whether it is a "real" system platform is not relevant. The output of > "uname" is set so that 'configure' knows that you are compiling software > that will use the MinGW runtime. Then why the *heck* didn't anyone ever say anything about that to begin with? It would have saved a whole lot of time and energy for a whole lot of people. It seemed like a simple enough question, "What" or, more specifically, "Why" is the output of uname set to MINGW32_some-os? The answer, "it was designed that way..." *sigh* not... >... the output of > "uname" is set so that 'configure' knows that you are compiling software > that will use the MinGW runtime. ^^^^ Now that makes sense. [snip] > > The exception to all this is the msysDVLPR package, which I won't try to > explain further unless you understand 100% of what Earnie and I have said so > far. [snip] > > In the default MSYS configuration, Mingw *is* the *only* compiler that can > be used. I am aware of that. > MSYS was designed just for this purpose, I know that. It doesn't change the fact that some people have dreamed of an Msys that doesn't care which compiler is being used. > so if you are trying to > use it for something beyond that, there are no guarantees. That has always been the assumption as far as I am concerned. > As Earnie said, > if you must use MSYS with a compiler other than Mingw, you should change the > MSYSTEM environment variable. > This variable is not documented because it is > sort of an "unsupported extension" that you should use only if you know what > you are doing ;) ;) > If you have any further queries, try to formulate them as just questions and > not an argument for how you think things should work. Will keep that in mind...It is just funny how when I do formulate queries as "just questions" and not "what I think they should be" or "how I think things should work" I always end up causing more confusion than clarification. So much so that I end up, in the long run, redefining what were once "just questions" as "how I think something should work", which in turn causes some to think that I am trying to tell them what to do or, worse, I am trying to tell them how something should be done...and round and round it goes...*sigh*. Never ceases to amaze me. Anyway... Thanks Luke. Care to address the Msys Developer tool kit? (I have been using it extensively for my porting of various packages specifically for use in an Msys build environment) Paul G. |
From: Earnie B. <ear...@ya...> - 2002-09-17 12:16:08
|
"Paul G." wrote: > > Care to address the Msys Developer tool kit? (I have been using it extensively for > my porting of various packages specifically for use in an Msys build environment) > The msysDTK contains packages that aren't easily portable to native MSVCRT or do not function well with MSYS as a native MSVCRT binary but aid in development of software that does. The current invocation of msysDTK includes autoconf, automake, libtool and perl. The next invocation will also include guile and autogen. The msysDTK is dependent on the mingw-1.0.dll and the mingwDTK is dependent on MSVCRT.DLL. The current mingwDTK contain flex and bison. Earnie. |
From: Luke D. <cod...@ho...> - 2002-09-17 10:37:33
|
>From: "Paul G." <pga...@at...> >Reply-To: pga...@at... >To: min...@li... >Subject: Re: [Mingw-msys] uname question(s?) >Date: Tue, 17 Sep 2002 02:53:36 -0700 > >On 17 Sep 2002 at 15:38, Luke Dunstan wrote: > [snip] > > > > The exception to all this is the msysDVLPR package, which I won't try to > > explain further unless you understand 100% of what Earnie and I have >said so > > far. > [snip] > > Care to address the Msys Developer tool kit? (I have been using it >extensively for >my porting of various packages specifically for use in an Msys build >environment) > > Paul G. I assume you use the 'msysdvlpr' command whenever you begin using msysDVLPR. Judging by your earlier remarks, perhaps you didn't notice that when you are in this environment (with the white rxvt window), typing "uname -s" will print "MSYS_NT-5.0". The reason why the output of "uname" changes in these two environments is because you are using a different compiler: the msys compiler produces executables that depend on the MSYS DLL with all its POSIX emulation (and the compiler itself depends on the MSYS DLL), while the mingw32 compiler produces executables that just use MSVCRT.DLL (and the compiler is linked to MSVCRT). Perhaps the reason why your original question was not immediately answered in that way was because I/we knew that you have used msysdvlpr and assumed too much about your knowledge of uname/hosts/targets/etc. You can find the target of the compiler by typing "gcc -dumpmachine", but "configure" (actually config.guess) needs to use "uname" to find the host platform of the compiler. Anyway, if you pass the desired host as an argument to "configure", I believe it will not use "uname" at all. Luke _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
From: Paul G. <pga...@at...> - 2002-09-21 22:57:29
|
Hi folks, Last few days my email account was down. Pulled this from archives. > From: Soren A <soren_andersen@fa...> > Re: uname question(s?) > 2002-09-18 23:09 > > I am glad this discussion is being held. In point of fact this was what I > was trying to get at when I posted my article on Sep 10 "Subject: > $build_os and other Autotools issues". I had in mind these "larger" > issues but didn't know how to directly express them, and then the replies > I got were immediately of a practical and mechanical nature, not > discussed as connected in any way to "why" (theoretical or > abstract-principles oriented) kinds of questions. > > "Luke Dunstan" <coder_infidel@ho...> is the "alternate voice" in the > quoted thread text which follows. > > "Paul G." <pgarceau@at...> wrote on Mon, 16 Sep 2002 04:37:26: > >> > > > Hi folks, > >> > > > > >> > > > Just been reviewing uname and how it is being used for > autoconfistication > >> > > > (is that correct term? It's the thing where "uname" is invoked > from > >> > > > within a "./configure" script in order to determine which OS is > actually running, eg: > >> > > > ac_sys_system=`uname -s`)? > > "[a|A]utoconfiscation" (note the absence of a syllable present in what > you wrote above) is the term used for a workflow or taskset in which a > developer takes an existing package that does not presently have a GNU > Autotools-based build configuration system and supplies one. It implies > conversion from nothing or something other than a GNU Autotools build > system, to an Autotools build system. Ok. > > People may sometimes speak of "autoconfiscating" a new package (that is > just being written), for all I know. But I haven't seen it being used > that way. > > What you are talking about is referred to as determining the canonical > system type. It is a step that some but not all GNU Autotools -based > configure scripts accomplish via the mechanism ('uname [arg]') you've > cited. Thank you. That is what I was trying to get at, guess I couldn't quite "grok" it...thus the attempt to "grok"... > > >> > > > I am not sure why MINGW32 is coming up as part of uname -s, > >> > > > since MINGW32 is not really a "system". It is closer, at least > >> > > > in my mind, to a type of build environment. The other half of > >> > > > that ("_NT-4.0" in my case) is a system reference. > > As the rest of this thread has revolved around this question I will just > note for completeness that as I see it, "MSYS" is the build environment > and "MINGW[32]" is the *run-time* environment or "system" (the > terminology offered elsewhere in the thread as clarification, involving > "host" and "target" and "build", being crucial to bring up in making a > complete clarification to you in the context of *nix-like 'configure' > approaches). Ok. Will remember that as the *shared* understanding for as long as it works. It does work. > > [Luke]: (no I am not quoting a book from the Bible ;-) > >> > > The sole purpose of MSYS is to allow MinGW to be recognised as a > >> > > host system by configure. > > That was well put. Without something that does what MSYS does, there > would be (was) no way to get a portable, GNU-style 'configure' script to > grasp what kind of system the software being configured was going to run > on (except by difficult contortions involving Cygwin's shell that > sometimes worked and sometimes didn't). By "system" we are talking about > the C runtime library and so forth: the variable, > platform implementation, vendor-specific "environment" that the binary > executable we are going to generate will have to 'interact' with. Ok, so if I see MSYS_..., it is MSYS runtime we are talking about. If it is MINGW32_..., it is Mingw runtime we are talking about. Thank you for the clarification, Soren. > > {snip} > >> > I think the confusion arises when I see Windows NT4 vs Mingw32. > >> > Windows NT4 is an Operating System or System Platform, Mingw32 is not. > Mingw32 > >> >does, however, run on > >> >an NT4 platform. Mingw32 is not a platform, is it? > > A not-merely-argumentative correction to your statement: "MinGW" > applications do not *only* run (or build) on an NT4 platform. Accepted. I got it. Practically, I count on such corrections as, **"MinGW" applications do not *only* run (or build) on an NT4 platform.** Sometimes it is difficult, at best, to simply establish such corrections. > > >> MinGW is a platform from the point of view of software, because it has > >> a specific runtime library that is different from other Win32 > >> platforms such as Cygwin. > > > > I agree. Mingw is a "software" platform. It is not, however, a > > "system" platform. > > At this point Paul, you just became lost in semantic abstractions. Ok. Now I understand that, thanks to (and for) the non-argumentative-corrections. > > The developers of MinGW can call/describe/label it whatever they want to, > and the only thing that really matters from a practical perspective is > that all the parties concerned agree on (and sufficiently possess) a > common (shared) understa(nding)... Ok. It is that which is what I am trying to establish here, a common (shared) understanding... Thank you, Soren for your time on this. Paul G. |
From: Soren A <sor...@fa...> - 2002-09-23 10:29:24
|
"Paul G." <pga...@at...> wrote in news:3D8C96F7.29973.890FD6@localhost: > Ok, so if I see MSYS_..., it is MSYS runtime we are talking > about. If it is MINGW32_..., it is Mingw runtime we are talking > about. Yes, exactly. And very few things need to run with that MSYS runtime; only a few special tools that Earnie et al are finding cannot be made to port cleanly to standard (that's msvcrt-based) MinGW. AFAIK it was never the intention of MSYS to become what Cygwin is, a full-time intermediary layer to sit over the basic API of the Windows 32-bit OS's and allow many *nix applications to "think" they are running on some kind of real *nix. As I understand it, MSYS is more like the temporary construction scaffolding that you'll see erected at big building sites. Or like temporary structural support bracing. It gives access for certain tools or holds things up while the building is being put up but then is removed. UWIN is another thing that is what Cygwin is (and MSYS is not). Given that there are these very capable things out there already (and although I have not had a chance to play with UWIN yet, I think it can be assumed that it is VERY capably accomplished because it is written by David Korn of the Korn shell: a very skilled programmer). A very basic precept of Open-Source hacking is "do not re-invent the wheel". If these several projects (UWIN, Cygwin) are already occupying that particular niche, why (IMHO) try to develop MSYS into YAWPO (Yet Another Windows-32 Posix-Overlayer)? I got the sense from your words previously that you were envisioning things that way. >> The developers of MinGW can call/describe/label it whatever they >> want to, and the only thing that really matters from a practical >> perspective is that all the parties concerned agree on (and >> sufficiently possess) a common (shared) understa(nding)... > > Ok. It is that which is what I am trying to establish here, a > common (shared) understanding... > > Thank you, Soren for your time on this. You are very welcome ;-). One further thing I want to mention for the record, vis-a-vis my previous article (relevent portion not quoted here). I wrote that "MinGW is sort of unprecedented". That's not quite true and as I have also written recently about not neglecting to recognize debts of gratitude -- such as for way- pavers, those who have gone before -- I need to rectify: DJGPP came before MinGW and is in a sense a predecessor of it and of Cygwin. DJ Delorie is the Grandfather of both things, of nearly all that is GNU-liscious on win32. Regards, Soren A -- --*perlspinr*-- **Helping to consume excess Internet bandwidth since 1996** |