bug-libtool
[Top][All Lists]
Advanced

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

Re: mixed prefix libraries ...


From: Ralf Wildenhues
Subject: Re: mixed prefix libraries ...
Date: Sat, 26 Jun 2010 12:49:39 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

Hello Michael,

thanks for the report.

* Michael Meeks wrote on Fri, Jun 25, 2010 at 05:57:38PM CEST:
>       I'm having problems running libtool linked binaries inside my build
> environment. This is related [ I believe ] to conflicts between system
> versions of libraries vs. those installed on my prefix.
[...]
>       Unfortunately, we have .la files for many of the dependents of this gtk
> + library, including a bus-load of X libraries installed into /usr/lib.
> 
>       These in turn cause $temp_rpath to have /usr/lib: prepended to the
> LD_LIBRARY_PATH before /opt/hgnome/lib.
> 
>       This causes the wrong glib to be linked to when the libtool wrapper
> script is called.

There are three aspects to this issue:

First, an rpath or LD_LIBRARY_PATH entry to /usr/lib seems like a bug;
is that directory not in sys_lib_dlsearch_path_spec, and if not, why?
If it is, then no rpath should be added to point there.

>       Sooo ... my thought is: why do we have this rather complicated setup of
> walking .la files trying to find the right paths etc. ? why do we even
> try to use a complex LD_LIBRARY_PATH ?
> 
>       Would it not be rather easier, wherever possible, to create symlinks
> for the correct (individual) libraries into .libs - and have a single
> LD_LIBRARY_PATH entry for that directory ?

Yes, this suggestion has come up before, from OpenBSD developers; that
systems' runtime linking features make this an even more attractive
idea.

This idea definitely has some merit.  It has the potential to fix some
cases (such as yours) on at least some systems.  One problem with it is
that at least on some systems, libtool isn't always smart enough to
really find all libraries the way the linker does; this could cause
regressions.

Another technical complication (but not a deal-breaker here) is that
currently, libtool employs one of several different methods to get
uninstalled programs linked against a mix of uninstalled and installed
libraries: a wrapper script or executable for setting up $shlibpath_var,
relinking of the uninstalled or the installed program to contain rpath
entries for uninstalled libs, ...

>       That way we would have a more robust solution, with full control over
> which libraries to link from what prefix.

Understood.

>       Failing that it is unclear to me why linking works but running does
> not ;-) how can it be that we manage to get the right paths linked into
> the .libs/gtk-query-immodules binary and then break them with these
> extra LD_LIBRARY_PATH that (apparently) are not really necessary ?

Well, the final aspect to this issue is: if your setup is so complex
that a linear ordering of directories from which to pick libraries will
not work for your complete library tree, then maybe later on you will
run into problems anyway.  Yes, I know that GNU ld is smarter here with
its handling of indirect dependencies than libtool, but it's easy enough
to shoot yourself in the foot also on GNU/Linux there.

So one question is: should the algorithm for uninstalled deplibs be
smarter than the situation with installed stuff, potentially leading to
problems only found out after "make install"?  That would counter
finding issues as early as possible.

TBH, I'm really not sure which weighs more here.  If somebody wants to
pursue the other approach, and it's done on a per-system basis (so that
we can incrementally enable it for those systems where it is deemed
safe) then I'm definitely interested, but maybe it should have some
safety measure to warn the user of potential problems to be had after
"make install", iff we can detect them.

Hope that helps.

Cheers,
Ralf




reply via email to

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