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@...> is the "alternate voice" in the
quoted thread text which follows.
"Paul G." <pgarceau@...> wrote on Mon, 16 Sep 2002 04:37:26:
>> > > > Hi folks,
>> > > >
>> > > > Just been reviewing uname and how it is being used for
>> > > > (is that correct term? It's the thing where "uname" is invoked
>> > > > 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
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
>> > > > 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" 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'
[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.
>> > I think the confusion arises when I see Windows NT4 vs Mingw32.
>> > Windows NT4 is an Operating System or System Platform, Mingw32 is not.
>> >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 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" and that was based on
> 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
> "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" 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.