Create a single static (convenience?) library with Autotools and multiple build directories

0
votes

I am maintaining a library project that builds a "front end" library and multiple "back end" libraries. The project utilizes the Autotools suite (which I am learning and finding our project's implementation is in need of maintenance) including Libtool. As shared libraries it all works very well. We have an application developer that uses the library and prefers to build using static libraries for his ease of software distribution across multiple platforms (I don't wish to debate his motives).

He has told me that at a previous point he was able to build a single large static library using our build system but is no longer able to. I have been unable to trace exactly when this occurred but suspect that it may be related to one of two changes. The first change was removal of a bundled libtool source directory. The second was placing the backend libraries into /usr/local/lib/project rather than scattering them about as before in /usr/local/lib (default locations).

What I have been unable to learn is how to combine the frontend library with the backends into a single convenience library under /usr/local/lib and do so within the Autotools framework. This seems to be possible but I've not found an example to learn from.

As an aside, the projects builds several utilities as part of our test suite. I ran configure with the --disable-shared option, then make, and the utilities are statically linked to the project library. Now my quest is to make this functionality available to third party applications.

1
static-librariesautotoolsautoconfautomakelibtool
Did you run your version control's equivalent of git bisect to find out for sure which commit was responsible? – ptomato
No. I'm not certain of the commands he used and whether he was employing his own script at the time. Also, I never built the library in that manner myself as I didn't care about a static lib. I first learned of this about a year ago and have on-and-off been looking for an answer or at least some clues. – Nate B.
It seems odd to describe unifying the installation directory in /usr/local/lib as "scattering about" rather than describing scattering of the installation locations in /usr/local/lib/[project]/ as such. – William Pursell
@WilliamPursell It may have been an odd way to describe it at the time. It matters not at this time as the project converted to having one large library that resolved this issue and a couple of others as a bonus. – Nate B.

1 Answers

3
votes

In Libtool's jargon a convenience library is a library that is not installed. It must be declared to Automake with the noinst_ prefix.

When you build a library L out of multiple convenience libraries: all the convenience libraries are gathered to build a single library L that will be installed. This happens regardless of whether L is a shared library or a static library.

My guess is that you have a third change: maybe in the past all your backend libraries were convenience (i.e., noinst_) libraries so you were effectivelly installing only one .so and one .a eventually; yet at some point it was decided to install all these backend libraries on their own (i.e., change the noinst_ to pkglib_ or similar), therefore these libraries stopped being convenience libraries and they are no longer included in the frontend.

Note that if the installed backend libraries are still listed as an _LIBADD for the frontend library, this dependency is still recorded by Libtool. Whenever you link to the installed frontend.la file (this requires you use libtool for linking, even as a user of the library), Libtool should include the backend libraries as well, regardless of whether frontend.la was compiled as a static or shared library.

PS: The matter would be slightly different if your backend libraries are actually Libtool modules (a.k.a. plugins) that are dlopened by the frontend.