1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
* Overview
This is a testcase for what seems to be a bug in the libtool.
* Synopsis
Imagine a project consististing of at least one installable shared
library and installable binary program, which is linked with that
library. The problem manifests itself on systems where relink_command
is set in the resulting wrapper script for the binary, such as
GNU/Linux, if one or more -Wl,-rpath linker options appear in the
_LDFLAGS variable of the Makefile.am responsible for building the
binary. When this happens, directories supplied with these options
take precedence over locations in the build tree. If a previous
version of the library is already installed on the system and one of
the -Wl,-rpath options points to its location, the local version of
the binary (.libs/lt-name) will be linked with the installed library,
instead of its local copy. This leads to undesirable consequences,
e.g. if the package provides a test suite, it will likely fail, since
it will be using old library version.
* Real-life case
The present testcase has been derived from a real life case I
encountered in GNU mailutils [1]. The package can optionally be built
with MIT Kerberos [2]. The configure script uses the krb5-config tool
to obtain the linker options needed for linking with the library. The
tool is invoked as "krb5-config --libs" and its output is then added
to the *_LDADD variable of several Makefile.am's via the substitution
variable [3]. However, it happens that the output in question
contains the -Wl,-rpath linker option, e.g.:
$ krb5-config --libs
-L/usr/lib64 -Wl,--enable-new-dtags -Wl,-rpath -Wl,/usr/lib64 -lkrb5 -lk5crypto -lcom_err
When this option makes its way to the *_LDADD variable, the local (not
yet installed) version of the mailutils programs uses old libraries if
a prior version of mailutils is already installed.
* The test case
I attempted to create a minimal testcase. It consists of:
- lib/libltb1.la
A library providing a single test function ltb_version(), which
prints on stdout an identifier string defined at compile time.
- src/ltr1
A binary linked with libltb1.la and invoking ltb_version().
The ltb1_LDFLAGS variable contains the expansion of the variable
CF_LIB_FLAGS, defined in configure.ac and containing -Wl.-rpath
-Wl,/usr/local/lib
* Testing
Follow these steps:
1. Configure the package with a prominent identifier string:
./configure LTBUG_ID='installed'
2. Make and install it to /usr/local:
make
make install # obviously, as root
3. Clean up the source tree:
make distclean
4. Configure the package with another identifier and build it again:
./configure LTBUG_ID='local'
make
6. Run src/lbt1. It will display
ltbug: installed
instead of the expected
ltbug: local
Inspecting the src/lt-lbt1 binary with ldd shows that it is linked
against installed version of libltb1.so
* Proposed solution
So far, mailutils filters out all '-Wl,' options from the output of
the external config tool, before assigning it to the substitution
variable. However, that does not seem to be a right solution. The
proposed patch to ltmain.in ensures that any arguments to -Wl,-rpath
options are appended to the end of the linker command line, after any
eventual local directories [4]. The patch is built for the commit
b9b44533fbf7c7752ffd255c3d09cc360e24183b of libtool.
* References
[1] https://mailutils.org
[2] http://web.mit.edu/kerberos/
[3] http://git.savannah.gnu.org/cgit/mailutils.git/tree/am/gssapi.m4
(mirror at http://git.gnu.org.ua/cgit/mailutils.git/tree/am/gssapi.m4)
[4] 0001-ltmain.in-append-rpath-option-arguments-to-finalize_.patch
|
