Take the 2-minute tour ×

In the book Autotools: A Practioner's Guide to GNU Autoconf, Automake, and Libtool, chapter 6 (building libraries with libtool), an example of linking library is given.

In the example, a library libjupiter.so is linked to another library libjupcommon.a. The first attempt fails because libjupiter.so needs PIC, but libjupcommon.a is not. The author adds libjupcommon_a_CFLAGS = -fPIC to fix it. It gets much better, but the warning of 'Linking the shared library libjupiter.la against the static library ../common/libjupcommon.a is not portable!' appears.

Therefore the author modifies the Makefile.am's again, using libtool to build libjupcommon.la. The libjupiter links to the libjupcommon.la. Like this:

noinst_LTLIBRARIES = libjupcommon.la

libjupcommon_la_SOURCES = jupcommon.h print.c



libjupiter_la_LIBADD = ../common/libjupcommon.la

This time everything's OK.

Now, my problem:

I have a library needs another library, just like libjupiter needs libjupcommon. The difference is my libjupcommon is from another project and installed into the system. It is not a noinst_LTLIBRARIES. Both .so and .a version exist. When I try to link the libjupcommon.la like the example shows, the .so is chosen, but I don't want a dynamic linking relationship. I want to link to the .a, like the example in the book.

Linking to .a explicitly (by using _LIBADD=the .a file) gives a usable library, but the warning of '... not portable' is given.

What's the proper way to achieve linking to the .a in this case?

PS: Download the example from the book's official site. In autotools/book/jupiter-libtool-ch6/common, modify the Makefile.am's noinst_LTLIBRARIES to lib_LTLIBRARIES should be a close mimic to my problem.

share|improve this question
What can of library do you want to build? A shared library or a static library? It make no sense to link with the installed .a library if you are building a shared library, hence the libtoool warning. If you are building a static library, you should explicitly state so (see ldav1s' answer). –  adl Nov 8 '11 at 9:48
I want to build a shared library. It makes no sense even if the installed .a is PIC? Why is it so? –  Cha Cha Nov 8 '11 at 9:55
But in that case the .a was not generated by Libtool. As far as I know, the .a files installed by Libtool are not PIC. –  adl Nov 9 '11 at 9:24
add comment

1 Answer

up vote 2 down vote accepted

There's a couple things you could try. You could try running configure with the --disable-shared option to turn off compilation of shared libs (and add the static lib to libfoo_LIBADD again). You could try adding -static to libfoo_LDFLAGS to get libtool to build it statically (again with the static lib added to libfoo_LIBADD).

EDIT: Since both static and shared libs are needed the above won't work.

Try adding:


to configure.ac.

share|improve this answer
You mean to compile the static one only? I think it will work. But I need both static and dynamic libjupcommon; and make libjupiter.so links the static one. –  Cha Cha Nov 8 '11 at 9:52
noinst_LTLIBRARIES are convenience libraries, intended to be relinked with some executable or other library during the build. –  ldav1s Nov 8 '11 at 23:25
After reading the code of libtool, I am convinced that building a static only library is what I should do. Like libfoo.so, libfoo.a libfoo_static.a. Thanks ldav1s. –  Cha Cha Mar 1 '12 at 8:32
add comment

Your Answer


