We don't want to mix 64 bit file opens with 32 bit file opens;

(This fixes issue #3.)
Space change
For visual consistency, don’t wrap dlsym calls
Supply “lazy initializers” in every intercepted function

The friendly folks at #musl say:

20:52 < dalias> i think it's good to have both that and the ctor
20:52 < Feh> This should increase robustness if it is in every function.
20:52 < dalias> because...
20:52 < dalias> several of these functions are required to be async-signal-safe
20:53 < dalias> so if the first call happened to be from a signal handler,
   you'd be in trouble if you didn't already have the ctor
20:54 < dalias> in theory another ctor in another lib or the app could run
   before yours and install and run a signal handler :-p but that's pretty
   unlikely and pathological
20:54 < dalias> so i think having both the ctor and the lazy-init keeps you
   safe in situations that will arise in the real world
Assert the existence of original functions

The friendly folks at #musl again:

21:17 < dalias> if you init the pointers both from the ctor and the "lazy
   init", then the assertion-failure/abort would happen during construction
   (either your ctor or somebody else's ctor calling your functions)
21:17 < dalias> so the program would exit "before it even gets started"
21:17 < dalias> and this is not so bad

21:18 < dalias> normally i consider it really bad practice for a library to
   abort the program
21:18 < dalias> but this happens during ctors, and there truely is no way to
   proceed
21:18 < dalias> if you've already replaced the program's library functions
   (open, etc.) with your copies, and then find that you can't actually supply
   working ones
Block all signals during store_pageinfo() and free_unclaimed_pages()

The friendly folks at #musl again:

21:34 < dalias> the cheap way around this problem is to block signals for the
   entire duration of the unsafe operation
21:35 < dalias> formally (by the rules of the standard) this is not sufficient
21:35 < dalias> because formally it's not just calling pthread_mutex_lock again
   on the same mutex  while the first call is interrupted that's undefined
21:36 < dalias> it's calling ANY unsafe function while ANY unsafe function (the
   same or otherwise) with any argument (e.g. not necessarily the same mutex)
   that gives undefined behavior
21:38 < dalias> but real-world-implementations don't have this maximum
   theoretical degree of unsafety
21:38 < dalias> so the approach i described (just ensuring your functions don't
   interrupt themselves or each other) should be enough to make them safe