* Andreas K. Huettel: >> > >> > Proposal: glibc gains two new build-time configure options: >> > * --enable-hard-time64 >> > * --enable-hard-lfs >> >> We should define new target triplets for this if it's really required. >> > > That doesn't really help anyone *but* Debian ... > >> 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. > 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. Debian does not have a multi-arch ldconfig, either. Their path layout isn't really ideal for that because it lacks a marker directory like glibc-hwcaps that would allow ldconfig to build the cache from file system content without knowledge of the exact architecture list. Maybe I can get justification for upstreaming some form of multi-arch support in the toolchain. But I find it difficult to make this a top priority. (We currently use the upstream path layout in our distributions.) Thanks, Florian
