Building .so module with autotools/libtool without .la and .a variants being installed

Question

How to build and install a .so module with autotools/libtool without .la and .a libraries being also installed into --prefix path?

Currently i am using following Makefile.am:

lib_LTLIBRARIES = libCurlDownloader.la
libCurlDownloader_la_SOURCES = Curl.cpp
libCurlDownloader_la_LDFLAGS = -module -avoid-version

It works, but in addition to libCurlDownloader.so it also installs libCurlDownloader.la and libCurlDownloader.a, what is undesirable.

Update #1

It is possible to make .a not be generated, by using either

./configure --disable-static

or

AC_ENABLE_SHARED(yes)
AC_ENABLE_STATIC(no)

in configure.ac

But it is still the question how to make .la not being installed into installation --prefix while having .so installed.

Update #2

It is possible to remove .la files from installation --prefix using

install-exec-hook: find $(DESTDIR)$(libdir) -type f -name \*.la -delete

Jodijodie

You have a minor typo (should be install-exec-hook). – Calva

I think you can't, debian packagers are removing by hand la files in deb packages – Cobnut

That install-exec-hook seems like a bad idea. It would remove all .la files from the directory, not just the ones generated by your project. Not much of a problem if DESTDIR is used, but very wrong otherwise. – Haruspex

Answer 1

You should not necessarily delete the .la files. The .la files contains information that is used in two situations:

1. Statically linking against the built library. When statically linking (i.e., .a with -static), there is no information about the dependencies of the library being linked, so libtool can use the information in the .la file to create an appropriate ld command referencing all the necessary dependencies. This is often more important on an environment like MinGW where the linker requires the same library specified multiples in a particular order to resolve recursive dependencies. This is only a concern if one intends to build a static binary.

2. Dynamically loading the build library on some platforms (i.e., with lt_dlopen if using libltdl). Similarly, on certain platforms, dependencies of the compile module are not encoded in the binary, so the .la file is needed so that lt_dlopen will find and load the correct dependencies. On ELF platforms (including Linux) and PE platforms (i.e., Windows), the dependencies are store in the library, so lt_dlopen will work without the .la files. The MachO format on MacOS can require .la files when building bundles.

The Debian/Ubuntu packagers have decided to exclude .la files from their packages because the second reason isn't appropriate on Linux and they would prefer you didn't build static binaries in the first place. On other platforms, which libtool is designed to support, the .la files may be needed for linking or running the program.

Prologue

For static linking dependencies; there is almost always (even more often then existing .la files) pkg-config instructions are available. – Jodijodie

Similary - even for dynamic linking pkg-config offers a better help then libtool crutches; in buildsystem-independent way. – Jodijodie

Answer 2

I stumbled upon this question because it used the term "module", which in automake/libtool speak is the term for a plugin. I have a plugin system in Finit, so I build my plugins with '-module' to avoid creating .a files. But I still get the .la files installed, which really is not even applicable in the '-module' case.

I've yet to find a documented way to skip .la files for plugins, but here is how I do it:

AM_LDFLAGS = -module -avoid-version -shared
pkglib_LTLIBRARIES = alsa-utils.la bootmisc.la

install-exec-hook:
        @(cd $(DESTDIR)$(pkglibdir) && $(RM) $(pkglib_LTLIBRARIES))

To be clear, in my use-case there is nobody going to "link" against my plugin .so's, so the .la files really are of no use.

Kibbutznik

Have you found it? I really hate this. – Chlortetracycline

@iharob nope, still using that hook rule to clean up the .la files. The project is here if you want to see more details. – Kibbutznik