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 |