So, here's what I took away from the thread. Please shout if you disagree.
1) Advertised riscv profiles will all be non-multilib and use /usr/ lib64 (or /usr/lib if we ever get around to riscv32). [A] 2) The standard for keywording and stabilization is rv64gc/lp64d. We keep stages for other variants [B] around if feasible, but on these important packages may be masked and unavailable [C]. 3) We try to internally keep the multilib variant with the two-stage path going for now, as very low-priority thing. [D] 4) Medium term we discuss with the RISC-V, glibc, gcc people how multilib could be simplified, and then switch the multilib settings once this comes to a conclusion. If there are no protests I'll start planning the path migration for 1). (Maybe making a riscv-specific new profile version is best.) Cheers, Andreas [A] Note that the actual specs use /usr/lib32/... [B] Other ABI (lp64) or other ISA (riscv32...) [C] See rust etc. [D] Low priority means, it pretty much won't build every now and then, as, e.g., right now [E]. [E] Our monkeypatched glibc-2.32 rv32 support was experimental enough so it didnt survive the transition to official upstream glibc-2.33 support, so the multilib stages will have to be re-bootstrapped. > 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" ... -- 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.
