[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On time64 and Large File Support

From: Florian Weimer
Subject: Re: On time64 and Large File Support
Date: Fri, 11 Nov 2022 12:30:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

* 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]