Hello,
In Debian and Ubuntu, we are working to move future releases of the OS on
32-bit architectures (predominantly: armhf AKA arm-linux-gnueabihf) to use
64-bit time_t natively in anticipation of the y2038 event horizon.
While for most libraries we are taking the approach to rebuild in-place with
changed compiler flags and declaring incompatibility with previous package
builds via the package manager, libselinux is a sufficiently core part of
the OS (as a dependency of the package manager itself) that this is not
tenable.
Therefore I propose the following patch to libselinux to make it dual-ABI
for the single LFS-sensitive entry point, congruent to the way glibc itself
handles such changes.
The particular implementation doesn't use as many asm extension / symbol
version map tricks as glibc to make "nice" symbol names in the resulting
binary, it just gives us matchpathcon_filespec_add() and
matchpathcon_filespec_add64() as entrypoints. If there is a preference for
more glibc-style handling with symbol versions I am happy to rework to
accomodate.
As this problem has been discovered rather late in our transition process, I
have a bit of a time crunch on my side which is not your problem, but I
would ask that whether or not the patch is ready to land, we reach a
consensus ASAP on:
- whether it is acceptable to introduce a new entry point for this on
32-bit architectures
- the name this new entry point should use (including symbol version)
- that it is acceptable to upstream that we proceed on implementing this
at the distro level in advance of the patch landing upstream.
Thanks!
