On 18/07/2026 12:52, Bruno Haible via Gnulib discussion list wrote:
Hi Luca,
libselinux is built in most distros, but it is seldomly needed at
runtime (e.g.: it is not used by default on Debian/Ubuntu). In order to
allow building small images from the same packages
libselinux.so is less than 200 KB large. Is it really worth the effort?
What is the size of "small images" that you are targeting, in MB?
Well it has a pcre2 transitive dependency.
Also there are selinux fs identification overheads at startup,
especially on systems that don't have that, as it scans /proc/mounts
looking for it.
Then there are overheads in utilities themselves,
that could be auto avoided if libselinux was not available.
I am leaning towards libselinux being dlopened for coreutils at least,
as most tools are functional with default options without it.
+ AS_CASE([$host_os],
+ [*android*], [LIBSELINUX_SONAME=libandroid-selinux.so],
The handling of Android here is correct. Yes, libandroid-selinux.so
does not have a major version suffix (unlike shared libraries created
through libtool).
+ [*], [LIBSELINUX_SONAME=libselinux.so.1])
The major version number of this library has been 1 at least since 2011.
But it is always possible that it gets superseded by a libselinux.so.2
some day. How would we know about it?
The situation I would like to avoid is that the developers of libselinux
switch to a new major version, we don't know about it, and as a consequence
coreutils, findutils, and sed don't operate correctly (in subtle ways)
for a long time — until maybe a year later somebody reports it.
I don't think always using the newest version (e.g. through
`readlink libselinux.so`) would work: A major version bump indicates
backward compatibility problems; so, a developer *must* look into it.
The only solution I can think of is a piece of configure script that
- looks up libselinux.so,
- runs `readlink /path/to/libselinux.so`
- extracts the major version from that,
- aborts the configuration through AC_MSG_ERROR if it is not 1.
(The use of AC_MSG_ERROR is OK here, since the user can bypass it by
not using the --enable-selinux option.)
Can you add something along these lines to m4/selinux-selinux-h.m4 ?
For reference, handling of soname version was done in coreutils with:
https://github.com/coreutils/coreutils/commit/3bbdb3938
https://github.com/coreutils/coreutils/commit/afc41505e
cheers,
Padraig
