From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 55E982582 for ; Fri, 11 Nov 2022 11:30:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668166227; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xlJsicngBwHMd3Ln/3bRhwgEeatLIA/ipsAbbsCrTMg=; b=HB1okl1TQpHnLOnNyhuR9K8nVeMZvEr0ZYr38sKbUhdpwLQA9J7VmwYxE1xWZoelGPlCcu JlzCsGHYpWN4/rCPYkUQFhs/LmdgTAdKkXl5tNxYg17y08ED27f9PGt2ZVth6kEpDO5pHJ r8coiwjgG4g+TCAoM0ktPY55ckl5v1c= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-442-1L93VpRGPgykz70A3y8amA-1; Fri, 11 Nov 2022 06:30:24 -0500 X-MC-Unique: 1L93VpRGPgykz70A3y8amA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4974F3C11EA3; Fri, 11 Nov 2022 11:30:23 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E81A740E9783; Fri, 11 Nov 2022 11:30:20 +0000 (UTC) From: Florian Weimer To: "Andreas K. Huettel" 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?Q?Arsenovi=C4=87?= , Paul Eggert , Frederic Berat Subject: Re: On time64 and Large File Support References: <87wn81q254.fsf@oldenburg.str.redhat.com> <9018152.CDJkKcVGEf@pinacolada> Date: Fri, 11 Nov 2022 12:30:19 +0100 In-Reply-To: <9018152.CDJkKcVGEf@pinacolada> (Andreas K. Huettel's message of "Fri, 11 Nov 2022 10:40:35 +0100") Message-ID: <87o7tdpw38.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Precedence: bulk X-Mailing-List: c-std-porting@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain * Andreas K. Huettel: >> > >> > Proposal: glibc gains two new build-time configure options: >> > * --enable-hard-time64 >> > * --enable-hard-lfs >> >> We should define new target triplets for this if it's really required. >> > > That doesn't really help anyone *but* Debian ... > >> 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 different > multiarch paths then. I didn't expect co-installability as a requirement. But yes, if that's the goal, we need non-overlapping paths. > Anyone with a more, ahem, standard filesystem arrangement has to find > a different solution for the problem of legacy binaries. 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. Debian does not have a multi-arch ldconfig, either. Their path layout isn't really ideal for that because it lacks a marker directory like glibc-hwcaps that would allow ldconfig to build the cache from file system content without knowledge of the exact architecture list. Maybe I can get justification for upstreaming some form of multi-arch support in the toolchain. But I find it difficult to make this a top priority. (We currently use the upstream path layout in our distributions.) Thanks, Florian