Re: On time64 and Large File Support

[Palmer Dabbelt <palmer@dabbelt.com>]

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...