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. |