bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9595: -module is not enough to get an .so


From: Reuben Thomas
Subject: bug#9595: -module is not enough to get an .so
Date: Sat, 24 Sep 2011 22:59:35 +0100

I want to build a test plugin in an automake project. For installed
plugins, I add them to pkglib_LTLIBRARIES, and the relevant .so files
are built in foo/.libs, whence I can extract them for testing.
However, libraries in check_LTLIBRARIES (or noinst_LTLIBRARIES) do not
have their .so files built, so my tests can't find them.

I can't just use the .la files, as I'm not linking against the plugin
files, but dlopening them (of course, using the appropriate variables
to get the .so suffix and .libs directory name).

I notice that in the .la file, dlname is empty for libraries in
check_LTLIBRARIES, yet the relevant library has -module in its
foo_la_LDFLAGS. The library is built, just not the .so file. From
looking at the output of make V=1, the difference appears to be that
the installed libraries are built with -rpath:

/bin/bash ../../libtool  --tag=CC   --mode=link gcc   -g -O2 -module
-avoid-version  -o struct.la -rpath
/home/rrt/local/x86_64/lib/lua/5.1/alien struct.lo
libtool: link: gcc -shared  .libs/struct.o      -Wl,-soname
-Wl,struct.so -o .libs/struct.so
libtool: link: gcc -shared  .libs/core.o   -lffi    -Wl,-soname
-Wl,core.so -o .libs/core.so
libtool: link: ( cd ".libs" && rm -f "struct.la" && ln -s
"../struct.la" "struct.la" )
libtool: link: ( cd ".libs" && rm -f "core.la" && ln -s "../core.la" "core.la" )

whereas the noinst/check libraries aren't:

/bin/bash ../libtool  --tag=CC   --mode=link gcc   -g -O2 -module
-avoid-version  -o alientest.la  alientest.lo
libtool: link: ar cru .libs/alientest.a .libs/alientest.o
libtool: link: ranlib .libs/alientest.a
libtool: link: ( cd ".libs" && rm -f "alientest.la" && ln -s
"../alientest.la" "alientest.la" )

I'm using libtool 2.2.6b (and automake 1.11.1). I can't see anything
in NEWS in git since 2.2.6b which bears on this issue.

However, I can see that the omission of -rpath is intentional, from
this commit message:

commit f15fa67ff2df0c7c147b7f61062fe6594d75be99
Author: Tom Tromey <address@hidden>
Date:   Sat Jan 13 18:56:19 2001 +0000

    2001-01-13  Kevin Ryde <address@hidden>

        * automake.in (handle_ltlibraries): Omit -rpath from
        check_LTLIBRARIES, as per noinst_LTLIBRARIES.

-- 
http://rrt.sc3d.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]