From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7577B3858C52 for ; Fri, 11 Nov 2022 11:30:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7577B3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668166230; 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=h0NN0ErVOzkFPjPmJG9VBEifQ9i2TgDtyiQlMT/KbZlsOi2CBo43wGohXEwQhUJjGfeNtF fNGbUMlt30TLALbGj+88hcGR2hO9s4RLVdA0OvKmpPo10AlxCxUJNuRjUsUEzqqTzpv8HI nEGI2f3Fh6ZkSqSi9AesbbhQsr/oQcI= 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) 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 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: * 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