On Fri, 11 Nov 2022 11:01:50 PST (-0800), libc-alpha@xxxxxxxxxxxxxx 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...
