Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: riscv@g.o, Palmer Dabbelt <palmer@×××××××.com>
Subject: Re: [gentoo-dev] How to structure our RISC-V support
Date: Fri, 07 May 2021 07:39:03
Message-Id: 6184986d290358bcec30d8df6d39cd838d98b909.camel@gentoo.org
In Reply to: Re: [gentoo-dev] How to structure our RISC-V support by Yixun Lan
1 On Fri, 2021-05-07 at 14:15 +0800, Yixun Lan wrote:
2 > On 22:30 Thu 06 May , Andreas K. Huettel wrote:
3 > > >
4 > > > Haven't I told you using two-level libdirs is stupid? So yes,
5 > > > please do that and let us be happy once again.
6 > > >
7 > > > That said, where does lp64gc land? Or isnon-multilib
8 > > > one-or-the-other the goal?
9 > >
10 > > It would be non-multilib one-or-the-other then for us.
11 > > The main relevant combination is rv64gc/lp64d, which is arguably what
12 > > a linux machine "should have".
13 > >
14 > > (I could also imagine to keep rv64imac/lp64 profile and stages (also
15 > > using lib64), these would have to mask stuff like rust then though.)
16 > >
17 > I'm fine with rust masked in lp64/other profile..
18 > but in my opinion: it's really up to upstream should fix/support it
19 >
20 > > (Unless Palmer et al come up with a fix for the libdirs on the
21 > > upstream side of things. Already e.g. libdir=lib64-lp64d would be much
22 > > easier to handle I suspect.)
23 >
24 > using one level path (eg. lib64-lp64d) won't fix the problem,
25 > the root cause is that we use a 'non-standard' lib path (QT5, Cmake issue),
26 > not matter it's one level or two level path, see bug here [1]
27 >
28 > [1] https://bugs.gentoo.org/781134
29 > https://gitlab.kitware.com/cmake/cmake/-/issues/22138
30 >
31
32 Maybe it doesn't matter for CMake but it does matter for us simpletons
33 who want '../' to work as its supposed to.
34
35 --
36 Best regards,
37 Michał Górny