> > 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
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)