From: Brian D. <br...@de...> - 2007-03-30 22:31:33
|
This is just a heads-up that as of a few hours ago, it looks like support for x86_64-*-mingw* has finally been committed to gcc HEAD: <http://gcc.gnu.org/ml/gcc-patches/2007-03/msg02035.html>. The support has been in binutils for some time now already. Still necessary before actually having a usable toolchain would be import libraries for the 64 bit Windows APIs, as well as 64 bit startup objects and runtime import libraries (mingw-runtime). I'm still unsure what the deal is with the 64 bit version of MSVCRT.DLL, whether it's considered part of the OS, or whether it must be distributed along with ones' project. If the latter is the case then at least there's <http://www.microsoft.com/downloads/details.aspx?FamilyID=90548130-4468-4bbc-9673-d6acabd5d13b> which is a free download of the VC++ 2005 x64 redistributables, which includes the 64 bit version of MSVCR80.DLL (as well as the C++ runtimes MSVCP80.DLL and MSVCM80.DLL, and the MFC 8.0 and ATL 8.0 runtimes; but none of these are usable by gcc due to different C++ ABI, AFAIU.) While developing the gcc port, Kai Tietz did seem to indicate that he had a local port of the Win64 API import libs, but it wasn't clear whether he had just modified the Microsoft PSDK headers or if it was actually a full port of w32api. In the former case, that's not of much use to us; in the latter, let's hope that he contributes the port. Brian |
From: Greg C. <chi...@co...> - 2007-03-30 23:21:25
|
On 2007-3-30 22:31 UTC, Brian Dessent wrote: > > Still necessary before actually having a usable toolchain would be > import libraries for the 64 bit Windows APIs, as well as 64 bit startup > objects and runtime import libraries (mingw-runtime). I'm still unsure > what the deal is with the 64 bit version of MSVCRT.DLL, whether it's > considered part of the OS, or whether it must be distributed along with > ones' project. If the latter is the case then at least there's > <http://www.microsoft.com/downloads/details.aspx?FamilyID=90548130-4468-4bbc-9673-d6acabd5d13b> > which is a free download of the VC++ 2005 x64 redistributables, which "free": gratis, but is it libre? If not, then maybe it can't be used for GPL code compiled with MinGW. Let's see...I download the thing, run it, and am confronted with a license that says... | This agreement only gives you some rights to use the software. ... | You may not [here are some selected items:] | * disclose the results of any benchmark tests... | * work around any technical limitations in the software; [such as libmingwex?] | * publish the software for others to copy; | * rent, lease or lend the software; | * use the software for commercial software hosting services. Doesn't seem libre. I'd question whether this meets the definition of "System Libraries" in the recent GPL "Discussion Draft 3 of Version 3, 28 March 2007". |
From: Brian D. <br...@de...> - 2007-03-30 23:45:30
|
Greg Chicares wrote: > "free": gratis, but is it libre? If not, then maybe it can't be > used for GPL code compiled with MinGW. Let's see...I download > the thing, run it, and am confronted with a license that says... Well of course it's not free/libre, it never has been, nor never will be, nor is the existing 32 bit C runtime library. The only question that stands in the way of using it with MinGW and linking it with GPL source is whether it fits the "part of the operating system" GPL exemption. > | You may not [here are some selected items:] > | * disclose the results of any benchmark tests... > | * work around any technical limitations in the software; > [such as libmingwex?] > | * publish the software for others to copy; > | * rent, lease or lend the software; > | * use the software for commercial software hosting services. I'm just speculating here but I'd guess that all or most of these restrictions are also in the Windows operating system EULA too. If so then this is nothing new, the existing 32 bit MinGW that uses MSVCRT.DLL already navigates this landmine, without any apparent lawsuits as of yet. > Doesn't seem libre. I'd question whether this meets the > definition of "System Libraries" in the recent GPL > "Discussion Draft 3 of Version 3, 28 March 2007". That of course is the important question, but I wouldn't use the v3 wording to argue it, considering v3 hasn't yet been finalized and even if it does, the user can still choose to not use it and fall back to v2. (Unless the project relicenses in the future to "v3 and higher only", and even in that case, still all the previously released versions are forever usable under v2.) If the wording of the GPL doesn't consider the VC++ Redist C runtime as part of the operating system then that would be a serious problem for the MinGW platform to support 64 bit Windows. The only options would be to: - Use a platform that has its own C runtime (such as Cygwin) - Create a new (or port an existing) C runtime that mirrors the functionality of MSVCRT - Wait and hope that MS does what it did with MSVCRT.DLL originally and make MSVCRT80.DLL included as part of the base operating system Brian |
From: Greg C. <chi...@co...> - 2007-03-31 00:57:11
|
On 2007-3-30 23:45 UTC, Brian Dessent wrote: > Greg Chicares wrote: ["redistributable" C rtl available gratis from ms] >> Doesn't seem libre. I'd question whether this meets the >> definition of "System Libraries" in the recent GPL >> "Discussion Draft 3 of Version 3, 28 March 2007". > > That of course is the important question, but I wouldn't use the v3 > wording to argue it, considering v3 hasn't yet been finalized and even > if it does, the user can still choose to not use it and fall back to > v2. I'm not sure GPL version 2 would permit use of this download (or, for that matter, any similarly-licensed download of the 32-bit rtl). The version 2 "special exception" applies to 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 I'd say MSVCRT.DLL is clearly okay for MinGW-built GPL apps because that dll is "distributed with the kernel" in the system directory of any 32-bit msw installation. One might argue that msvc++ is a "major component" because it's the OS vendor's compiler, but then there's the counterargument that msvc++ is not "normally distributed" with the OS and most msw users don't even have it. |
From: Brian D. <br...@de...> - 2007-03-30 23:58:59
|
Brian Dessent wrote: > - Use a platform that has its own C runtime (such as Cygwin) > - Create a new (or port an existing) C runtime that mirrors the > functionality of MSVCRT > - Wait and hope that MS does what it did with MSVCRT.DLL originally and > make MSVCRT80.DLL included as part of the base operating system And, I suppose, even if mixing GPL+x64 MSVCRT is deemed to be incompatible, then MinGW could still release a 64 bit toolchain. It's just that it could legally only be able to compile BSD or otherwise-liberally licensed code that links with the nonfree C runtime library. That would be a pretty unfortunate state though, as most of the supporting tools needed to get work done in a GNUish environment are GPL. (the gcc runtimes all have the exception clause so they are not relevant here, I believe.) Brian |
From: Jonathan W. <jf...@tp...> - 2007-03-31 01:25:51
|
An examination of a windows XP x64 installation shows that there is both 32 bit and 64 bit versions of msvcrt.dll included. Assuming this is true for Vista x64 too then we should be able to link to and use that for MingW without questions over whether it counts under the "part of the compiler/OS" exception in the GPL. What would be needed is for someone to create 64 bit versions of mingw-runtime and w32api (although it should be possible to reuse most of the 32 bit stuff AFAIK) |