Re: [PATCH 2/3] selinux: load libselinux with dlopen instead of linking

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?