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