On Thu, 2021-05-06 at 22:01 +0200, Andreas K. Huettel 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.
>
> 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" ...
>
> Opinions?
>
Haven't I told you using two-level libdirs is stupid? So yes, please do
that and let us be happy once again.
That said, where does lp64gc land? Or isnon-multilib one-or-the-other
the goal?
--
Best regards,
Michał Górny
