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

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

--- Comment #2 from David Tardon <dtardon@redhat.com> ---
(In reply to Ashod Nakashian from comment #1)
> After spending some time tackling this, it's clear that it isn't as
> straightforward as I was led to believe.

Sorry I misled you. This was intended to be an "exploration"-style task, but I
see the description does not say that anywhere...

Thanks for the analysis, though!

> 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.

Actually, LD is used. But indirectly by libtool.

> 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, that is probably because libtool finds no known dynamic linker. It defaults
to building static libraries in that case instead of just failing as any
sensible tool would do. You can check the build log (in
workdir/UnpackedTarball/*/build.log by default); there should be an info
message from libtool that it can't build dynamic libs for some reason and that
it switches to static.

> 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.

I agree that a ld-wrapper seems to be needed. But not with the rest. Dynamic
libraries are already supported, through libtool. But libtool either cannot use
link.exe directly (-> a wrapper) or it needs extra options for building dynamic
libs (my first suspect would be -no-undefined, but libwps already passes that
one).

> 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.

Well, while some of the projects do have VS project files, these are typically
out-of-date...

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