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

[Bob Friesenhahn]

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?

> 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.

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.

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.

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

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/