libebl: Try harder to find backend library in bin and lib origin paths.
authorMark Wielaard <mark@klomp.org>
Sat, 11 May 2019 14:55:01 +0000 (16:55 +0200)
committerMark Wielaard <mark@klomp.org>
Thu, 30 May 2019 17:05:17 +0000 (19:05 +0200)
commitbfcf8b1fee8805b42b262baf352c58574df59362
treecb2d60ec4fb3d29fcac95e63a82aa5092a182bcf
parentd7193bd7c9dc2a979352eee7fc446dacd3e97779
libebl: Try harder to find backend library in bin and lib origin paths.

eblopenbackend tries to find libraries based on the $ORIGIN/../$LIB/
path. But depending on whether the system is multilib or multiarch
this doesn't always work. On multilib systems $LIB is always just one
directory deep (it is either .../lib or .../lib64) but on multiarch
systems it can be multiple directories deep (.../lib/x86_64-linux-gnu).
This means that on multiarch systems $ORIGIN/../$LIB only works for
binaries (where origin is .../bin/), but not for libraries.

Most of the time it still works because of RPATH which is tried afterwards.
But RPATH processing does not always work reliable.

So try multiple paths first. The first time using the $ORIGIN as if it
came from an executable (in bin/) and then using the $ORIGIN as if it
came from an library (in lib[64]/ or lib/<arch>/). So first time using
../$LIB and second time just with the elfutils EBL_SUBDIR.

The first is what we do now and always work on multilib systems. The
second try works when loading relative to a library whether on a multilib
or multiarch system.

Then we use the same fallback (not using any path) we used already
(to take advantage of any RPATH or LD_LIBRARY_PATH setting).

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

Signed-off-by: Mark Wielaard <mark@klomp.org>
libebl/ChangeLog
libebl/eblopenbackend.c