Originally posted by yogi_berra
View Post
I'm not sure how static linking would work, but definitely for dynamic linking, you can download msvcrt.dll (or whatever) from Microsoft and link against that using the GNU linker `ld' provided by MinGW.
Also, if there were a licensing issue, then nobody would be able to distribute binaries compiled by MinGW, yet there are many small and large businesses that shamelessly do so. Are all of them violating the GPL?
I don't think so, especially if they dynamically link, because what GPL3 code is there involved?
Step 1: I write my own code. I can license it however I want.
Step 2: I use MinGW to compile it. MinGW links it against the native Microsoft libraries such as msvcrt.
Step 3: I distribute my binary. The binary contains code linking against Microsoft libraries and it contains my own code, which is under any license I want as long as it doesn't contradict Microsoft's license agreement for linking with their libs.
Where's the GPLv3 code? GNU and FSF explicitly say that their compilers can produce binaries under any license you want, and you are only restricted in the choice of license if your binary contains object code from GPLed libraries (which is a completely separate concept than the license of the compiler / linker stack). So for a silly example, if you had a C library licensed under a license that only allows you to run the code on a satellite in space, you could legally produce dynamic or static binaries using gcc and this C library, and you'd only be bound by the restrictions of that C library's license and any other object code that is dynamically or statically linked to your code. The license of the compiler infrastructure intentionally does not touch the license of the produced binaries, any more than encoding MP3s with LAME means that you have to license them under the GPL, or that producing .odt files with OpenOffice means that you have to license them under the GPL.
You must be thinking of Cygwin, which ships its own C library and links against a Windows emulation of libc and libstdc++, etc. and emulates POSIX calls like fork() and exec().
AFAIK the only purpose of MinGW's Win32 API libraries (both static and dynamic) is to give GCC and the linker sufficient information to produce a binary that, at runtime actually does link against Microsoft's implementation.
Lending credibility to this idea is the file size of even the static archives (.a files) of Win32 libs in MinGW: they're a couple kilobytes apiece. No way you can implement all of the win32 API in a megabyte or two.
Also, if some company writes a library that you want to link against your MinGW executable, and they link against the MSVC libraries, you can still link their library into your MinGW-produced executable.
There are some technical complexities as detailed at http://www.mingw.org/wiki/MixingCompilers but these can be overcome, as the article suggests.
Comment