[CLN-list] msvc support patch

[Bruno Haible]

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/Windows/msvc/
> (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/Windows/msvc/run_compilation.sh?revision=5375
[3] http://cvs.savannah.gnu.org/viewvc/gettext/m4/woe32-dll.m4?revision=1.2&root=gettext&view=text/plain