Hi there,
Sorry for the long latency.
* Philip Martin wrote on Fri, Oct 07, 2005 at 01:38:48AM CEST:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
>
> > After reading bug #291641, I'd have to agree this is a problem
> > with the linker.
>
> It's not quite so clear to me. Here's the script I've been using to
> duplicate the problem:
Hehe, nice script. Take it, do a
sed -e 's/libtool/$libtool/'
on it, and add
: ${libtool=libtool}
somewhere at the top.
(It's also very instructive to look at the output of objdump -p
by the way, in addition to `libtool --mode=execute ldd' which gives a
skewed view through LD_LIBRARY_PATH; so you might want to add that).
Now let's pretend we're not installing to $PWD/zz/lib, but
to /usr/lib. Just for a minute, ok?
Well, to simulate what libtool would do iff the installation path
is in both link editor's and the runtime linker's default search
path (and without actually messing with our installation), we need to
fake libtool knowledge:
sed < libtool > libtool-fake \
-e "s#^\(sys_lib_search_path_spec=.*\)\"\$#\1 $PWD/zz/lib\"#" \
-e "s#^\(sys_lib_dlsearch_path_spec=.*\)\"\$#\1 $PWD/zz/lib\"#"
Now try
libtool=./libtool-fake ./run
(given that your script is named 'run').
It will pass :)
In the following analysis, let 'libdir' be '$PWD/zz/lib'.
- two differences: libj won't be passed the -rpath $libdir,
hence won't have DT_RPATH $libdir. It will still have the DT_RPATH
entry for the uninstalled libi, correctly.
- linking of k (precise: zz/k/.libs/k) won't have *any* -rpath argument.
And it won't be passed '-li' on the command line.
This is precisely the situation in which the GNU ld mechanism
for walking DT_NEEDED + DT_RPATH combinations of indirect dependencies
(libraries pulled in by other libraries) works.
> Note the --rpath to the install directory, that goes straight through
> to the linker, and it appears that the command line option overrides
> RPATH in the library.
Correct.
> Is it a linker bug for the command line option to have priority?
> I don't know.
It's documented that way.
> Perhaps libtool should not be passing that --rpath during the link?
Well. In above scenario, it would fix the problem.
In general it's harder to avoid. Imagine we have a dependency on
another library, from another package, already installed. If it was
installed in a path which the linker won't find by itself, the -rpath
will be necessary for the final _installed_ executable, so that it can
find its libraries on its own.
What we could do now, to save the day, would be to disallow fast_install.
Relinking upon installation would have to be required then. This would
enable, on Linux, to remove the -rpath to $libdir from the uninstalled.
I believe.
Hmm. Sounds like quite a bit of work. And pretty dangerous, too. We'd
need lots of good tests. One thing to always keep in mind (for upstream
GNU Libtool) is that this change of operation must not change anything
on other systems. A good way to get many people annoyed at you.
Another way of solving the problem in libtool could be to do the grunt
work of traversing all indirect libraries and adding rpaths for them,
too. Ugly. Would likely need '.la' files for all of them so it could
be done portably. OTOH, it may be the only way we could get decent
indirect dependencies support on more than just GNU ld.
See, the way I see it, this whole automatic DT_NEEDED + DT_RPATH walking
by the link editor works best when all installed paths are found by
default, and thus the final program won't need any overrides, which then
make the linker turn off the weaker search methods.
Another thing not to underestimate is library authors that forget to
list all their dependent libraries they use directly. Finding a bug
related to this is bound to be horrific.
> Perhaps libtool should be passing the build dir instead? (That might
> mean that libtool has to relink the executable at install time to get
> the correct final rpath.) Does that make it a libtool bug?
Hmm. I'd call it a ld limitation for which libtool does not yet have an
adequate workaround. But that may just be me. :)
Also, it may be helpful to note that there has been quite a bit of
discussion on the libtool list, on and off, about decent support for
indirect dependencies. Not many patches yet, though. :-/
Cheers,
Ralf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
