From: Daniel J. <dr...@fa...> - 2010-02-15 00:04:18
|
I've been trying to build an application (GDB, in this case, with Python enabled) that links to MSVCR90.DLL instead of MSVCRT.DLL. I can't, and I have the same problem with a trivial program that calls fstat. DLL Name: msvcr90.dll vma: Hint/Ord Member-Name Bound-To 5120 32 _fstat If I take the linker command and replace -lmoldname with -lmoldname90 and -lmsvcrt with -lmsvcr90, then I get a binary that links successfully but fails to run. If I'm logged in to a console I get a popup saying that it's trying to resolve _fstat in msvcr90.dll, and failing. I'm not a PE expert, but it looks to me like that's exactly what libmoldname90.a is doing: an import stub for _fstat that references msvcr90.dll. Is this mingw's fault - incomplete support for 9.0 runtime, maybe? It looks to me like something should be redirecting the call to _fstat32 or _fstat64 instead (or _fstat32i64 or _fstat64i32). I don't see anything in the mingw libraries or headers to do that. -- Daniel Jacobowitz CodeSourcery |
From: Daniel J. <dr...@fa...> - 2010-02-15 01:10:58
|
On Sun, Feb 14, 2010 at 06:44:46PM -0500, Daniel Jacobowitz wrote: > Is this mingw's fault - incomplete support for 9.0 runtime, maybe? It > looks to me like something should be redirecting the call to _fstat32 > or _fstat64 instead (or _fstat32i64 or _fstat64i32). I don't see > anything in the mingw libraries or headers to do that. Eventually I found: http://sourceforge.net/tracker/index.php?func=detail&aid=2134161&group_id=2435&atid=302435 Apparently there's been a number of attempts to fix this, but none merged. [I've gotta say, it's unfortunate from where I sit that the answer requires recompilation and not just relinking... would a wrapper function named _fstat in libmoldname90.a have killed anyone? This means that when building an ar archive library I already have to know which CRT library it will link to.] -- Daniel Jacobowitz CodeSourcery |
From: Chris S. <ir0...@gm...> - 2010-02-15 14:02:00
|
Hi Daniel, >> Is this mingw's fault - incomplete support for 9.0 runtime, maybe? It >> looks to me like something should be redirecting the call to _fstat32 >> or _fstat64 instead (or _fstat32i64 or _fstat64i32). I don't see >> anything in the mingw libraries or headers to do that. > > Eventually I found: > > http://sourceforge.net/tracker/index.php?func=detail&aid=2134161&group_id=2435&atid=302435 > > Apparently there's been a number of attempts to fix this, > but none merged. Thank you for reviving this discussion. I have updated the patch so that it applies to the mingwrt CVS head and have raised the discussion on the MinGW Developer mailing list for additional comment. Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Daniel J. <dr...@fa...> - 2010-02-15 15:41:17
|
On Mon, Feb 15, 2010 at 09:01:47AM -0500, Chris Sutcliffe wrote: > Thank you for reviving this discussion. I have updated the patch so > that it applies to the mingwrt CVS head and have raised the discussion > on the MinGW Developer mailing list for additional comment. Thanks! FYI, yesterday I got GDB working by writing the stubs I needed by hand. I have some additional comments, which may or may not be useful: * I don't see any disadvantage, for the libmoldname90.a library, to including stubs for _fstat, time, et cetera. Because the names were removed, anything calling them must have been built with an old __MSVCRT_VERSION__. Therefore they must want the 32-bit time_t versions. This preserves compatibility. * _osver has also been removed, although there is an alias for it in libmsvcr90.a. Since the only users of this in my codebase are two Win9X checks in mingw, and I don't need Win9X support, I defined: int _osver = 0; int *__imp__osver = &_osver; Presumably there's some better solution. This does suggest that no one's tested mingw with the 9.0 DLLs in a while. * It would be much easier to use these if someone either got upstream GCC patched ("-mmsvcr90"), or else mingw shipped the libraries in directories ("-L$mingw/lib/msvcr90" containing libmsvcrt.a which was really libmsvcr90.a). Rather than hacking up specs files, I copy the libraries around in my build system and use -L. -- Daniel Jacobowitz CodeSourcery |
From: Charles W. <cwi...@us...> - 2010-02-16 02:39:45
|
Daniel Jacobowitz wrote: > * It would be much easier to use these if someone either got upstream > GCC patched ("-mmsvcr90"), or else mingw shipped the libraries in > directories ("-L$mingw/lib/msvcr90" containing libmsvcrt.a which was > really libmsvcr90.a). Not going to happen. Doing this means that the MinGW free-as-in-speech compiler when used to compile GPL code, would create by default applications that violate the GPL. Here's why (IANAL, yadda yadda yadda): The GPL has an exception, that allows GPLed code to be linked to runtime libraries that are "part of the operating system". You are allowed to distribute these binaries (and /your/ source code) even if you don't have/distribute the source code for those "system" runtime libraries. msvcrt.dll has been defined by MS as "part of the operating system". msvcrXX.dll where xx=71,80,90,etc, have NOT been so defined. So, if you used this proposed version of MinGW gcc to build a GPLed application against msvcrt90.dll, and distributed that binary to anyone -- whether you give them the appropriate MS redist.exe package or not -- you have now violated the GPL. (Never mind the fact that MS doesn't allow anyone except those who have purchased Visual Studio to distribute the redist.exe pacakges...) Because you're distributing a binary, that links to a shared library which is NOT part of the OS, yet you are not also making available the source code for that shared library (you don't happen to have the source code for microsoft's msvcr90.dll, do you?) Now, you're free to build such applications for yourself, and use them, but it's on your head if you distribute them and violate the GPL. We don't want to encourage that, by making it the default behavior. That's why we're "stuck" with msvcrt.dll. -- Chuck |
From: Jef D. <jef...@ho...> - 2010-02-16 08:43:06
|
On 16/02/2010 3:02, Charles Wilson wrote: > msvcrt.dll has been defined by MS as "part of the operating system". > msvcrXX.dll where xx=71,80,90,etc, have NOT been so defined. So, if you > used this proposed version of MinGW gcc to build a GPLed application > against msvcrt90.dll, and distributed that binary to anyone -- whether > you give them the appropriate MS redist.exe package or not -- you have > now violated the GPL. (Never mind the fact that MS doesn't allow anyone > except those who have purchased Visual Studio to distribute the > redist.exe pacakges...) Just a quick question related to distributing the redist packages. As you probably know, there are Visual Studio Express editions which are available for free. So anyone can get a (legal) copy of Visual Studio Express and thus be allowed to distribute the redist package? Or is there some catch somewhere? |
From: Greg C. <gch...@sb...> - 2010-02-16 14:01:03
|
On 2010-02-16 08:42Z, Jef Driesen wrote: [... msvcr*.dll, MinGW, and GPL ...] > Just a quick question related to distributing the redist packages. As > you probably know, there are Visual Studio Express editions which are > available for free. So anyone can get a (legal) copy of Visual Studio > Express and thus be allowed to distribute the redist package? Or is > there some catch somewhere? A gratis download doesn't necessarily confer freedom--e.g., see: http://article.gmane.org/gmane.comp.gnu.mingw.user/22153 You might think that a "redistributable" package could be, well, re-distributed; but the EULA cited there forbids you (among other things) to "publish the software for others to copy". |
From: Kees Z. <kz...@us...> - 2010-02-17 13:21:27
|
Charles Wilson-8 wrote: > Not going to happen. Doing this means that the MinGW free-as-in-speech > compiler when used to compile GPL code, would create by default > applications that violate the GPL. Here's why (IANAL, yadda yadda yadda): > > The GPL has an exception, that allows GPLed code to be linked to runtime > libraries that are "part of the operating system". You are allowed to > distribute these binaries (and /your/ source code) even if you don't > have/distribute the source code for those "system" runtime libraries. > > msvcrt.dll has been defined by MS as "part of the operating system". > msvcrXX.dll where xx=71,80,90,etc, have NOT been so defined. So, if you > used this proposed version of MinGW gcc to build a GPLed application > against msvcrt90.dll, and distributed that binary to anyone -- whether > you give them the appropriate MS redist.exe package or not -- you have > now violated the GPL. (Never mind the fact that MS doesn't allow anyone > except those who have purchased Visual Studio to distribute the > redist.exe pacakges...) > The GPL has not only exceptions for libraries provided with the operating system but also for libraries provided with the compiler used to create the program you wish to distribute. Now msvcr90.dll is provided with Visual Studio Express and the EULA explicitly allows one to distribute it with one's program. Moreover msvcr90.dll is also freely (gratis) available from MS, as part of the Visual C++ Redistributable Package. Also, the description on MSDN (http://msdn.microsoft.com/en-us/library/ms235291.aspx) on how to deploy Visual C++ library DLLs, clearly shows how to distribute these files with your application. So, I would conclude that for GPL-ed programs there is no objection to link them with msvcr90.dll and to distribute it with your program. Greg Chicares-2 wrote: > You might think that a "redistributable" package could be, well, > re-distributed; but the EULA cited there forbids you (among other > things) to "publish the software for others to copy". This sectence refers to Visual Studio (Express) and not to the software created with it. Also, the EULA explicitly mentions "Distributable Code" as listed in redist.txt, which includes msvcr90.dll. So again, I would conclude that it is redistributable. -kz -- View this message in context: http://old.nabble.com/fstat-stub-in-libmoldname90.a-tp27588241p27623553.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Roumen P. <bug...@ro...> - 2010-02-19 20:35:01
|
Kees Zeelenberg wrote: > > > Charles Wilson-8 wrote: >> Not going to happen. Doing this means that the MinGW free-as-in-speech >> compiler when used to compile GPL code, would create by default >> applications that violate the GPL. Here's why (IANAL, yadda yadda yadda): >> >> The GPL has an exception, that allows GPLed code to be linked to runtime >> libraries that are "part of the operating system". You are allowed to >> distribute these binaries (and /your/ source code) even if you don't >> have/distribute the source code for those "system" runtime libraries. >> >> msvcrt.dll has been defined by MS as "part of the operating system". >> msvcrXX.dll where xx=71,80,90,etc, have NOT been so defined. So, if you >> used this proposed version of MinGW gcc to build a GPLed application >> against msvcrt90.dll, and distributed that binary to anyone -- whether >> you give them the appropriate MS redist.exe package or not -- you have >> now violated the GPL. (Never mind the fact that MS doesn't allow anyone >> except those who have purchased Visual Studio to distribute the >> redist.exe pacakges...) >> > The GPL has not only exceptions for libraries provided with the operating > system > but also for libraries provided with the compiler used to create the program > you wish > to distribute. Now msvcr90.dll is provided with Visual Studio Express and > the EULA > explicitly allows one to distribute it with one's program. Moreover > msvcr90.dll is also > freely (gratis) available from MS, as part of the Visual C++ Redistributable > Package. > Also, the description on MSDN > (http://msdn.microsoft.com/en-us/library/ms235291.aspx) > on how to deploy Visual C++ library DLLs, clearly shows how to distribute > these files > with your application. > So, I would conclude that for GPL-ed programs there is no objection to link > them > with msvcr90.dll and to distribute it with your program. > > Greg Chicares-2 wrote: >> You might think that a "redistributable" package could be, well, >> re-distributed; but the EULA cited there forbids you (among other >> things) to "publish the software for others to copy". > > This sectence refers to Visual Studio (Express) and not to the software > created with it. > Also, the EULA explicitly mentions "Distributable Code" as listed in > redist.txt, which includes > msvcr90.dll. So again, I would conclude that it is redistributable. > > -kz Is the shared libraries installed in directory winsxs part of operating system ? Roumen |
From: Charles W. <cwi...@us...> - 2010-02-20 00:55:06
|
Kees Zeelenberg wrote: > The GPL has not only exceptions for libraries provided with the operating > system > but also for libraries provided with the compiler used to create the program > you wish > to distribute. IANAL, but I don't think this would hold up in court. You're not USING the compiler that provides the msvcr90.dll library -- VizStudio. In this hypothetical, you're using the MinGW gcc compiler. We don't provide msvcr90.dll; it doesn't belong to us and cannot reasonably be considered to be "normally distributed...with the...compiler" >From section 3 (GPLv2): "However, as a special exception, the source code distributed 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." Even worse: technically, on windows but unlike unix, the compiler is not usually considered a "component...of the operating system" at all, so it's not clear that the exception extends that far, even if you're using MSVC! GPLv3 isn't much more lenient. From section 1A (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." [[[ emphasis added. Again, you're using mingw gcc, and msvcrXX.dll is not provided by THAT compiler, it's provided by that other compiler, over there, which you /did not use/ in this scenario ]]] > Now msvcr90.dll is provided with Visual Studio Express and > the EULA > explicitly allows one to distribute it with one's program. Read it closely (I haven't; don't have access to it) but I would /suspect/, at the most liberal, it says something like you can redistribute the runtime DLLs with your program if and only if you used Express to compile and link that program. I doubt Microsoft's lawyers want to enable people to redist their DLLs simply because developers installed -- but don't actually use -- Express. But I seem to recall reading somewhere that the license for Express is actually MORE restrictive, that you CANNOT personally redistribute the DLLs -- but instead must point your users to the MS official redist.exe download site. Now, this is not to say that you can't compile GPL code using Express. Sure you can -- in that case, you're actually USING the compiler that provides these DLLs, so of course the "compiler" exception applies. But mingw gcc != Express. > Moreover > msvcr90.dll is also > freely (gratis) available from MS, as part of the Visual C++ Redistributable > Package. Whether something is available gratis has nothing to do with your obligations or rights under the GPL. There are actually two issues: 1) Does the msvcr90.dll fall under the OS/"compiler" exception, so that you are not obligated to distribute the source code of that DLL if you link and GPL'ed app to it, and distribute that app? If it does fall under that exception, then there's no problem (such as if you were actually USING Express or $$$ VisStudio to compile your application). The consensus position of this list is that ONLY msvcrt.dll falls under that exception, because (a) that's the only one MS has explicitly stated is actually part of the OS, and (b) those other runtime DLLs, which might fall under a "compiler" exception if you were to use the actual compiler that provides them (e.g. MSVS2003, MSVS2005, MSVS2008, etc), are not part of OUR compiler. We didn't create them; Microsoft did. So they can't be considered part of "our" compiler -- thus, using mingw gcc but linking to the msvcrXX.dll doesn't magically confer "part of mingw gcc" status on those DLLs and imbue them with the "compiler exception". 2) However, assume I'm wrong on part 1. Even so, do you as a developer have the right to personally redistribute that msvcrXX DLL to end users, even if you don't actually use MSVC (pro or express) to compile your application? > Also, the description on MSDN > (http://msdn.microsoft.com/en-us/library/ms235291.aspx) > on how to deploy Visual C++ library DLLs, clearly shows how to distribute > these files > with your application. Sure, they tell you HOW to do it. I can tell you HOW to pick a lock. That, by itself, doesn't mean you have the RIGHT to distribute those files (or pick that lock). You have to look specifically at the terms of the EULA. Instructions are not a grant of legal rights. And just downloading and installing the redist package, and using mingw's import libs, is not sufficient -- because, despite the name, the redist package is NOT libre' redistributable. Anybody can download it from MS' website and install it, but they can't give copies away to third parties. For THAT legal ability, you must install (one of the) Microsoft compilers -- the $$$ version for sure gives you this right. I'm not sure if the Express version does (I have no intention of installing it just so I can read the EULA). > So, I would conclude that for GPL-ed programs there is no objection to link > them > with msvcr90.dll and to distribute it with your program. Don't take legal advice from a mailing list. Mine OR Kees'. Seek professional assistance. To sum up, until the mingw.org project actually hires a lawyer to provide a professional, binding legal opinion that says we CAN do this, I don't think any of us want to wander very close to that line. If you want to, fine...that's your decision. But we are not obligated to make it any easier -- especially as doing even THAT much might increase our legal exposure. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-02-16 13:03:08
|
Jef Driesen wrote: > On 16/02/2010 3:02, Charles Wilson wrote: >> (Never mind the fact that MS doesn't allow anyone >> except those who have purchased Visual Studio to distribute the >> redist.exe pacakges...) > > So anyone can get a (legal) copy of Visual Studio > Express and thus be allowed to distribute the redist package? Or is > there some catch somewhere? Dunno. You'll have to read the EULA that comes with VizStudioExpress. -- Chuck |
From: Keith M. <kei...@us...> - 2010-02-16 19:56:26
|
On Tuesday 16 February 2010 13:02:32 Charles Wilson wrote: > > So anyone can get a (legal) copy of Visual Studio > > Express and thus be allowed to distribute the redist package? Or > > is there some catch somewhere? > > Dunno. You'll have to read the EULA that comes with > VizStudioExpress. This is hearsay, so may be wrong: AFAIK, the EULA for the Express editions of VS expressly (pun intended) forbids distribution of *anything*, (even the applications you develop yourself); you have to purchase a full VS licence, for anything beyond personal use. -- Regards, Keith. |
From: Roumen P. <bug...@ro...> - 2010-02-19 21:01:18
|
Daniel Jacobowitz wrote: > I've been trying to build an application (GDB, in this case, with > Python enabled) that links to MSVCR90.DLL instead of MSVCRT.DLL. I > can't, and I have the same problem with a trivial program that calls > fstat. > > DLL Name: msvcr90.dll > vma: Hint/Ord Member-Name Bound-To > 5120 32 _fstat > > If I take the linker command and replace -lmoldname with -lmoldname90 > and -lmsvcrt with -lmsvcr90, then I get a binary that links > successfully but fails to run. If I'm logged in to a console I get a > popup saying that it's trying to resolve _fstat in msvcr90.dll, and > failing. > > I'm not a PE expert, but it looks to me like that's exactly what > libmoldname90.a is doing: an import stub for _fstat that references > msvcr90.dll. > > Is this mingw's fault - incomplete support for 9.0 runtime, maybe? It > looks to me like something should be redirecting the call to _fstat32 > or _fstat64 instead (or _fstat32i64 or _fstat64i32). I don't see > anything in the mingw libraries or headers to do that. > One question is for fstat and another is for _fstat . _fstat -> _fstat* is well documented Support for so called by microsoft oldnames is not documented and in this category fail function fstat. If you check current CVS version you will see ...: -------------------- #ifndef _NO_OLDNAMES /* FIXME for __MSVCRT_VERSION__ >= 0x0800 */ /* These functions live in liboldnames.a. */ _CRTIMP int __cdecl __MINGW_NOTHROW fstat (int, struct stat*); .... -------------------- So the question is for future of liboldnames. Will be this library part of GCC compiler ? Roumen |