[Bug 91480] allow to build shared libraries in bundled projects on Windows

https://bugs.documentfoundation.org/show_bug.cgi?id=91480

--- Comment #1 from Ashod Nakashian <ashodnakashian@yahoo.com> ---
After spending some time tackling this, it's clear that it isn't as
straightforward as I was led to believe.

The main issue is that, while the compiler (CC and CXX) is replaced by the gcc-
and g++-wrapper, the linker isn't replaced. LD isn't used at all, instead,
these external projects (the handful I looked into) explicitly use LIBTOOL,
which points to a script generated by configure. So defining LIBTOOL doesn't
help here.

In all the cases I've checked, setting --enable-shared and --disable-static do
not produce the desired result. At least in the case of libwps it's clear that
shared libraries are not supported (or are broken if they were at some point).
If the project in question compiles successfully, it always generates a static
library.

So the solution is to patch configure (in each project) such that shared
libraries would be supported. To do that we would most probably need to wrap MS
link.exe in the same way that gcc-wrapper wraps cl.exe. But first we need to
make sure that Makefile does call LD, which can then be proxied as necessary.

Another way is to patch the VS projects where they are available to produce
DLL, then compile using devenv.com (part of VS) instead of $(MAKE). This should
be the simplest solution, but many projects might not even have these VS
projects, although those could be created as well.


If there is a smarter way that I missed, I'd be interested to be hinted at the
right direction.

-- 
You are receiving this mail because:
You are on the CC list for the bug.