On Fri, 2021-05-07 at 14:15 +0800, Yixun Lan wrote: > On 22:30 Thu 06 May , Andreas K. Huettel wrote: > > > > > > Haven't I told you using two-level libdirs is stupid? So yes, > > > please do that and let us be happy once again. > > > > > > That said, where does lp64gc land? Or isnon-multilib > > > one-or-the-other the goal? > > > > It would be non-multilib one-or-the-other then for us. > > The main relevant combination is rv64gc/lp64d, which is arguably what > > a linux machine "should have". > > > > (I could also imagine to keep rv64imac/lp64 profile and stages (also > > using lib64), these would have to mask stuff like rust then though.) > > > I'm fine with rust masked in lp64/other profile.. > but in my opinion: it's really up to upstream should fix/support it > > > (Unless Palmer et al come up with a fix for the libdirs on the > > upstream side of things. Already e.g. libdir=lib64-lp64d would be much > > easier to handle I suspect.) > > using one level path (eg. lib64-lp64d) won't fix the problem, > the root cause is that we use a 'non-standard' lib path (QT5, Cmake issue), > not matter it's one level or two level path, see bug here [1] > > [1] https://bugs.gentoo.org/781134 > https://gitlab.kitware.com/cmake/cmake/-/issues/22138 >
Maybe it doesn't matter for CMake but it does matter for us simpletons who want '../' to work as its supposed to. -- Best regards, Michał Górny
