hopefully this resolves the rest of the issues with hideously
nonportable hacks in programs that use gnulib.

this is a really ugly and backwards function, but its presence will
prevent lots of broken gnulib software from trying to define its own
version of fpurge and thereby failing to build or worse.

these interfaces are required to be thread-safe even though they are
not state-free. the random number sequence is shared across all
threads.

per POSIX: The mprotect() function shall change the access protections
to be that specified by prot for those whole pages containing any part
of the address space of the process starting at address addr and
continuing for len bytes.

on the other hand, linux mprotect fails with EINVAL if the base
address and/or length is not page-aligned, so we have to align them
before making the syscall.

this is mostly useless for shared libs (though it could help for
prelink-like purposes); the intended use case is for adding support
for calling the dynamic linker directly to run a program, as in:
./libc.so ./a.out foo

this usage is not yet supported.

prior to this change, copy relocations for initialized pointer
variables would not reflect the relocated contents of the pointer.

some cruft was left and DESTDIR was not being used correctly.

the path for the dynamic linker is now configurable, and failure to
install the symlink for it will not stop the build.

deps can be null if a library has no dependencies (such as libc itself)

basically we temporarily make the library and all its dependencies
part of the global namespace but only for the duration of performing
relocations, then return them to their former state.

some of the code is not yet used, and is in preparation for dlopen
which needs to be able to handle failure loading libraries without
terminating the program.

1. search was wrongly beginning with lib itself rather than dso head
2. inconsistent resolution of function pointers for functions in plt

previously, a potentially-indeterminate value from we_offs was being
used, resulting in wrong we_wordc and subsequent crashes in the
caller.

why did gcc allow this invalid assignment to compile in the first place?

first, use $LD_LIBRARY_PATH unless suid. if that fails, read path from
/etc/ld-musl-$ARCH.path and fallback to a builtin default.