Gentoo Archives: gentoo-dev

From: Palmer Dabbelt <palmer@×××××××.com>
To: dilfridge@g.o
Cc: gentoo-dev@l.g.o, riscv@g.o, mgorny@g.o
Subject: Re: [gentoo-dev] How to structure our RISC-V support
Date: Thu, 06 May 2021 20:34:56
Message-Id: mhng-559607e9-da41-4711-8eac-09218ecdcfff@palmerdabbelt-glaptop
In Reply to: Re: [gentoo-dev] How to structure our RISC-V support by "Andreas K. Huettel"
1 On Thu, 06 May 2021 13:30:45 PDT (-0700), dilfridge@g.o wrote:
2 >>
3 >> Haven't I told you using two-level libdirs is stupid? So yes,
4 >> please do that and let us be happy once again.
5 >>
6 >> That said, where does lp64gc land? Or isnon-multilib
7 >> one-or-the-other the goal?
8 >
9 > It would be non-multilib one-or-the-other then for us.
10 > The main relevant combination is rv64gc/lp64d, which is arguably what
11 > a linux machine "should have".
12 >
13 > (I could also imagine to keep rv64imac/lp64 profile and stages (also
14 > using lib64), these would have to mask stuff like rust then though.)
15 >
16 > (Unless Palmer et al come up with a fix for the libdirs on the
17 > upstream side of things. Already e.g. libdir=lib64-lp64d would be much
18 > easier to handle I suspect.)
19
20 TBH: I'm not really going to come up with something better beacuse I
21 came up with the current (and likely broken) scheme and I still don't
22 fully understand why. So if you have suggestions as to something that
23 would actually work that would be great, as otherwise I'm just going to
24 come up with something broken again ;)
25
26 Is the constraint just "no sub-directories for libraries"? IIRC we did
27 that because someone else was already doing it and it seems to be less
28 of a FHS break that adding a bunch of first-level directories. I can
29 totally buy I was just wrong, though. If that's all we need then this
30 shouldn't be that hard to fix upstream, of course it'll take a while to
31 get everyone updated but at least we'll have a way to steer everyone.

Replies

Subject Author
Re: [gentoo-dev] How to structure our RISC-V support "Andreas K. Huettel" <dilfridge@g.o>