Re: On time64 and Large File Support

[Andreas K. Huettel]

> >> 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@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)