* New build prerequisite doxygen (controllable via --with-doxygen).
* Adapted various headers to slightly different doxygen documentation
syntax, but much clean up still remains to be done (i.e., warnings
emitted by doxygen fixed).
This is a cherry-pick of Matúš's e2f30c078fcf26d481c2e90398b450f6c475a483
from the feature/gbuild branch, with the following modifications by
Stephan Bergmann <sbergman@redhat.com>:
* Adapt salhelper/Makefile to what all those Makefiles currently need to
look like.
* Do not remove salhelper/source/gcc3.map, instead add directly into it
what otherwise solenv/bin/addsym.awk would add to it on Linux.
* In salhelper/Library_salhelper.mk, add code that on Linux takes care of
the soname and symbol versioning required for backwards compatibility.
Solaris would need those features too, and its backwards compatibility
is thus currently broken. Also add a bad hack to create the soname
symlink (xxx.3 -> xxx) in the solver needed on non-Windows platforms (it
is a bad hack for now in that it e.g. is not removed by "make clean").
* In solenv/gbuild/platform/macosx.mk, add an even worse hack to set the
correct install name for libuno_salhelpergcc3.dylib.3, with a trailing
".3".
Unfortunately the C++ name mangling in a 64-bit MSVC compilation is
slightly different from that in a 32-bit one:
-- An 'E' is inserted for pointers to indicate that they are 64
bits. I don't fully understand the rationale for this; isn't that the
only kind of pointer in 64-bit code produced by a C++ compiler anyway?
-- As there is only one calling convention on x64 Windows, __cdecl,
the indications for other calling conventions (here, especially
__thiscall) change to that for __cdecl.
It should be possible to write a tool to at least partially automate
conversion of 32-bit mangled names to 64-bit ones, and thus make it
easy to create mscx map files from the corresponding msci ones in
LibreOffice. Sure, it probably wouldn't work 100% correctly in all
cases, but it would help a lot.
After of the vos removal, some classes in other parts of the code now
are subclasses of SimpleReferenceObject.
To avoid compilation and linking errors in those other parts, we seem
to need to have the operator new[] and operator delete[] in
SimpleReferenceObject as protected instead of private. We also need an
implementation of operator delete[]. As it can be unimplemented with
gcc, I hope it isn't actually called, though, so it for now crashes
intentionally if called.
Will see later if this actually works, this is just a commit to make
stuff build.
