[CLN-list] [GiNaC-list] msvc support patch (Was: use of STL iterators in GiNaC)

[Michael Goffioul]

On Sun, Apr 19, 2009 at 9:53 PM, Richard B. Kreckel <kreckel at 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 at 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/Windows/msvc/
(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.