Gentoo Archives: gentoo-dev

From: Yixun Lan <dlan@g.o>
To: gentoo-dev@l.g.o
Cc: riscv@g.o, "Michał Górny" <mgorny@g.o>, Palmer Dabbelt <palmer@×××××××.com>
Subject: Re: [gentoo-dev] How to structure our RISC-V support
Date: Fri, 07 May 2021 06:16:00
Message-Id: YJTbESCtPGhYcFzM@ofant
In Reply to: Re: [gentoo-dev] How to structure our RISC-V support by "Andreas K. Huettel"
1 On 22:30 Thu 06 May , Andreas K. Huettel 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 I'm fine with rust masked in lp64/other profile..
17 but in my opinion: it's really up to upstream should fix/support it
18
19 > (Unless Palmer et al come up with a fix for the libdirs on the
20 > upstream side of things. Already e.g. libdir=lib64-lp64d would be much
21 > easier to handle I suspect.)
22
23 using one level path (eg. lib64-lp64d) won't fix the problem,
24 the root cause is that we use a 'non-standard' lib path (QT5, Cmake issue),
25 not matter it's one level or two level path, see bug here [1]
26
27 [1] https://bugs.gentoo.org/781134
28 https://gitlab.kitware.com/cmake/cmake/-/issues/22138
29
30 --
31 Yixun Lan (dlan)
32 Gentoo Linux Developer
33 GPG Key ID AABEFD55

Replies

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