Home/ Questions/Q 8159079
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T17:48:11+00:00

I have a new c++ project built with autoconf, automake and libtool. Functionality is

  • 0

I have a new c++ project built with autoconf, automake and libtool. Functionality is divided up into support libraries and user binaries. There is also a set of unittests binaries which link against these libraries, are built and run at make check time, but are not installed.

I said the the project is new. I’m actually just now getting around to extracting the first library that should be installed. Until now the (small amount of) written code was just compiled directly into a unittests.

My attempted Makefile.am snippet looks like this:

lib_LTLIBRARIES += libfoo.la
libfoo_la_SOURCES = foo.cc

In make check, I get this:

/bin/bash ./libtool --tag=CXX   --mode=link g++ -Wall -Wextra -Werror -ansi -fprofile-arcs -ftest-coverage -g -O0 -fprofile-arcs -ftest-coverage -L/usr/local/lib -Wl,-rpath /usr/local/lib  -o libfoo.la -rpath /usr/local/lib foo.lo  -lboost_thread-mt -lboost_system-mt -pthread 
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbeginS.o  .libs/foo.o   -L/usr/local/lib -lboost_thread-mt -lboost_system-mt -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crtn.o  -fprofile-arcs -O0 -fprofile-arcs -Wl,-rpath -pthread   -pthread -Wl,-soname -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0
/usr/bin/ld: cannot find libfoo.so.0: No such file or directory
collect2: ld returned 1 exit status

Notice the missing library is precisely the one I’m trying to compile.

(The library is not libfoo, but I am able to reproduce the same error with this stub library. The Makefile.am and error lines above are literal and unedited.)

If I change the automake lines to

check_LTLIBRARIES += libfoo.la
libfoo_la_SOURCES = foo.cc

then the compile looks like this:

/bin/bash ./libtool --tag=CXX   --mode=link g++ -Wall -Wextra -Werror -ansi -fprofile-arcs -ftest-coverage -g -O0 -fprofile-arcs -ftest-coverage -L/usr/local/lib -Wl,-rpath /usr/local/lib  -o libfoo.la  foo.lo  -lboost_thread-mt -lboost_system-mt -pthread 
libtool: link: ar cru .libs/libfoo.a .libs/foo.o 
libtool: link: ranlib .libs/libfoo.a
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && cp -p "../libfoo.la" "libfoo.la" )

..and everything works fine (except my library isn’t installed, being in check_.)

Notice the only difference in the command lines is some additional arguments in the 2nd one:

… -Wl,-rpath /usr/local/lib -o libfoo.la -rpath /usr/local/lib foo.lo -lboost_thread-mt …

I don’t know offhand if this new argument shouldn’t be there, but it does appear to be causing the problem. Does anyone know what I’m missing?

Some more details:

  • On osx lion, this works fine (and the command lines are different.) This error manifests on
    ubuntu 12.04, possibly other linuxes.
  • noinst_LTLIBRARIES and EXTRA_LTLIBRARIES work like check_LTLIBRARIES: no extra arguments, and it links. It seems libtool ‘convenience’ libraries are specifically the ones without these arguments.
  • automake 1.11.1
  • autoconf 2.68
  • libtool 2.4

EDIT

(Manually) dropping -Wl,-rpath /usr/local/lib from the arguments also fixes the problem.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I did it to myself. While bringing in autoconf support for boost, I encountered a bug described here. My work-around followed the suggestion of one post:

    diff --git a/m4/boost.m4 b/m4/boost.m4
index 3d4e47c..9dd0c43 100644
--- a/m4/boost.m4
+++ b/m4/boost.m4
@@ -403,7 +403,7 @@ dnl generated only once above (before we start the for loops).
       LDFLAGS=$boost_save_LDFLAGS
       LIBS=$boost_save_LIBS
       if test x"$Boost_lib" = xyes; then
-        Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-R$boost_ldpath"
+        Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-rpath $boost_ldpath"
         Boost_lib_LDPATH="$boost_ldpath"
         break 6
       else

    The -rpath introduced here is the same one apparently causing the issue. If I revert this change, the problem goes away (I am of course left with the first issue, but that’s another story.)

    • 0