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.

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

Thanks for the detailed feedback David.

> So, that is probably because libtool finds no known dynamic linker.

At least in the case of libwps shared lib was disabled explicitly for non-gcc compilers (actually, it assumes non-gcc to mean mvs/msc). I have a patch to enable it, but, as you note, it still defaults to static linking. I think I know where to look: libtool.

> I agree that a ld-wrapper seems to be needed.

I'll experiment with a wrapper and investigate how we could get it to cooperate with libtool to create shared libs.

Btw, are we waiting for Windows support of shared libs to enable/test on other platforms, or does shared work on Linux? Do we know these libraries can/do link as shared? I haven't tried building on Linux, and it's easier to ask :)


> But not with the rest.

You mean only with some projects? Not sure I get your point here.

(In reply to Ashod Nakashian from comment #3)
> Thanks for the detailed feedback David.
> 
> > So, that is probably because libtool finds no known dynamic linker.
> 
> At least in the case of libwps shared lib was disabled explicitly for
> non-gcc compilers (actually, it assumes non-gcc to mean mvs/msc).

Do you speak about libwps itself here, or about its build inside libreoffice? By the reference to msvc I assume the latter... In that case, libwps is not being built using its native build mechanism on Windows, because that currently cannot produce a shared library! The patch I attached switches the libwps build to the native build mechanism, so it can be used for experimentation.

> I have a
> patch to enable it, but, as you note, it still defaults to static linking. I
> think I know where to look: libtool.

As I have said, you should check the build log first. There might be some info message(s) from libtool telling why it switched back to static linking.

> 
> > I agree that a ld-wrapper seems to be needed.
> 
> I'll experiment with a wrapper and investigate how we could get it to
> cooperate with libtool to create shared libs.
> 
> Btw, are we waiting for Windows support of shared libs to enable/test on
> other platforms, or does shared work on Linux? Do we know these libraries
> can/do link as shared? I haven't tried building on Linux, and it's easier to
> ask :)

It seems I was not clear enough on that in the initial description... The libraries in question are already built as shared on all platforms. The libraries' native build mechanism (IOW, configure + make) is used on Linux and OS X. It is only Windows that needs special treatment (and the idea of this task is to try to change that).

> > But not with the rest.
> 
> You mean only with some projects? Not sure I get your point here.

I do not agree that there is any need to patch configure or Makefiles.

> Do you speak about libwps itself here, or about its build inside libreoffice? 

Sorry, I wasn't clear. I think we're on the same page. I've, of course, applied your patch, and do recognize the distinction.

I am saying that the native libwps _had_ support for building with msvc[*] using configure/makefile. However that is no longer maintained. I had started with libwps, but also tried other projects since wasn't sure what was specific to it and what more generic.

Anyway, I think I know what to do. As I said, I need to wrap link.exe, which as you say is used by libtool. I also found (after reading your feedback,) where configure checks $LD to decide if shared linking is possible (line 13,918). This means the first test to pass is to make the wrapper respond correctly to configure's check.

Thanks again for your help. Will get back to you with progress (or issues).


[*] See line 15,766 in libwps's configure, for example, or search for "msvc" or "mvs".

Discussed with Jan-Marek and removing from easy hacks. Comment: "You eventually have to write a linker wrapper or somesuch for link.exe, eventually somehow patch libtool and whatnot."

Easy hacks should be guided and not exploratory.

Dear David Tardon,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug