From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 6C1173858422 for ; Tue, 15 Aug 2023 01:15:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C1173858422 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [192.168.100.1]) by gateway (Coremail) with SMTP id _____8Bxyep8_9lkOhsYAA--.40156S3; Mon, 14 Aug 2023 18:18:37 +0800 (CST) Received: from loongson-pc (unknown [192.168.100.1]) by localhost.localdomain (Coremail) with SMTP id AQAAf8AxHs97_9lk0MhZAA--.25514S2; Mon, 14 Aug 2023 18:18:36 +0800 (CST) Date: Mon, 14 Aug 2023 18:18:35 +0800 From: Yujie Yang To: Xi Ruoyao Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH v1 1/6] LoongArch: a symmetric multilib subdir layout Message-ID: <20230814101835.n2pdn6rlbon5dsj3@loongson-pc> References: <20230814035707.11272-1-yangyujie@loongson.cn> <07a023290a898ba3e7a6ae1c36e6e4562bc66aaf.camel@xry111.site> <20230814073712.2eqs3p6s4xrykttm@loongson-pc> <6e631a31aad6b77dfc15a31ec1f1737ca1ec13c9.camel@xry111.site> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6e631a31aad6b77dfc15a31ec1f1737ca1ec13c9.camel@xry111.site> User-Agent: NeoMutt/20180716 X-CM-TRANSID:AQAAf8AxHs97_9lk0MhZAA--.25514S2 Authentication-Results: localhost.localdomain; spf=neutral smtp.mail=y angyujie@loongson.cn; X-CM-SenderInfo: 51dqw5pxmlvqxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBj93XoW7Cw43Zw1rKrWDJr1UGr4Dtrc_yoW8tr48pr WUZa4jyF4kXF1Syrn2yw4rJFyYgrZ3uasxGr1rCrWjg3s8C3s8JFWIg3WY9FnrZr1xJw4a vrZYga4UXF9xZFgCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUkYb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv 67AKxVWxJVW8Jr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxAIw28IcxkI7V AKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCj r7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6x IIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAI w20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x 0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU14lk7UUUUU== X-Gw-Check: ab73d8b6e13f6062 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote: > On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote: > > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > > > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > > > > > > However, for LoongArch, we do not want such a "toplevel" library > > > > installation since the default ABI may change.  We expect all > > > > multilib variants of libraries to be installed to their designated > > > > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so that > > > > the default ABI can be configured arbitrarily (with --with-abi) > > > > while the gcc libdir layout stays consistent.  This could be > > > > helpful for the distribution packaging of GCC libraries. > > > > > > Have you tested a --disable-multilib configuration?  To me with -- > > > disable-configuration everything should be still in the toplevel > > > directory, not any sub-directory. > > > > That's a good point, sorry I missed --disable-multilib here. > > > > However, you don't really need --disable-multilib since > > the libraries are only built once in the default ABI configuration > > as long as --with-multilib-list does not request anything more than > > that. > > > > Maybe we should force-enabling multilib in all cases. > > I really don't like this. Why must I always remind my self "hey, this > is LoongArch, there is a different directory layout" when I don't need > multilib at all? > AFAIK, the two main uses of the multisubdir layout are in the C++ header directory and the GCC libdir (where libgcc.a resides), respectively. The GCC libdir is fine since they are private to a user's GCC build. However, the C++ header directory is shared across the system unless an alternative sysroot is chosen, so the consisentency of the multilib layout matters. So theoretically, the toplevel libraries should have the same ABI under the the target triplet. However, for many architectures, the "--with-abi + MULTILIB_DEFAULT" scheme may cause the toplevel to be configured to have different meanings. So I think it's also a reasonable approach that we just simply eliminate the ambiguous toplevel libraries and use a symmetric layout instead.