Re: [CLN-list] [GiNaC-list] msvc support patch (Was: use of STL iterators in GiNaC)
On Sun, Apr 19, 2009 at 9:53 PM, Richard B. Kreckel <kreckel@ginac.de> wrote:
Hi!
Michael Goffioul wrote:
(How) Did you manage to compile CLN with msvc?
Magic.
VC++ per-se is quite (not fully) standard compliant. Most of the problems are in the autotool based build framework. With a bit of coding, you can make VC++ look like GCC.
Interesting. Could you write up a summary of what you did and report it on <cln-list@ginac.de>? This way, others will have a chance to pick up on your work.
CLN/GiNaC compilation with VC++ is part of the making of Windows package for octave. All compilation scripts and patches are available under SVN on octave-forge http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/Win... (run_compilation.sh and libs/) The main problem when compiling packages with VC++ is not the compiler itself, which is pretty C/C++ compliant, but the build toolchain. Most packages in the UNIX world use autoconf/automake/libtool toolchain and those tools do not support VC++ very well (at all). But you can work around that problem by using wrappers around VC++ compiler to make it look like GCC, by translating command flags. You can use such wrappers to build tools equivalent to gcc, g++, ar, ranlib... but based on VC++. You can also provide some missing headers like stdint.h, inttypes.h or unistd.h (you can find some on the web), to further ease porting packages. Once you have those tools, it becomes easier to compile packages using the normal "./configure && make" way, using the MSYS shell. But you still need to take care of some specific issues: 1) libtool: using some post-processing magic, it's possible to make libtool to support VC++ (through the gcc-like wrappers) 2) symbol export: VC++ does not export symbols automatically, so you need to take of it; either by using a .def file (some packages provide their own), or by using dllexport/dllimport qualifiers (again some packages support that as well), or by parsing yourself the object files to generate a .def file automatically (this works well especially for plain C code); of course, when you build a static library (which is what I do or CLN/GiNaC), you don't have to care about that 3) export of data: even with the tricks of point 2), you still need to decorate exported data with dllimport, as VC++ does not have the auto-import feature of MinGW; for packages that do not provide this decoration, you have to write your own patch. For the specific case of CLN, there were a couple of issues I also had to take care of: - struct/class, const/non-const: at some places, CLN foward declares objects as being "class", while there are actually "struct"; VC++ generates different mangled names for struct and class, so you end up with unresolved references. The same happen for const/non-const (forward declare as non-const, but define as const). - assembly code: here I cheated a little bit and used gcc to compile the .S file; this required some hacks in the Makefile - some namespace issues: apparently, declaring a function inside the body of another method, which is parted of the cln namespace, does not make VC++ to tag the declared function with the cln namespace; for instance in number.h, I had to move the "extern" statements of CL_DEFINE_LONG_CONSTRUCTOR out of the method bodies. Bye, Michael.
Michael Goffioul wrote:
CLN/GiNaC compilation with VC++ is part of the making of Windows package for octave.
There is a problem with the Windows installer of Octave: It violates the GNU GPL, under which Octave is distributed. The download octave-3.0.3-setup.exe [1] contains an installable part called "Microsoft C/C++ runtime libraries required by Octave." According to the packaging scripts to which you pointed us [2], these runtime libraries are the files msvcr80.dll, msvcp80.dll, msvcm80.dll. Because these files are not normally distributed with the Windows OS and because they are not distributed with source code, it's a breach of the GPL. (Of section 3 of GPLv2, to be precise.) Maybe the copyright holders of Octave have given their agreement to this; I don't know. In this case there would be nothing wrong with said downloadable installer, if it doesn't contain CLN. But regarding CLN, there is no such extra permission. As the main copyright holder of CLN, I'm asking to respect the GPLv2, under which CLN is distributed. This may sound negative and may deceive you. Let me explain the reason: There is a compiler with a free runtime library (excluding the components that are shipped with Windows). It's mingw. And then there is a compiler with a closed-source runtime library: MSVC++. When you build software for your own, you may use mingw or MSVC++. I don't mind, I don't care. It's your choice which compiler you prefer. But when you build it for redistributing it to other people, I prefer that you give these users the right to inspect and modify the C++ runtime library, and I don't want CLN to be used as a vehicle for distributing a closed-source DLL. Ultimately this will help making mingw and libstdc++ better.
3) export of data: ... VC++ does not have the auto-import feature of MinGW; for packages that do not provide this decoration
This auto-import "feature" is more a misfeature, IMO. See [3] for explanations.
- struct/class, const/non-const: at some places, CLN foward declares objects as being "class", while there are actually "struct"; VC++ generates different mangled names for struct and class, so you end up with unresolved references.
What does the C++ standard say about this? Is CLN right, or is MSVC++ right?
- some namespace issues: apparently, declaring a function inside the body of another method, which is parted of the cln namespace, does not make VC++ to tag the declared function with the cln namespace; for instance in number.h, I had to move the "extern" statements of CL_DEFINE_LONG_CONSTRUCTOR out of the method bodies.
Again, what does the C++ standard say about this?
All compilation scripts and patches are available under SVN on octave-forge http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/Win... (run_compilation.sh and libs/)
Did cln's "make check" pass with these patches? Bruno [1] http://sourceforge.net/project/showfiles.php?group_id=2888&package_id=40078 [2] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/Win... [3] http://cvs.savannah.gnu.org/viewvc/gettext/m4/woe32-dll.m4?revision=1.2&root=gettext&view=text/plain
Bruno Haible wrote:
Michael Goffioul wrote:
Hi Bruno,
CLN/GiNaC compilation with VC++ is part of the making of Windows package for octave.
There is a problem with the Windows installer of Octave: It violates the GNU GPL, under which Octave is distributed.
The download octave-3.0.3-setup.exe [1] contains an installable part called "Microsoft C/C++ runtime libraries required by Octave." According to the packaging scripts to which you pointed us [2], these runtime libraries are the files msvcr80.dll, msvcp80.dll, msvcm80.dll. Because these files are not normally distributed with the Windows OS and because they are not distributed with source code, it's a breach of the GPL. (Of section 3 of GPLv2, to be precise.)
I really don't want to turn this into a flame war and I know that licensing discussions aren't too welcome on the Ginac list, so I dropped it from the CC. I am curious what your point of view regarding the system runtime exception is here. From the above I gather that you do not think that the MSVC runtime falls under that since it isn't distributed with (at least some versions of) Windows. My reading has always been that this clause in the GPL covered compiler runtimes as well.
Maybe the copyright holders of Octave have given their agreement to this; I don't know. In this case there would be nothing wrong with said downloadable installer, if it doesn't contain CLN.
But regarding CLN, there is no such extra permission. As the main copyright holder of CLN, I'm asking to respect the GPLv2, under which CLN is distributed.
This may sound negative and may deceive you. Let me explain the reason:
There is a compiler with a free runtime library (excluding the components that are shipped with Windows). It's mingw. And then there is a compiler with a closed-source runtime library: MSVC++.
When you build software for your own, you may use mingw or MSVC++. I don't mind, I don't care. It's your choice which compiler you prefer.
But when you build it for redistributing it to other people, I prefer that you give these users the right to inspect and modify the C++ runtime library, and I don't want CLN to be used as a vehicle for distributing a closed-source DLL. Ultimately this will help making mingw and libstdc++ better.
Agreed. <SNIP technical discussion> Cheers, Michael
Michael Abshoff wrote:
From the above I gather that you do not think that the MSVC runtime falls under that since it isn't distributed with (at least some versions of) Windows.
Yes, this is one of the points. If someone states, for example, that the system requirements of his binary package is "Windows XP or newer", and relies on a DLL that is part of the Windows XP operating system, the GPL has no problem with that.
My reading has always been that this clause in the GPL covered compiler runtimes as well.
... *if* the compiler runtime are not shipped as part or together with the binary package. That's the second requirement in the GPL, that is necessary for the compiler runtimes exception to apply. Quoting GPLv2 section 3: "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." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Similar provisions are in the GPLv3: When you put DLLs into the same installer as GPLed software, they are not merely forming an "aggregate" (in the sense of the last paragraph of section 5 of the GPLv3), but rather a combined work, hence the GPL applies to these DLLs as well, with the consequence that they cannot be closed-source. That's why distributing mingw built binary packages is OK: They rely on msvcrt.dll (which comes with Windows) and libmingw32.a, libmingwex.a, libmingwthrd.a, libstdc++.a (for which source is available and the license is GPL-compatible). Bruno
On Mon, Apr 20, 2009 at 4:16 AM, Bruno Haible <bruno@clisp.org> wrote:
Michael Abshoff wrote:
Hi Bruno,
From the above I gather that you do not think that the MSVC runtime falls under that since it isn't distributed with (at least some versions of) Windows.
Yes, this is one of the points. If someone states, for example, that the system requirements of his binary package is "Windows XP or newer", and relies on a DLL that is part of the Windows XP operating system, the GPL has no problem with that.
Ok.
My reading has always been that this clause in the GPL covered compiler runtimes as well.
... *if* the compiler runtime are not shipped as part or together with the binary package. That's the second requirement in the GPL, that is necessary for the compiler runtimes exception to apply.
Quoting GPLv2 section 3: "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." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aha.
Similar provisions are in the GPLv3: When you put DLLs into the same installer as GPLed software, they are not merely forming an "aggregate" (in the sense of the last paragraph of section 5 of the GPLv3), but rather a combined work, hence the GPL applies to these DLLs as well, with the consequence that they cannot be closed-source.
That's why distributing mingw built binary packages is OK: They rely on msvcrt.dll (which comes with Windows) and libmingw32.a, libmingwex.a, libmingwthrd.a, libstdc++.a (for which source is available and the license is GPL-compatible).
Thanks for clearing this up. The next post answered my next question how one could legally deal with the MSVC runtime..
Bruno
Cheers, Michael
On Mon, Apr 20, 2009 at 3:22 AM, Bruno Haible <bruno@clisp.org> wrote:
Michael Goffioul wrote:
CLN/GiNaC compilation with VC++ is part of the making of Windows package for octave.
There is a problem with the Windows installer of Octave: It violates the GNU GPL, under which Octave is distributed.
The download octave-3.0.3-setup.exe [1] contains an installable part called "Microsoft C/C++ runtime libraries required by Octave." According to the packaging scripts to which you pointed us [2], these runtime libraries are the files msvcr80.dll, msvcp80.dll, msvcm80.dll. Because these files are not normally distributed with the Windows OS and because they are not distributed with source code, it's a breach of the GPL. (Of section 3 of GPLv2, to be precise.)
This link will hopefully clarify this. If you still don't agree, there's no point in discussing the rest. http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL Michael.
Hi! Bruno Haible wrote:
Michael Goffioul wrote:
- struct/class, const/non-const: at some places, CLN foward declares objects as being "class", while there are actually "struct"; VC++ generates different mangled names for struct and class, so you end up with unresolved references.
What does the C++ standard say about this? Is CLN right, or is MSVC++ right?
I don't think it is worth checking what the standard says about this. Even if it permits such sloppiness, they should be avoided. I'll prepare a patch for CLN. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (4)
-
Bruno Haible
-
Michael Abshoff
-
Michael Goffioul
-
Richard B. Kreckel