On 02/08/2018 06:51 AM, david.abdurachmanov@xxxxxxxxx wrote:
>> We could do a downstream patch.
>
> This would be a minimal patch based on quick look into glibc code. We
> could force it to act as, e.g AArch64. I worry, that this would be
> custom from what is expected in RISC-V software ecosystem. If we stay
> with /lib64/lp64d/ then we probably need to do more fixing in packages,
> because I doubt everything is using %{_libdir}.
>
> Alternative being discussed right now at #fedora-riscv is to use
> symlinks, e.g. /usr/lib64/lp64d -> /usr/lib64 like we have /lib64 ->
> /usr/lib64
>
> If we can solve this issue with symlinks, then I would vote for that.
> Then we don't need to do a lot of fixing and we sorta have what's
> expected by glibc, or/and in general RISC-V software ecosystem.
I see two issues at hand:
(a) RISC-V software ecosystem compatibility.
(b) Technical implications and ABI compatibility.
In regards to (a), I agree completely with David, that deviating
from the RISC-V software ecosystem is going to cause adoption problems.
We should avoid changing what upstream has chosen. Symlinks should
solve the issue, and if they do not then that's a bug in the dynamic
loader and someone should immediately file the bug and the Fedora
glibc team will fix it.
In regards to (b), there are two very important distinctions to make:
(1) What is the path to the dynamic loader?
(2) What is the path to shared libraries?
Firstly, (1) is an ABI atrifact that all 3rd party libraries will
have encoded into the binaries PT_INTERP program header entry, and
for binaries compiled with an upstream the official path is listed
here:
https://sourceware.org/glibc/wiki/ABIList#RISC-V
Surprisingly it is /lib. So this means that rtlddir is /lib, and
the dynamic loader is uniquely placed in /lib *even though* it
is a 64-bit dynamic loader.
We *must* *not* deviate from this in Fedora, and this path must
exist to the loader, but it can be a symlink.
Secondly, (2) is all the libraries, and these we have much more
flexibility, we can really put them wherever we want, the DSO's
DT_NEEDED entries are SONAMES which are searched by our own loader
and since we control those search paths we could make things
work like we expect them to with all libraries in /lib64.
However, the upstream community has chosen /lib64/lp64 as the
location of the shared library directory e.g. slibdir, and that
means 3rd party binaries could have hard coded dlopen paths that
try to open specific libraries e.g. dlopen /lib64/lp64/libfoo.so.0
and if we don't at least symlink that path it will fail. Likewise
3rd party binaries may also use DT_RPATH and DT_RUNPATH to specify
specific search paths which may be based on /lib64/lp64 e.g.
/lib64/lp64/mozilla/plugins.
In summary:
- We must minimally provide a symlink for /lib/ld-linux-riscv64-lp64d.so.1
- We must minimally provide a symlink for /lib64/lp64d
- As Fedora glibc team lead I'm OK with symlinks.
I'm happy to see both of these symlinks in glibc.spec point to
wherever we as a community decide we want to see things.
--
Cheers,
Carlos.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
