From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 4BDB63858D38 for ; Fri, 11 Nov 2022 19:28:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4BDB63858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pg1-x533.google.com with SMTP id h193so5101538pgc.10 for ; Fri, 11 Nov 2022 11:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=wLErv9vqjX+unFv37Nn+eM2Ivsr+fdNHgG3wMqStdE8=; b=t0kglGt1YbABKKthaZ3FqzgfMtOfoaw+KxpW2mO50dIGweGgRIN9WO7iMuO78A/TYn HK7sbyr5GH6W8fdYcROmVnGkSfRyOdMYsPnttBXizJu67G3Qke5Wqjho0aPh9fKb0YOW sWhWNZ3fMI01Jf3zo5XUhAixuOSIqCvlFffJfOlOjZoRrPWwSIRiB+5AimJ4kDHoXt2X c6zQNhok4KpF6AkryCF+m8eRjT0KcBV74Gb7kJv/jJS+e+Pv1VOwPz3zHXULHGIe3b4E n6tWAdjs72IFGC/ZUbORBLpKQmHQLkM6/ZzZ2r8UcV2Oa3OX9gHd1wwk41DGBe1fT5CZ b9yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wLErv9vqjX+unFv37Nn+eM2Ivsr+fdNHgG3wMqStdE8=; b=GxN82Xi+25G6hJudqqYxtFxRPU4VuXO0IJZNPycP0s88Sv5SGJwfmXi4mH4oxZx4eI kKwH7U4TV4SbKGRURIw+VWbjpLgXsgqU0x6KdYlT91IEZKppLtLPn6DLJ4qYzk1BPwaV Zs0ntP1jIMnVKF+M3iij5kJujeT3zbFyTet3AxALeaY3pWG8Ij6jXQfbdMRXL2N9XRoo lyfji3q8y6WyiUhG5HkR0MYH55sWNZ0lVEZtkPQhhFejcJm2GvsAIzUcbpCWmmjB5LLM 3gpDJga8QLpusXpR2EBQLYHNfByqLZVNYxGwc57ZB70aEVT37WtJfHPz51Gst8cWUCMo 4uRA== X-Gm-Message-State: ANoB5pnL29rbEwbYiIu9qsNX1dK+OYtNJTLY+7LsaklddhI9DiUfdUxa PUmJ1QhIPEzS/T+AT6PJA1ymGA== X-Google-Smtp-Source: AA0mqf7eHbGaM1XTgvS16F0MJg+O1IKbEGyLcaNUlKakklR9oJokAIYBP7evPWxpkBvLhmCZQL/sCA== X-Received: by 2002:a63:5d50:0:b0:460:ec46:3645 with SMTP id o16-20020a635d50000000b00460ec463645mr3010297pgm.92.1668194906187; Fri, 11 Nov 2022 11:28:26 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id 124-20020a620582000000b00565cbad9616sm1945026pff.6.2022.11.11.11.28.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 11:28:25 -0800 (PST) Date: Fri, 11 Nov 2022 11:28:25 -0800 (PST) X-Google-Original-Date: Fri, 11 Nov 2022 11:28:22 PST (-0800) Subject: Re: On time64 and Large File Support In-Reply-To: <5874994.lOV4Wx5bFT@pinacolada> CC: fweimer@redhat.com, sam@gentoo.org, libc-alpha@sourceware.org, autoconf@gnu.org, c-std-porting@lists.linux.dev, zack@owlfolio.org, soap@gentoo.org, toolchain@gentoo.org, arsen@aarsen.me, eggert@cs.ucla.edu, fberat@redhat.com From: Palmer Dabbelt To: libc-alpha@sourceware.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,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 Fri, 11 Nov 2022 11:01:50 PST (-0800), libc-alpha@sourceware.org wrote: >> >> 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. > > 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. >> >> 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, > lib32/ilp32) and mips64 (lib, lib32, lib64) send their regards.] I don't want to derail the thread, but sorry again for the RISC-V bits there. IMO we can fix it without an ABI break via adding some new paths, I just don't know what they should be. Happy to hear if anyone has suggestions...