[Mingw-users] Success building GCC 4.5.2 using only the msvcr100.dll runtime

[Khalid <kh...@ya...>]

It seems that I managed to build a three-stage gcc-4.5.2 compiler relying only
on the msvcr100 runtime. Even the built-in specs now default to using
moldname100 and msvcr100 as opposed to moldname and msvcrt.

The compiler suite included/includes patched mingwrt-3.18 code, w32api-3.17-2,
and code from gcc-g++-4.5.2, as well as gcc-core-4.5.2 together with the
prerequisite libraries for building gcc-4.5.2.

The compiler and its components seem to rely exclusively on msvcr100.dll,
whether they be executables (gcc, g++, collect2, etc.) or DLLs such as
libgcc_s_dw2-1.dll, and libstdc++-6.dll.

I am reporting this to put the word out that it can be done. 

I also wish to suggest the idea that maybe MinGW should release binary versions
of its shared libraries, namely libgcc_s_dw2-1.dll, and libstdc++-6.dll, that
rely on msvcr90.dll, and msvcr100.dll to help people who wish to link to these
libraries instead of the current MinGW default of msvcrt.dll.

These could be taken in the same vain as the Microsoft Visual C++
redistributable packages, only now they will be MinGW-X.Y.Z-redist-V90.tar.lzma,
and MinGW-X.Y.Z-redist-V100.tar.lzma and these would contain the shared
libraries mentioned above but ones that link exclusively with the V90, and V100
of the runtimes respectively. So when a programmer needs to distribute his code
in shared library form, she can bundle the required MinGW redistributable
according to her project needs.

It seems to me that in this way all licenses in question would be still
respected, as far as the MinGW project is concerned. Let programmers worry about
their license issues if MinGW's are sorted out. After all it is not beyond the
realm of possibilities that a group of programmers need to collaborate on a
project that owns a proper Visual C++ license but which relies on and requires
exclusive linking to something other than msvcrt.dll. Python comes to mind. It
seems to own a Visual C++ license and relies on the msvcr90.dll for proper
functioning of its core and extensions.

If this seems like a good idea, I'd be willing to contribute the DLLs I created
and, given enough time, would try to repeat the process for the shared libraries
that rely only on the msvcr9.dll


Regards,
Khalid