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.
