From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D99EA1382C5 for ; Fri, 7 May 2021 07:39:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2A871E0830; Fri, 7 May 2021 07:39:00 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DF129E0822 for ; Fri, 7 May 2021 07:38:59 +0000 (UTC) Message-ID: <6184986d290358bcec30d8df6d39cd838d98b909.camel@gentoo.org> Subject: Re: [gentoo-dev] How to structure our RISC-V support From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Cc: riscv@gentoo.org, Palmer Dabbelt Date: Fri, 07 May 2021 09:38:54 +0200 In-Reply-To: References: <14808987.iMDcRRXYNz@pinacolada> <96fa909d025ca0f171bb8050cb4f00d43a6a306d.camel@gentoo.org> <7320181.F8r316W7xa@pinacolada> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 6ac22e09-4ed7-4dc9-8a41-e4da73231059 X-Archives-Hash: c9255796d17ea944348b4cf8e8a9d92c 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