From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 6F95B3858D1E for ; Fri, 11 Nov 2022 19:01:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F95B3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org From: "Andreas K. Huettel" To: Florian Weimer Cc: Sam James , libc-alpha@sourceware.org, autoconf@gnu.org, c-std-porting@lists.linux.dev, Zack Weinberg , David Seifert , Gentoo Toolchain , Arsen =?utf-8?B?QXJzZW5vdmnEhw==?= , Paul Eggert , Frederic Berat Subject: Re: On time64 and Large File Support Date: Fri, 11 Nov 2022 20:01:50 +0100 Message-ID: <5874994.lOV4Wx5bFT@pinacolada> Organization: Gentoo Linux In-Reply-To: <87o7tdpw38.fsf@oldenburg.str.redhat.com> References: <9018152.CDJkKcVGEf@pinacolada> <87o7tdpw38.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,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: > >> We need to support legacy binaries on i386. Few libraries are > >> explicitly dual-ABI. Whether it's safe to switch libraries above > >> glibc to LFS or time64 needs to be evaluated on a per-library > >> basis. For most distributions, no one is going to do that work, > >> and we have to stick to whathever we are building today. > > > > ... since for Debian the libraries with different ABI end up in differe= nt > > multiarch paths then. >=20 > I didn't expect co-installability as a requirement. But yes, if that's > the goal, we need non-overlapping paths. Doesn't that requirement come automatically with "we need to support legacy binaries"? How else would that work? > > Anyone with a more, ahem, standard filesystem arrangement has to find > > a different solution for the problem of legacy binaries. >=20 > We can have lib, lib64, libx32, and lib32t quite easily, that's not the > problem. What's missing is ldconfig support. The previous three x86 > architectures have ELF-level selectors; we might need something special > there as well. Yup. I was thinking of lib32n (which won't collide with anything out there), but the selector problem remains. [Apart from all further fun problems with library paths unexpected by unwary upstreams... riscv64 (lib64/lp64d, lib64/lp64, lib32/ilp32d,=20 lib32/ilp32) and mips64 (lib, lib32, lib64) send their regards.] =2D-=20 Andreas K. H=FCttel dilfridge@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice)