> I'm kind of torn on this one: this has been around for a while and > dropping it would be an ABI break, but the feedback from distro folks is > pretty consistently that multlib is broken on RISC-V. If it's really > unusably broken then I could buy the argument that there's no binaries > (and thus no ABI to break), but there's at some base multilib > functionality working -- I build multilib cross toolchains regularly, > for example, and they can build simple stuff.
So as the one who initially bootstrapped rv64 for Gentoo in full multilib mode... 1) Multilib works in principle. 2) The main problem with the lib64/lp64d etc paths is that software authors out there assume that the "libdir" is a single-depth directory. In Gentoo specifically, "normally" $(get_libdir) echos "lib64" and people assume that "$(get_libdir)/../" ends up at a specific location. Now if $(get_libdir) echos "lib64/lp64" ... That is not limited to the Gentoo side though. 3) The second problem is that binary-distributed software, built for non-multilib lp64d (hey, rust, I'm talking of you), of course use "lib64" and not "lib64/lp64d". 4) The third problem (more of an oddity) is that for rv32 the non-multilib fallback for the "lib32/ilp32d" directories is not "lib32" but "lib". With incompatible changes some time ago (the 17.0 to 20.0 profile change), 2) and 3) was "fixed" in Gentoo (where we officially only do rv64 so far because usermode qemu-riscv32 is b0rk b0rk b0rk). What I did: * The main ABI (normally lp64d) was moved to lib64 https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/multilib.eclass#n419 * Compat symlinks, e.g. /usr/lib64/lp64d -> . were installed. This * *mostly* solves 2) because only a small subset of libraries is installed for the non-default ABI, * and solves 3) because the default ABI is in the fallback non-multilib location (but also accessible via the symlink if something insists). https://gentoo.osuosl.org/releases/riscv/autobuilds/ Given these hacks, our multilib stages are not linked on the website, but they are built just fine and should work just fine. Feel free to try in a chroot / with qemu / ... > I always find making that "nobody's used it" argument really hard, > there's just too many users to try and track everyone down. We're in > kind of a weird spot with RISC-V in general when it comes to ABI stuff: > we were probably a bit overly optimistic about how fast any of this was > going to get used when we committed to the ABI freeze, but any ABi break > has such a huge potential for user headaches that I'm not sure it's > going to be possible. It means we're stuck with some baggage, and while > it's a headache to keep around stuff that's probably not all that useful > I think it's just what we've got to live with. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
