[Bug backends/24488] ebl_openbackend might use wrong library search path

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|abidw: wrong results when   |ebl_openbackend might use
                   |running with ASAN runtim    |wrong library search path

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Mark Wielaard from comment #2)
> We discussed this on irc a bit and the real bug is indeed in the sanitizer.
> When overriding ldopen it doesn't obey the RUNPATH set in libdw.so. And so 
> 
> But on Fedora it still works because ebl_openbackend first tries to load
> from:
> 
> #ifndef LIBEBL_SUBDIR
> # define LIBEBL_SUBDIR PACKAGE
> #endif
> #define ORIGINDIR "$ORIGIN/../$LIB/" LIBEBL_SUBDIR "/"
> 
>         /* Give it a try.  At least the machine type matches.  First
>            try to load the module.  */
>         char dsoname[100];
>         strcpy (stpcpy (stpcpy (dsoname, ORIGINDIR "libebl_"),
>                         machines[cnt].dsoname),
>                 ".so");
> 
>         void *h = dlopen (dsoname, RTLD_LAZY);
> 
> This doesn't work on Debian based systems though.
> $LIB will expand to "lib" (on 32bit systems) or "lib64" (on 64bit systems).
> But on Debian (amd64) everything is installed under /usr/lib/x86_64-linux-gnu

Some experiments on Debian seem to point to $LIB expanding to
lib/x86_64-linux-gnu. But I cannot find any documentation for that. Debian's
own documentation 
https://manpages.debian.org/unstable/manpages/ld.so.8.en.html says:

  $LIB (or equivalently ${LIB})
    This expands to lib or lib64 depending on the architecture (e.g., on
x86-64, it expands to lib64 and on x86-32, it expands to lib). 

> It is not immediately clear why we use ../$LIB/
> I think we can just use #define ORIGINDIR "$ORIGIN/" LIBEBL_SUBDIR "/"

That won't work. The path is used for both binaries and libraries that rely on
ebl backends. When built in a binary (say eu-elflint) that doesn't use libdw we
need the ../$LIB/ part to get from prefix bin/ dir to the corresponding prefix
/lib[64] dir.

The original idea was that you could find the ebl backend libraries relative to
whereever the binary (eu-xxx) or library (libdw.so) were installed.

The problem on systems that use a deeper library paths we cannot use the same
search path for binaries and libraries (../ doesn't get us to the top of the
install prefix).

-- 
You are receiving this mail because:
You are on the CC list for the bug.