> >> 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.] -- Andreas K. Hüttel dilfridge@xxxxxxxxxx Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice)
