On Thu, 06 May 2021 13:01:23 PDT (-0700), dilfri...@gentoo.org wrote:
Howdy.
I'm sending this not only to the team members on the alias, but also
to the whole dev list for discussion.
So far I've been trying to support in Gentoo the full risc-v multilib
directory structure and the ABI sets supported by glibc. According to
specs this means for riscv64
-mabi=rv64gc -march=lp64d
libdir = lib64/lp64d
("hardfloat")
-mabi=rv64imac -march=lp64
libdir = lib64/lp64
("softfloat")
and theoretically similar for riscv32 (which just landed in glibc and
is still broken in qemu-user).
However, this leads to several levels of pain (and I definitely dont
have time to deal with it myself):
a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads
to difficulties in build systems. Right now Qt5 and CMake are still
somewhat broken (in *Gentoo*).
b) Rust only supports rv64gc/lp64d. (Which is arguably what you should
have for decent Linux support.)
I'm pretty sure these are not the only things, but they are somewhat
symptomatic.
So, I would like to bring two proposals up for discussion.
1) We stop caring about anything except rv64gc/lp64d.
People can still bootstrap other stuff with crossdev etc, but the
Gentoo tree and the riscv keyword reflect that things work with above
-mabi and -march settings.
IMO dropping multilib is fine from a "working on real hardware"
perspective, as that's all anyone is going to have for the forseeable
future -- at least for the sort of hardware you'd want to run a
desktop/server style Linux distro on (something like buildroot might be
interested in other ISA/ABI combos).
That said, it seems like a lot of the distros are punting on multilib
because of this path issue. If that's really the worry then I wouldn't
be opposed to just fixing it in GCC/glibc. Ideally we'd be able to just
add paths so we don't break the ABI, but if the ABI we came up with
really hasn't been used by anyone then I wouldn't be opposed to breaking
it if it means we can actually get multilib up and running -- we'd have
to talk with a lot of people for that, though.
In the long run I think we will want multilib to work, as we're likely
to end up with some ISA extensions that are useful enough to want to
build general code for but not so useful that everyone has them -- B and
V, for example. We're a long way away from having good code gen for V
(at least for arbitrary code, some special libraries might show up
sooner), but B is a bit closer and might be amenable to having a system
built with it. That may be a bit less interesting for Gentoo, where
we're building things locally (and there shouldn't be any -bin packages
on RISC-V yet, we're not getting ports of proprietary stuff yet), but if
we can be a forcing function to put together a multlib ABI that actually
works then that's a win for everyone.
2) We drop the multilib paths and use "normal" lib64, with additional
"safety symlinks" (/usr)/lib64/lp64d -> .
This is what SuSE and (I think) Fedora already does. The symlink
should be there since "lib64" is NOT an official fallback coded into
gcc/glibc/binutils; the only fallback present is "lib" ...
IMO we can just fix that one upstream. If all the distros are going to
do it anyway then it'd be better to just fix it, there's not a lot of
sense in forcing everyone to patch these things. IIUC that one would be
an ABI-compatible addition, but again we'd need to talk about it in
GCC/glibc land (and with some other distro folks).
Sorry this is such a mess!
