Can p11-kit be used in a hermetic build?

[bcsgh]

I found this which implies but doesn't prove the answer is no. I'm hoping that's not the case or that there is another API comparable library I can use in it's place.

For context, I am trying to use p11-kit in a context where I must not make any assumptions about the environment that are not guaranteed by the fact the OS got to the point of attempting to start my binary. There is a begrudging allowance for the dynamic library that contains the OS sys-calls, but that's only because there is no way to even get to trying to run my binary if that's not usable and sys-calls have to interact with the current OS version so it can't be statically linked anyway.

Nether of these applies to something like p11-kit; using a dynamic library could result in load failures if the binary file is copied onto a system without that library or could result in it running on a version other than the one build as part of the hermetic build if another version is present. I need to eliminate both these possibilities.

If it makes any difference in my case, I'd be willing to manually call an officially supported public init API to make things work.

---

Side note: I'm guessing that the current state is a result of module registration and the requirement for external libraries to call into a registration function simply by being linked in as well as some ordering constraints between them and p11-kit's internal initialization. As it happens, at least in C++11 (thought presumably the details would would different for C), I personally know this is 100% possible to do in a static library because I've implemented it myself. It ends up looking something like this:

struct Registrar { ... };

Registrar* get_registrar() {
  static Registrar* ret = construct_init_registrar();  // See C++11 standard 6.7.4 re concurrent execution
  return ret;
}

template<void (*fn)(Registrar*)>
class Register {
 public:
  Register() { fn(get_registrar()); }
};

// in module:
namespace { Register<my_init> init; } 

The only remaining trick then is to get the linker to not throw away the module, but I have reason to believe this is a problem with know but finiky solutions.