GNU bug report logs - #9595
-module is not enough to get an .so

Previous Next

Package: libtool;

Reported by: Reuben Thomas <rrt <at> sc3d.org>

Date: Sat, 24 Sep 2011 22:01:02 UTC

Severity: normal

To reply to this bug, email your comments to 9595 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-libtool <at> gnu.org
Subject: -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 <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.