For some reason this hasn't appeared on the mailing list, nor in the
archive. Please forgive any duplication.
On 17 Mar 2001, at 16:34, the Illustrious Charles S. Wilson wrote:
[skip]
...the question that precipitated Paul's [S] response was *precisely*
>
about the use of mingw as a 'lightweight cygwin'. I am attempting to >
uncover the "proper" way on a *cgywin* system to install so-called >
"mingw" libs -- that is, static and dynamic libraries compiled by gcc
on
> Windows that depend on the crt and/or msvcrt runtimes. This
information > is needed in order to get *cygwin's* 'gcc -mno-cygwin'
version of the > "mingw" compiler to operate correctly.
[The focus of this email is two-fold, as noted in the Subject field,
and is meant as a General Statement about the differences between Mingw
and Cygwin. Furthermore, this post to the mailing list is also meant
to
answer the question about where the Mingw libraries, etc. should go
according to agreements between the Mingw developers, who supply most,
if not all of the Mingw related updates, for the Cygwin CVS repository,
and the Cygwin CVS repository maintainer(s)].
The Cygwin specs file, when -mno-cygwin is invoked, actually
looks/adds "usr/local/lib/mingw" and "usr/lib/mingw" to the library
search (-L). Mingw specific libraries are expected to be located/found
on the Cygwin mounts noted above.
Cygwin is set up to facilitate mingw (through the use of the -mno-
cygwin switch, msvcrt and crtdll notwithstanding) using the cygwin
mount
table(s).
You can even generate libstdc++ libraries if you wish, using the -mno-
cygwin switch, since the libstdc++ source code is still in C language.
All you need to do is get the libstdc++ source, compile it using -mno-
cygwin, "et voila" -mno-cygwin C++ libs.
Of course, the most effective thing to do is to simply compile and
link
your libstdc++ librar(ies) using Mingw (modify automake/autoconf files)
as a standalone development environment and then copy the resulting
libstdc++ static libs to the appropriate location(s) within the Cygwin
environment.
The Cygwin "-mno-cygwin" switch ("-mno-cygwin" does not exist for Mingw
gcc).
Cygwin gcc -mno-cygwin is the same as telling Cygwin gcc to use the
"specs" defined for Mingw runtime/libraries.
[For more on specs, see the Cygwin specs file:
(<cygwin drive>/lib/gcc-lib/i686-pc-cygwin/<gcc-version>/specs)]
So, when you use the gcc -mno-cygwin switch, all you are really
telling the Cygwin environment to do is to change your compiled binary
to be compatible with a development environment that doesn't use or
require the inclusion of the cygwin1.dll.
The decisive advantage of using -mno-cygwin under the Cygwin
Development Environment is that you no longer need to rely on the
cygwin1.dll to be present for your gcc/g++ compiled/linked app to run,
win32api notwithstanding.
What is typically _not said_ is that if you _do_ decide to use the
newly added (relatively speaking) -mno-cygwin switch, you are, in fact,
invoking the Mingw specific headers and runtime libraries..._not_ the
Cygwin specific headers and runtime libraries. "Shell" and Cygwin
specific binutils (those which require cygwin1.dll) run as they always
have.
In other words, if you download all of the Cygwin Development Tools,
you are actually downloading two different development environments,
the
Mingw (-mno-cygwin) environment and the Cygwin environment.
The only thing that ties the two environments together at all is that
they both use a form of Gnu C/C++.
A brief Mingw history lesson:
Mingw, in one of its earliest forms, was actually built using the
Cygwin development environment (b17-b18, aka EGCS?). I recall well the
amount of messages that went through the Cygwin mailing list which were
related to what we now call, Mingw (formerly "Minimalist [Gnu Compiler]
for Win32 based platforms", or simply put "MinGW32").
Later, as more and more people began to see the advantages of using a
a
"minimalist version" of gcc/g++ for win32 vs. the resource heavy
version
of gcc/g++ typical for Cygwin, even today. It was then that Mingw
began
its aging process.
Today, there are over 500 people who are interested enough to keep
their names on the Mingw-users mailing list (message bounces are
extremely rare).
What you see today at the Official Mingw Homepage
(http://www.mingw.org) and at the SourceForge Project Site for Mingw
(https://sourceforge.net/projects/mingw/), is the latest evolution of
"Minimalist Gnu C/C++ Standalone Development Tools/Environment For A
Win32 Based API" (that was the long form of the term, "Mingw").
Any changes that occur to the Mingw source tree are, especially in the
areas of the Win32api and Mingw runtime patches, manually added to the
Cygwin CVS repository by the Mingw Volunteer Developers.
In closing, I would like to say that this post to the mingw-users list
is specifically meant to clarify the boundaries between Mingw and
Cygwin. I can only hope that in some small way I have succeeded in
this
rather large task.
Thank you, everyone, for your time and patience on this.
Peace,
Paul G.
Nothing real can be threatened.
Nothing unreal exists.
|
