For this one, two general issues:
* This implementation doesn't appear to be thread-safe.
* There are several ways to use dlopen:
1. Have an initialization procedure, when the application discovers it
needs selinux, it uses that procedure to resolve all the library
symbols. The application arranges to call the initialization procedure
before it uses any selinux feature. This tends to avoid threading
issues, as the initialization procedure can be invoked in the main
thread early on.
2. Each selinux function itself invokes the initialization procedure, so
that the app need not know about initialization.
3. Even more lazily: each selinux function arranges for itself to be
available (via dlsym), but not the other functions.
The patch uses (2), but what if an app developer prefers (1) or (3)? (3)
might be better, for example, for apps that need some but not all
selinux functions, especially if selinux evolves.
What if the app has libselinux linked in for other reasons, before
'main' even starts? Would that collide with the draft patch? That is,
does the draft patch insist that Gnulib be the only way to use
libselinux functionality?
Some more-particular issues:
The patch to m4/selinux-selinux-h.m4 causes an Android build to insist
on libandroid-selinux.so rather than merely preferring it; is that intended?
No need to include <stdbool.h>; the bool module arranges for C23-style
bool, which doesn't include that file.
Why depend on stddef-h?
Why include <sys/stat.h> and depend on sys_stat-h?
