[Coin-discuss] [Cbc] Question about building [Cbc, Clp, etc.] in Visual Studio

[Lou Hafer]

Calvin, et al.,

> [ ... I'm wondering if it's possible to build [libCoinUtils, libClp,
> libCbc, etc. ] as DLL's ... ]

	I've been holding off answering this because I didn't know the answer
to a critical question. As of yesterday, I think I have a solution. The
short answer is `soon, probably, and it's not pretty.'

	The explanation below is relevant to the common use case of implicit
linking, where an import library is generated as cover for the DLL.
Purists will note that if you know what you're looking for (in C++, that
means knowing mangled method names), you can use explicit loading.

	The problem with building DLLs is that you need to specify the methods
to be exported from the DLL. Microsoft does this by decorating each
exported class or function with __declspec(dllexport). Where a DLL
imports from the outside, the declaration should be decorated with
__declspec(dllimport). And, of course, outside of the MS world,
__declspec is just a syntax error. To go the __declspec route requires
littering the COIN code base with this decoration, hidden behind a
compile-time define that selects the proper choice from the above three.
That's unattractive.

	The alternative is a module definition (.def) file, which is processed
by the linker when it assembles the various .obj files into the DLL and
import library. But there's a problem: everything I've been able to find
that talks about automated generation of the .def file assumes that
declarations are decorated with __declspec so that 'dumpbin /exports'
will work. That's not the case here. Hand maintenance of the .def file
is not possible in the world of C++, mangled names to handle overloads,
and libraries that export hundreds of methods. Name mangling is not
standardised. It comes down to `How to automatically extract the mangled
names from the .obj files without __declspec?'

	I've been working on how to do this, and have a proof-of-concept
finished (read: I can build libCoinUtils.dll and it passes its unit
test :-) It's not pretty; a PowerShell script that scans the .obj files,
extracts the symbols, prunes away the unsuitable ones, manipulates
others, and generates the .def file. It's based on observation of
patterns in the (undocumented) name mangling scheme used by cl. It's
probably brittle; it's surely restricted to cl, perhaps even to
particular versions of cl. There's a fair bit of work to go before its
ready for an unsuspecting world.

	You should have a look at CoinMP. It wraps cbc in a small set of access
methods with C linkage, thereby sidestepping all the problems I've
mentioned above. But you're limited to solver-level access --- set
options, load a problem, solve, get the answer. You don't have easy
access to the full set of methods in the underlying libraries.

	Volunteers welcome! I'll admit up front I'm a unix guy at heart, and
the Windows world still looks pretty strange. Calvin, if you're
interested, send me an email.

							Lou