> > 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. > > fine by me, for current software/upstream state, it's probably the > most practical way to only support lp64d, this will significantly > ease our life .. besides, it's relatively easy if people want to > support more (lp64/lp32..) later >
++ > > 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" ... > can we use different scheme for non-multilib vs multilib? > 1) non-multilibe: just use "normal" lib64, keep align with other > ARCHs (amd64)? ++ > 2) multilib: just stick to current two level lib path We can try that but it doesn't solve any of our problems (and we'd have to keep carrying the two-level dir patches). (I've already decided some time ago that supporting real multilib stages is too much effort for insufficient gain and stopped publishing them. Until recently I still built them; since glibc-2.33 they broke and while I know how to fix things I haven't had time to do it yet.) So if we keep the multilib scheme around, then IMHO only as internal workaround until we/upstream/... have figured out a better directory scheme. -- 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.
