On Thu, Feb 08, 2018 at 11:50:32AM -0800, Carlos O'Donell wrote:
> 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.
Yes, our currently built binaries have:
[Requesting program interpreter: /lib/ld-linux-riscv64-lp64d.so.1]
> 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.
This is great, a good summary.
What I'm going to do is work on a glibc.spec patch which I'll
circulate to you and glibc-owner before pushing anything.
However it takes 11 hours to build glibc in the emulation so
it'll be a while :-/
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
