GNU bug report logs -
#9595
-module is not enough to get an .so
Previous Next
To reply to this bug, email your comments to 9595 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-libtool <at> gnu.org
:
bug#9595
; Package
libtool
.
(Sat, 24 Sep 2011 22:01:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Reuben Thomas <rrt <at> sc3d.org>
:
New bug report received and forwarded. Copy sent to
bug-libtool <at> gnu.org
.
(Sat, 24 Sep 2011 22:01:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <tromey <at> redhat.com>
Date: Sat Jan 13 18:56:19 2001 +0000
2001-01-13 Kevin Ryde <user42 <at> zip.com.au>
* automake.in (handle_ltlibraries): Omit -rpath from
check_LTLIBRARIES, as per noinst_LTLIBRARIES.
--
http://rrt.sc3d.org
This bug report was last modified 13 years and 323 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.