Re: [gentoo-dev] How to structure our RISC-V support -- Summary
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.
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
Re: [gentoo-dev] How to structure our RISC-V support
On 22:01 Thu 06 May , Andreas K. Huettel wrote:
> Howdy.
>
> I'm sending this not only to the team members on the alias, but also
> to the whole dev list for discussion.
>
> So far I've been trying to support in Gentoo the full risc-v multilib
> directory structure and the ABI sets supported by glibc. According to
> specs this means for riscv64
>
> -mabi=rv64gc -march=lp64d
> libdir = lib64/lp64d
> ("hardfloat")
>
> -mabi=rv64imac -march=lp64
> libdir = lib64/lp64
> ("softfloat")
>
> and theoretically similar for riscv32 (which just landed in glibc and
> is still broken in qemu-user).
>
> However, this leads to several levels of pain (and I definitely dont
> have time to deal with it myself):
>
> a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads
> to difficulties in build systems. Right now Qt5 and CMake are still
> somewhat broken (in *Gentoo*).
>
> b) Rust only supports rv64gc/lp64d. (Which is arguably what you should
> have for decent Linux support.)
>
> I'm pretty sure these are not the only things, but they are somewhat
> symptomatic.
>
> 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.
>
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
> --
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, toolchain, base-system, perl, libreoffice)
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
Re: [gentoo-dev] How to structure our RISC-V support
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 -- Yixun Lan (dlan) Gentoo Linux Developer GPG Key ID AABEFD55
Re: [gentoo-dev] How to structure our RISC-V support
On Thu, 06 May 2021 13:30:45 PDT (-0700), dilfri...@gentoo.org 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.) (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.) 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 ;) 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 can totally buy I was just wrong, though. If that's all we need then this shouldn't be that hard to fix upstream, of course it'll take a while to get everyone updated but at least we'll have a way to steer everyone.
Re: [gentoo-dev] How to structure our RISC-V support
> > 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.) (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.) -- 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 Thu, 2021-05-06 at 22:01 +0200, Andreas K. Huettel wrote:
> Howdy.
>
> I'm sending this not only to the team members on the alias, but also
> to the whole dev list for discussion.
>
> So far I've been trying to support in Gentoo the full risc-v multilib
> directory structure and the ABI sets supported by glibc. According to
> specs this means for riscv64
>
> -mabi=rv64gc -march=lp64d
> libdir = lib64/lp64d
> ("hardfloat")
>
> -mabi=rv64imac -march=lp64
> libdir = lib64/lp64
> ("softfloat")
>
> and theoretically similar for riscv32 (which just landed in glibc and
> is still broken in qemu-user).
>
> However, this leads to several levels of pain (and I definitely dont
> have time to deal with it myself):
>
> a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads
> to difficulties in build systems. Right now Qt5 and CMake are still
> somewhat broken (in *Gentoo*).
>
> b) Rust only supports rv64gc/lp64d. (Which is arguably what you should
> have for decent Linux support.)
>
> I'm pretty sure these are not the only things, but they are somewhat
> symptomatic.
>
> 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" ...
>
> Opinions?
>
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?
--
Best regards,
Michał Górny
Re: [gentoo-dev] How to structure our RISC-V support
>
> -mabi=rv64gc -march=lp64d
should be -march=rv64gc -mabi=lp64d
> libdir = lib64/lp64d
> ("hardfloat")
>
> -mabi=rv64imac -march=lp64
should be -march=rv64imac -mabi=lp64
> libdir = lib64/lp64
> ("softfloat")
>
(but that doesnt change the rest of the argument)
--
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.
[gentoo-dev] How to structure our RISC-V support
Howdy.
I'm sending this not only to the team members on the alias, but also
to the whole dev list for discussion.
So far I've been trying to support in Gentoo the full risc-v multilib
directory structure and the ABI sets supported by glibc. According to
specs this means for riscv64
-mabi=rv64gc -march=lp64d
libdir = lib64/lp64d
("hardfloat")
-mabi=rv64imac -march=lp64
libdir = lib64/lp64
("softfloat")
and theoretically similar for riscv32 (which just landed in glibc and
is still broken in qemu-user).
However, this leads to several levels of pain (and I definitely dont
have time to deal with it myself):
a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads
to difficulties in build systems. Right now Qt5 and CMake are still
somewhat broken (in *Gentoo*).
b) Rust only supports rv64gc/lp64d. (Which is arguably what you should
have for decent Linux support.)
I'm pretty sure these are not the only things, but they are somewhat
symptomatic.
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" ...
Opinions?
Cheers,
Andreas
--
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.
