Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?

[Nish Aravamudan]

On 16.02.2017 [17:39:59 -0600], Bob Friesenhahn wrote:
> On Thu, 16 Feb 2017, Nish Aravamudan wrote:
> 
> > I am trying to get to the bottom of an odd build failure on Ubuntu 17.04
> > with heimdal. I believe the underlying issue is a bug in libtool, but
> > I'm not confident in my analysis (some of it is also at
> > https://github.com/heimdal/heimdal/issues/241), but here's what I have,
> > I would appreciate any feedback!
> > 
> > Using the system sqlite3 (/usr/lib/x86_64-linux-gnu/) via configure, we
> > end up inserting the above path into LD_LIBRARY_PATH for build-time
> > generated wrapper scripts and since we also happen to have heimdal
> > libraries install at the system-level, the system heimdal libraries are
> > used by the tests instead of the build-local ones. This is bad for two
> > reasons: a) it fails in this case because of an ABI mismatch and b) we
> > are trying to test the built libraries, not the system installed ones
> > when the library in question is built by this package.
> 
> Do your test cases use
> 
>  ./libtool --mode=execute ./testprogram
> 
> or equivalent to assure that ./testprogram is executed with correct library
> paths?

I do not believe so, the tests (heimdal self-tests) are run via a
Makefile target which calls the generated wrapper script(s).

> > It seems like there is rarely, if ever, a case to put a system library
> > path before a non-system library path in the wrapper script, and in
> > particular, it seems like ltmain.sh actually detects adding the system
> > path to compile_rpath and finalize_rpath. Is it correct to do the same
> > elision in temp_rpath? e.g.
> 
> Without studying the details, it is worth noting that other software
> delivering libraries does manage to successfully test the uninstalled
> libraries even if installed libraries are present.  For operating systems
> where this is deemed not possible (or which hard code paths to the libraries
> used), libtool builds with hard-coded run-paths and then re-links at install
> time.

This is Linux, if it matters (Ubuntu 17.04) -- I will look at these
libtool options.

> Problems could still occur if a library used has a hard-coded run path baked
> into it so that the undesired directory is still used.

Right, we'd want the installed library(ies) to use the system for
satisfying dependencies.

> Problems could also accur if libraries are linked in the wrong order (e.g.
> building/linking in the wrong order in a recursive build) or with wrong
> paths such that a system library was used.

Right.

> I am definitely aware of issues under Microsoft Windows, which does not seem
> to offer sufficient control of where files come from.

I really appreciate the response! From what I can tell, though, the
temp_rpath variable is not actually used to compile/link anything, it's
only used for the wrapper script generator. And I don't understand how
it would be correct for an explicit LD_LIBRARY_PATH specification (as
done by the wrapper generator) to have the system library path anywhere
before the end of the list. Otherwise, if any of the required library
dependencies are installed, the somewhat arbitrary set before the system
library path in LD_LIBRARY_PATH will use the built libraries and the
somewhat arbitrary set after the system library path in LD_LIBRARY_PATH
will use the system libraries without any indication of a problem -- and
it becomes rather murky what is actually being tested.

Thanks,
Nish

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd