Re: [gentoo-dev] How to structure our RISC-V support
Am Donnerstag, 6. Mai 2021, 22:34:52 CEST schrieb Palmer Dabbelt: > > TBH: I'm not really going to come up with something better beacuse I > came up with the current (and likely broken) scheme and I still > don't fully understand why. So if you have suggestions as to > something that would actually work that would be great, as > otherwise I'm just going to come up with something broken again ;) > Heh. No worries. I actually liked the idea, just until the moment when I remembered that we had been campaigning for months to replace all absolute symlinks in Gentoo with relative ones. And suddenly there is only on riscv not enough "../" in the link. > Is the constraint just "no sub-directories for libraries"? IIRC we > did that because someone else was already doing it and it seems to > be less of a FHS break that adding a bunch of first-level > directories. I need to read up on FHS. Time... -- 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.
Re: [gentoo-dev] How to structure our RISC-V support
> I'm fine with rust masked in lp64/other profile.. > but in my opinion: it's really up to upstream should fix/support it > > > (Unless Palmer et al come up with a fix for the libdirs on the > > upstream side of things. Already e.g. libdir=lib64-lp64d would be > > much easier to handle I suspect.) > > using one level path (eg. lib64-lp64d) won't fix the problem, > the root cause is that we use a 'non-standard' lib path (QT5, Cmake > issue), not matter it's one level or two level path, see bug here I suspect this may need some more analysis. But, if we transition in non-multilib cases to normal lib64, then we have all the time in the world to figure it out. -- 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.
Re: [gentoo-dev] How to structure our RISC-V support
> > 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.
Re: [gentoo-dev] How to structure our RISC-V support
On Fri, 2021-05-07 at 14:15 +0800, Yixun Lan wrote: > On 22:30 Thu 06 May , Andreas K. Huettel wrote: > > > > > > 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? > > > > It would be non-multilib one-or-the-other then for us. > > The main relevant combination is rv64gc/lp64d, which is arguably what > > a linux machine "should have". > > > > (I could also imagine to keep rv64imac/lp64 profile and stages (also > > using lib64), these would have to mask stuff like rust then though.) > > > I'm fine with rust masked in lp64/other profile.. > but in my opinion: it's really up to upstream should fix/support it > > > (Unless Palmer et al come up with a fix for the libdirs on the > > upstream side of things. Already e.g. libdir=lib64-lp64d would be much > > easier to handle I suspect.) > > using one level path (eg. lib64-lp64d) won't fix the problem, > the root cause is that we use a 'non-standard' lib path (QT5, Cmake issue), > not matter it's one level or two level path, see bug here [1] > > [1] https://bugs.gentoo.org/781134 > https://gitlab.kitware.com/cmake/cmake/-/issues/22138 > Maybe it doesn't matter for CMake but it does matter for us simpletons who want '../' to work as its supposed to. -- Best regards, Michał Górny
