From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 0264E3858422 for ; Tue, 15 Aug 2023 01:30:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0264E3858422 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1692063023; bh=1Q1NtzNtxWuGK4dVOb4HSEW7KWeb+SaYHmKj25uPHm4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=WZoZjobnO4zLKbf99AuCKdiIlXnUD/Rr3Zyjm8i3To7zuDIjJcE30UTaAmIqE9jfX frlYxLZKaPZ70gsSnlEpFXdeP7aES18DXuk9Xw+H03iFqjrMB6M2NYyEkPMmCOjNWD mW3/sFHoSGbttkuiPNvMRDJMZN43kEZLQ7ZbNrtg= Received: from [IPv6:2409:8a0c:2a4:2170:40dc:a500:81f0:2] (unknown [IPv6:2409:8a0c:2a4:2170:40dc:a500:81f0:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 3EDA7659AC; Mon, 14 Aug 2023 21:30:20 -0400 (EDT) Message-ID: <5a4e86c3c0a2eb1e65f70395c621e0dbbc86e1c1.camel@xry111.site> Subject: Re: [PATCH v1 1/6] LoongArch: a symmetric multilib subdir layout From: Xi Ruoyao To: Yujie Yang Cc: gcc-patches@gcc.gnu.org Date: Tue, 15 Aug 2023 09:29:54 +0800 In-Reply-To: References: <20230814035707.11272-1-yangyujie@loongson.cn> <07a023290a898ba3e7a6ae1c36e6e4562bc66aaf.camel@xry111.site> <20230814073712.2eqs3p6s4xrykttm@loongson-pc> <6e631a31aad6b77dfc15a31ec1f1737ca1ec13c9.camel@xry111.site> <20230814101835.n2pdn6rlbon5dsj3@loongson-pc> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 MIME-Version: 1.0 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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, 2023-08-14 at 19:16 +0800, Xi Ruoyao wrote: > On Mon, 2023-08-14 at 18:18 +0800, Yujie Yang wrote: > > 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: > > > > >=20 > > > > > > However, for LoongArch, we do not want such a "toplevel" librar= y > > > > > > installation since the default ABI may change.=C2=A0 We expect = all > > > > > > multilib variants of libraries to be installed to their designa= ted > > > > > > ABI-specific subdirs (e.g. base/lp64d) of the GCC libdir, so th= at > > > > > > the default ABI can be configured arbitrarily (with --with-abi) > > > > > > while the gcc libdir layout stays consistent.=C2=A0 This could = be > > > > > > helpful for the distribution packaging of GCC libraries. > > > > >=20 > > > > > Have you tested a --disable-multilib configuration?=C2=A0 To me w= ith -- > > > > > disable-configuration everything should be still in the toplevel > > > > > directory, not any sub-directory. > > > >=20 > > > > That's a good point, sorry I missed --disable-multilib here. > > > >=20 > > > > 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. > > > >=20 > > > > Maybe we should force-enabling multilib in all cases. > > >=20 > > > I really don't like this.=C2=A0 Why must I always remind my self "hey= , this > > > is LoongArch, there is a different directory layout" when I don't nee= d > > > multilib at all? > > >=20 > >=20 > > AFAIK, the two main uses of the multisubdir layout are in the C++ > > header directory and the GCC libdir (where libgcc.a resides), respectiv= ely. > > 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. >=20 > The C++ header directory should also be considered private to the GCC > build.=C2=A0 AFAIK no distro supports "overwriting a part of the system",= so > you cannot just install a custom GCC build and overwrite the system C++ > header directory.=C2=A0 For a cross compiler, the C++ header directory is > $prefix/$target_triple/include/c++/$gcc_version/$multi_dir, the C++ > header in $sysroot/usr/include/c++ (if it ever exists) will not be used > at all. >=20 > > So theoretically, the toplevel libraries should have the same ABI under > > the the target triplet.=C2=A0 However, for many architectures, the > > "--with-abi + MULTILIB_DEFAULT" scheme may cause the toplevel to be > > configured to have different meanings. >=20 > https://gcc.gnu.org/PR104085=C2=A0is an example of the issue caused by th= e > different meaning. >=20 > > So I think it's also a reasonable approach that we just simply eliminat= e > > the ambiguous toplevel libraries and use a symmetric layout instead. >=20 > I don't like the inconsistency among different GCC ports.=C2=A0 If all po= rts > use the same approach I'll not object. I came up with another idea. What if we: 1. Keep the "default" ABI libs in the toplevel directory. There is *always* a default ABI so treating it specially is not really nonsense. 2. Create a symlink for consistency. For example, if --with-abi=3Dlp64d, - -with-multilib-list=3Dlp64d,lp64s: * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0 contains the lp64d libraries. * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64s contains the lp64s libraries. * /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d is a symlink to "." Then we can refer to the lp64d libgcc.a with both /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d/libgcc.a, and /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/libgcc.a. For referring to the default multilib, the non-suffixed /usr/lib/gcc/loongarch64-linux-gnu/14.0.0 path should be used; for referring lp64d (no matter what the default is), /usr/lib/gcc/loongarch64-linux-gnu/14.0.0/lp64d should be used. The symlink can be created by the GCC building system or manually by the distro maintainer (or gcc packager). Thoughts? --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University