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? > + 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 ? Bruno
