From: John E. <jo...@ti...> - 2011-04-27 06:57:11
|
I'm in the final stages of converting a large Linux app to run on Windows. Through personal preference I'm building with Visual C++ but I'd like to keep the source code so that it's still buildable with gcc - whether on Linux, Cygwin, MinGW or whatever. Linux and Cygwin aren't a problem because I have both at my disposal. However, I've no familiarity with MinGW so I wondered if someone can answer these questions..? They might seem a bit basic to you guys.... 1) Paths - when dealing with absolute paths, does mingw expect them to be in Windows format (with a drive letter at the start) - e.g. "C:\Documents and Settings\some_file". Or does it favour Linux/Cygwin style paths - e.g. "/usr/local/some_file". 2) Which of these is supported by mingw - fork() / exec() / spawn(). If not supported directly, are they supported by external libs? 3) Does mingw support the kind of functions commonly found in unistd.h - e.g. symlink() / readlink() / unlink() etc? Again, if not supported directly, are they supported by 3rd party libs. Thanks, John |
From: LRN <lr...@gm...> - 2011-04-27 07:32:11
|
On 27.04.2011 10:57, John Emmas wrote: > 1) Paths - when dealing with absolute paths, does mingw expect them to be in Windows format (with a drive letter at the start) - e.g. "C:\Documents and Settings\some_file". Or does it favour Linux/Cygwin style paths - e.g. "/usr/local/some_file". MinGW tools expect DOS-style paths (c:\windows\...). Msys tools expect *nix-style paths (/c/windows/... or /usr/local/...). Msys will watch process invocations by all Msys tools (including the shell) and will mangle the command line, substituting *nix-style paths for DOS-style paths (see [1] for details). Most (IME) *nix-originated autotools-using projects can not be compiled without using a shell, therefore some kind of Msys shell is mandatory (not sure about non-Msys shell implementations such as zsh), which means that path mangling will be involved. Otherwise (for projects that have their own custom-built Windows/MinGW makefiles or that use buildsystems capable of generating makefiles and that ship them) you might be able to compile with MinGW only and just stick to DOS-style paths everywhere. The programs compiled with MinGW expect DOS-style paths. > 2) Which of these is supported by mingw - fork() / exec() / spawn(). If not supported directly, are they supported by external libs? fork() is not supported exec() is supported by MS C Runtime (though there are differences between POSIX exec() and MSVCR exec()) spawn() is supported by MS C Runtime (again, there are differences) "MS C Runtime" here means that MinGW doesn't have to do anything to support these, they are just forwarded to MSVCR*. > 3) Does mingw support the kind of functions commonly found in unistd.h - e.g. symlink() / readlink() / unlink() etc? Again, if not supported directly, are they supported by 3rd party libs. See [2] for a very recent discussion related to symlinks. In addition: Neither MinGW nor Msys tools support symlinks. Also, since both link to msvcrt instead of msvcrtXX, they, in some cases, might not work with symlinks transparently as you would have wanted. Or might work with symlinks transparently as you would have not wanted. For example: rm -rf /somedir will delete somedir and all of its contents. Even if /somedir is a symlink to c:\foodir. Which means that c:\foodir will be empty after that. Or this: If you symlink /mingw/lib/libws2_32.a to C:\Windows\System32\ws2_32.dll (gcc can link to DLLs directly, but this requires altering library-finding logic; by linking ortodox library names, such as lib/libfoo.dll.a or lib/libbar.a to actual DLLs you can have direct linking without hacking anything), binutils might think that libws2_32.a has size = 0, because stat() from non-symlink-aware msvcrt will say so. Some of that changes if you compile against msys-1.0.dll, but that is for Msys tools only, and if you want to go that far, you'd be better off with Cygwin. [1] http://www.mingw.org/wiki/Posix_path_conversion [2] http://comments.gmane.org/gmane.comp.gnu.mingw.user/36205 |
From: Earnie <ea...@us...> - 2011-04-27 11:50:49
|
LRN wrote: > If you symlink /mingw/lib/libws2_32.a to C:\Windows\System32\ws2_32.dll > (gcc can link to DLLs directly, but this requires altering > library-finding logic; by linking ortodox library names, such as > lib/libfoo.dll.a or lib/libbar.a to actual DLLs you can have direct > linking without hacking anything), binutils might think that libws2_32.a > has size = 0, because stat() from non-symlink-aware msvcrt will say so. > Binutils will find ws2_32.dll if you include -L c:\Windows\System32 (or whatever the directory name is on your PC) in the link command when you specify -lws2_32 so there is no need to create this reparse point. -- Earnie -- http://www.for-my-kids.com |
From: LRN <lr...@gm...> - 2011-04-27 12:46:48
|
On 27.04.2011 15:50, Earnie wrote: > LRN wrote: >> If you symlink /mingw/lib/libws2_32.a to C:\Windows\System32\ws2_32.dll >> (gcc can link to DLLs directly, but this requires altering >> library-finding logic; by linking ortodox library names, such as >> lib/libfoo.dll.a or lib/libbar.a to actual DLLs you can have direct >> linking without hacking anything), binutils might think that libws2_32.a >> has size = 0, because stat() from non-symlink-aware msvcrt will say so. >> > Binutils will find ws2_32.dll if you include -L c:\Windows\System32 (or > whatever the directory name is on your PC) in the link command when you > specify -lws2_32 so there is no need to create this reparse point. > Would it find it have priority over libws2_32.a (or libws2_32.dll.a, which doesn't exist, but let's suppose it does). |
From: Earnie <ea...@us...> - 2011-04-27 14:35:48
|
LRN wrote: > On 27.04.2011 15:50, Earnie wrote: >> Binutils will find ws2_32.dll if you include -L c:\Windows\System32 (or >> whatever the directory name is on your PC) in the link command when you >> specify -lws2_32 so there is no need to create this reparse point. >> > Would it find it have priority over libws2_32.a (or libws2_32.dll.a, > which doesn't exist, but let's suppose it does). See http://sourceware.org/binutils/docs/ld/WIN32.html (section: "direct linking to a dll") It would find ws2_32.dll in the c:\windows\system32 directory first and use that instead of the c:\mingw\lib\libws2_32.dll.a because -L c:\windows\system32 is searched for libraries first. Otherwise if an import interface file exists in the directory with the DLL it will prefer the interface file. The library file order in the directory search paths is as follows. Once it finds the library the search for the library ceases so that the first one found is used. libxxx.dll.a xxx.dll.a libxxx.a xxx.lib <prefix>xxx.dll (*) libxxx.dll xxx.dll (*) Replace <prefix> with what ever you specify with --dll-search-prefix. If no --dll-search-prefix is given then none is search for. -- Earnie -- http://www.for-my-kids.com |
From: John E. <jo...@ti...> - 2011-04-27 07:47:36
|
Many thanks for that comprehensive reply. Up until now I've assumed from various things I've read that mingw apps are closer to Windows apps whereas Cygwin apps are closer to *nix apps. i.e. mingw apps won't support fork(), won't support symlink() etc and will tend to work with Windows style paths. Fortunately, it looks like I've been doing the right things so far, but I thought I'd better check! John |
From: John E. <jo...@ti...> - 2011-04-27 07:50:50
|
Of course, MinGW apps and Cygwin apps ARE Windows apps - but you probably knew what I meant.... :-) |
From: Chris W. <ch...@qw...> - 2011-04-27 07:53:26
|
Hi John, On Wed, 27 Apr 2011, John Emmas wrote: > I'm in the final stages of converting a large Linux app to run on > Windows. Through personal preference I'm building with Visual C++ but > I'd like to keep the source code so that it's still buildable with gcc - > whether on Linux, Cygwin, MinGW or whatever. > > Linux and Cygwin aren't a problem because I have both at my disposal. > However, I've no familiarity with MinGW so I wondered if someone can > answer these questions..? They might seem a bit basic to you guys.... > > 1) Paths - when dealing with absolute paths, does mingw expect them to > be in Windows format (with a drive letter at the start) - e.g. > "C:\Documents and Settings\some_file". Or does it favour Linux/Cygwin > style paths - e.g. "/usr/local/some_file". > > 2) Which of these is supported by mingw - fork() / exec() / spawn(). > If not supported directly, are they supported by external libs? > > 3) Does mingw support the kind of functions commonly found in unistd.h > - e.g. symlink() / readlink() / unlink() etc? Again, if not supported > directly, are they supported by 3rd party libs. MinGW, unlike Cygwin, is NOT a compatibility layer. It is a different compiler, that's all. So the answer to all the above questions is "if and only if it works with msvcrt.dll" and therefore "ask MSDN". The questions that might help you more are like this: * Does your app compile and run with the original MSVCRT C library? * Does it use any non-standard MSVC preprocessor syntax? * Does it use any MSVC #defines to build on Windows? * Does it use MFC or ATL? (neither are supported using MinGW as far as I know) * Does it have a Makefile? * Have you actually tried to compile it with MinGW gcc.exe instead of cl.exe to see what happens? * How do you deal with the lack of fork(), symlink() and readlink() when compiling with MSVC? The same should apply to MinGW. Cheers, Chris. |
From: John E. <jo...@ti...> - 2011-04-27 10:00:42
|
Thanks Chris. That's a long list of questions so just FYI.... > * How do you deal with the lack of fork(), symlink() and readlink() when > compiling with MSVC? The same should apply to MinGW. > For symlink() and readlink() I've provided my own approximations. For fork()/exec() I've substituted spawn(). It seems like spawn() would be the correct way to go for MinGW too, although I now suspect that the app wouldn't build under MinGW for other reasons, namely.... > * Does it have a Makefile? > No. The original build system was scons. > * Does it use MFC or ATL? (neither are supported using MinGW as far as I > know) > That's quite interesting... The app I'm talking about is Ardour and I do know that others have tried building it with MinGW (unsuccessfully, from what I can gather). It does use ATL quite extensively, so maybe that was the problem. > * Does your app compile and run with the original MSVCRT C library? > No. I'm using MSVC 8.0. Just out of interest, why is MinGW sticking with the old CRT from MSVC 6.0? Is it just tradition? Contrary to popular belief, newer versions of MSVC are much more standards compliant (in certain areas, anyway - one of which is ATL). There's still very little C99 support of course but CRT 8.0 and later are light years ahead of version 6.0. Is that the kind of move that would benefit MinGW? Or even be practical?? John |
From: Tor L. <tm...@ik...> - 2011-04-27 10:38:14
|
(This response is just my educated guess, I am not a MinGW maintainer) > Just out of interest, why is MinGW sticking with the old CRT from MSVC 6.0? msvcrt.dll is not "from MSVC 6.0". That is just FUD. msvcrt.dll is shipped as a new version with each version of the Windows OS, and exists even as a 64-bit version on 64-bit Windows. If it was "from MSVC 6.0" that would hardly be the case, would it? > Is it just tradition? Partly yes, and maybe because people haven't contributed suitably clean-room-engineered and suitably licensed headers to match the other runtimes. Also 1) it is "good enough" in many (most?) cases. Much of the new and additional stuff in the newer MSVC-version-specific CRTs are, well, compiler-specific anyway, 2 ) It makes it so much easier to distribute MinGW-built software as you don't have to distribute a MSVC-version-specific CRT with your software (if that would even be allowed by its license, always an interesting question), or instruct the end-user where to get them, If msvcrt.dll was "obsolete", why would Microsoft keep using it themselves for stuff like notepad and other applications that are part of the OS? --tml |
From: Chris W. <ch...@qw...> - 2011-04-27 10:45:46
|
Hi John, On Wed, 27 Apr 2011, John Emmas wrote: >> * Does your app compile and run with the original MSVCRT C library? >> > No. I'm using MSVC 8.0. Just out of interest, why is MinGW sticking > with the old CRT from MSVC 6.0? Is it just tradition? Contrary to > popular belief, newer versions of MSVC are much more standards compliant > (in certain areas, anyway - one of which is ATL). There's still very > little C99 support of course but CRT 8.0 and later are light years ahead > of version 6.0. Is that the kind of move that would benefit MinGW? Or > even be practical?? More information about why MSVC 6.0 and MSVCRT are still popular, and the problems with manifests and redistributables, is available here: http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/ Cheers, Chris. |
From: John E. <jo...@ti...> - 2011-04-27 14:43:51
|
On 27 Apr 2011, at 11:00, John Emmas wrote: > The app I'm talking about is Ardour and I do know that others have tried building it with MinGW (unsuccessfully, from what I can gather). It does use ATL quite extensively, so maybe that was the problem. > Oops, how silly of me... Ardour uses STL of course, not ATL. I'm forever getting them mixed up! I just took a look at the T&C's for Microsoft's Redistributable packages. It seems that anyone is allowed to download them for personal usage but if you aren't covered by an alternative license (e.g. the one for Visual Studio) you aren't permitted to download them for commercial gain. So MinGW is probably wise to stick with MSVCRT.dll and its contemporaries. I guess it'll be around for some time to come but surely a day will come when Windows starts shipping without it. Is there a case for MinGW to develop its own CRT library, rather than continuing its dependence on Microsoft? I guess malloc() and stuff would be quite difficult without some reliance on Microsoft's CRT? John |
From: LRN <lr...@gm...> - 2011-04-27 15:13:37
|
On 27.04.2011 18:43, John Emmas wrote: > Is there a case for MinGW to develop its own CRT library, rather than continuing its dependence on Microsoft? I guess malloc() and stuff would be quite difficult without some reliance on Microsoft's CRT? On Dec 29 2010 in #mingw-w64 @ irc.oftc.net i've had this conversation (not a quote, slightly edited typos and conversation flow): * vityan * I have plans to make more real-libc for Mingw-W64 and will base it upon FreeBSD's libc 7.0 runtime library code due to its license(and quite good functionality). * NS_mb * look at ironcrate in our repo * NS_mb * Kai started on a libc for windows * NS_mb * afaik, from scratch * vityan * Hmmm... I see - it's almost empty * LRN * You can easily get libc routines that work with strings, math and stuff from other OSes. But I/O, processes and other things are OS-dependent, you'll have to re-implement all that on top of WinAPI and/or Native API * LRN * Because on Linux libc will often just make a syscall - and that's it * vityan * LRN - most of the stuff(stdio,buffer copying and other) can be written in C/asm. OS related stuff(mainly *NiX syscalls) will be replaced by Native NT API. I'll avoid Win32 API in my libc * vityan * I also plan to provide native fork which is not part of MS C runtime nor the Win32 API. * LRN * Well, good luck. I'll certainly appreciate a free-software C runtime library for NT * NS_mb * vityan: feel free to contribute to ironcrate :) * vityan * As ironcrate is almost empty it's more willing to continue on my wlibc :D * vityan * My base is BSD's libc so it will progress my better(lots of stuff already present under liberal license) * vityan * I hope i'll not need to use init code from... libcmt sources :( * vityan * iconv should be integrated into libc to provide independent locale support * vityan * in will be one libc.dll library * vityan * + libm.dll and possibly ported libdl * vityan * Main goal is to implement basic libc with support to all funcs included in latest MSVCR runtime. Later various devs can be interested in extending it and adding some POSIX stuff as OPTIONAL extension. * vityan * Posix extension will allow creation of cygwin64/msys64 based on it but that will not happen any time soon(and i'm quite limited in time actually) for Ironcrate see [1] Haven't heard about this from him since. But he's still around (last seen ~2 weeks ago). Also, some years ago (don't remember the date) i've asked a ReactOS dev .... KJK::Hyperion, if i remember correctly, about CRT, and he said that ReactOS will have to implement its own C Runtime eventually. Obviously, no one knows when that "eventually" will be. It should be noted that MinGW cites its reliance on msvcrt as an advantage (links to msvcrt, which is already available, as opposed to Cygwin, which dooms applications to carrying cygwin-1.dll around). Not sure if they will gladly give it up. [1] http://sourceforge.net/apps/trac/mingw-w64/wiki/libw64crt%20Documentation |
From: Earnie <ea...@us...> - 2011-04-27 15:21:34
|
> On 27.04.2011 18:43, John Emmas wrote: >> Is there a case for MinGW to develop its own CRT library, rather than continuing its dependence on Microsoft? I guess malloc() and stuff would be quite difficult without some reliance on Microsoft's CRT? No, it isn't our purpose. However, if you find an alternative you can use it instead. Keith has already pointed to a wiki document on changing the GCC specs file. -- Earnie -- http://www.for-my-kids.com |
From: Earnie <ea...@us...> - 2011-04-27 15:17:09
|
John Emmas wrote: > I just took a look at the T&C's for Microsoft's Redistributable packages. It seems that anyone is allowed to download them for personal usage but if you aren't covered by an alternative license (e.g. the one for Visual Studio) you aren't permitted to download them for commercial gain. So MinGW is probably wise to stick with MSVCRT.dll and its contemporaries. I guess it'll be around for some time to come but surely a day will come when Windows starts shipping without it. Is there a case for MinGW to develop its own CRT library, rather than continuing its dependence on Microsoft? I guess malloc() and stuff would be quite difficult without some reliance on Microsoft's CRT? They would have to rewrite the whole of the Windows API to get rid of MSVCRT.DLL. I don't think they would think it wise to do that. It sure makes no business sense. MSVCRT.DLL is not the old CRTDLL.DLL and rather stands for MicroSoft Visual C RunTime which can be any version of Visual C distributed with the OS Version. The newer the OS the newer the MSVCRT version is used. For an interesting read take a look at the output of ``objdump -x $SYSTEMROOT/system32 | less''. -- Earnie -- http://www.for-my-kids.com |
From: Earnie <ea...@us...> - 2011-04-27 14:54:35
|
John Emmas wrote: >> * Does it use MFC or ATL? (neither are supported using MinGW as far as I >> know) >> > That's quite interesting... The app I'm talking about is Ardour and I do know that others have tried building it with MinGW (unsuccessfully, from what I can gather). It does use ATL quite extensively, so maybe that was the problem. > I suggest you search the net for mingw+atl. OpenOffice for instance deals with the lack of ATL in MinGW. And I find attempts to port WTL, a ATL drop-in replacement, to MinGW. -- Earnie -- http://www.for-my-kids.com |
From: LRN <lr...@gm...> - 2011-04-27 10:12:28
|
On 27.04.2011 14:00, John Emmas wrote: >> * Does it have a Makefile? > No. The original build system was scons. Scons works well enough with MinGW. You just have to force it to use mingw toolchain (on Windows it will look for MSVC toolchain by default). >> * Does it use MFC or ATL? (neither are supported using MinGW as far as I >> know) > That's quite interesting... The app I'm talking about is Ardour and I do know that others have tried building it with MinGW (unsuccessfully, from what I can gather). It does use ATL quite extensively, so maybe that was the problem. Probably. >> * Does your app compile and run with the original MSVCRT C library? > No. I'm using MSVC 8.0. Just out of interest, why is MinGW sticking with the old CRT from MSVC 6.0? Is it just tradition? Contrary to popular belief, newer versions of MSVC are much more standards compliant (in certain areas, anyway - one of which is ATL). There's still very little C99 support of course but CRT 8.0 and later are light years ahead of version 6.0. Is that the kind of move that would benefit MinGW? Or even be practical?? msvcrt was used because it isn't affected by XML manifests and SxS madness, AFAIR. msvcr100 (which isn't affected by these things as well) might be used instead in future, see [1] [1] http://comments.gmane.org/gmane.comp.gnu.mingw.user/36183 |
From: John E. <jo...@ti...> - 2011-04-27 10:23:40
|
On 27 Apr 2011, at 11:11, LRN wrote: > msvcrt was used because it isn't affected by XML manifests and SxS > madness, AFAIR. msvcr100 (which isn't affected by these things as well) > might be used instead in future, see [1] > > [1] http://comments.gmane.org/gmane.comp.gnu.mingw.user/36183 > That seems like it would be a useful step forward. I hope it works out okay if the MinGW team decides to go down that route. John |
From: Keith M. <kei...@us...> - 2011-04-27 11:13:12
|
On 27 April 2011 11:23, John Emmas wrote: > On 27 Apr 2011, at 11:11, LRN wrote: > >> msvcrt was used because it isn't affected by XML manifests and SxS >> madness, That isn't the reason, at all. See Tor Lillqvist's comment regarding your original misconception of the relationship between MSVCRT.dll and any particular version of MSVC. MinGW uses MSVCRT.dll because it is a fundamental component of the operating system; therefore, its use is permitted by the GPL -- GCC, on which MinGW is founded is a GPL tool chain. Although you are entitled to distribute MinGW built applications without them being constrained by the GPL, we are not entitled to distribute non-free components as part of the tool chain itself. MSVCR[67891]*.dll are NOT fundamental OS components. IIRC, they are not even redistributable, unless you are building your code with MSVC, and you have PURCHASED an MSVC licence from Microsoft. Thus, we CANNOT legally (AIUI: IANAL) make MinGW in any way dependent on any of them. >> AFAIR. msvcr100 (which isn't affected by these things as well) >> might be used instead in future, ... >> > That seems like it would be a useful step forward. I hope it works > out okay if the MinGW team decides to go down that route. It's hardly likely. That would fall under the same licensing restriction as any of the other MSVCR[6789]*.dll variants, AFAICT. YOU are welcome to deploy code which depends on these more restrictively licensed MSVCR*.dll variants, but the responsibility for ensuring proper licence compliance is yours; it isn't our responsibility to police it. If you wish to follow that path, see: http://www.mingw.org/wiki/SpecsFileHOWTO (in particular, my comments below the main article). -- Regards, Keith. |
From: LRN <lr...@gm...> - 2011-04-27 22:32:49
|
On 27.04.2011 15:13, Keith Marshall wrote: > On 27 April 2011 11:23, John Emmas wrote: >> On 27 Apr 2011, at 11:11, LRN wrote: >> >>> msvcrt was used because it isn't affected by XML manifests and SxS >>> madness, > That isn't the reason, at all. > > See Tor Lillqvist's comment regarding your original misconception of the > relationship between MSVCRT.dll and any particular version of MSVC. > > MinGW uses MSVCRT.dll because it is a fundamental component of the > operating system; therefore, its use is permitted by the GPL -- GCC, on > which MinGW is founded is a GPL tool chain. Although you are entitled > to distribute MinGW built applications without them being constrained by > the GPL, we are not entitled to distribute non-free components as part > of the tool chain itself. > > MSVCR[67891]*.dll are NOT fundamental OS components. IIRC, they are not > even redistributable, unless you are building your code with MSVC, and > you have PURCHASED an MSVC licence from Microsoft. Thus, we CANNOT > legally (AIUI: IANAL) make MinGW in any way dependent on any of them. These are the terms for MSVCR100 (partially, open up vcredist_ARCH.exe in 7zip to find the whole EULA): You may not • disclose the results of any benchmark tests of the software to any third party without Microsoft’s prior written approval; • work around any technical limitations in the software; • reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation; • make more copies of the software than specified in this agreement or allowed by applicable law, despite this limitation; • publish the software for others to copy; • rent, lease or lend the software; • transfer the software or this agreement to any third party; or • use the software for commercial software hosting services. Well, you can't redistribute vcredist without a special license, but that's old news. Downloading it from MS is a burden, but not an obstacle. All other terms do not apply (directly) to MinGW, as far as i've been able to learn (IANAL, obviously, but regarding 'commercial software hosting' there was an answer on MS forum from MS employee, and it says that this youmaynot refers to redistribution). As for GPL restriction on not using proprietary components - except when they are normal part of the OS, here's what is in GPLv2 on this: ...need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. GPLv3: The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. For reference: Windows 7 Ultimate x86 comes with these pre-installed: msvcr90 (SxS) msvcr80 (SxS) msvcrt40 msvcrt40 (SxS) msvcrt20 msvcrt20 (SxS) msvcrt msvcrt (SxS) Updates (even SP1) don't seem to bring anything newer (although "newer" here is msvcr100, which will probably only come in with SP2 or Windows 8) Windows XP Pro SP3 comes with these pre-installed: msvcrt40 msvcrt20 msvcrt msvcrt (SxS) MSVCR70 (not pre-installed, but it comes with .NET 1.1, which is bundled on XP Pro CD, not sure if that counts). Updates (updates only, no new IE or tools) will bring you: msvcr71 (as part of .NET 1.1 SP1 update, i think) And, of course, you'd get all relevant versions of msvcrXX with any of MS compiler suites. So, obviously, msvcrXX doesn't qualify as a system library neither by GPLv2, nor by GPLv3 standards. Although IANAL. |