note that dlerror is specified to be non-thread-safe, so no locking is
performed on the error flag or message aside from the rwlock already
held by dlopen or dlsym. if 2 invocations of dlsym are generating
errors at the same time, they could clobber each other's results, but
the resulting string, albeit corrupt, will still be null-terminated.
any use of dlerror in such a situation could not be expected to give
meaningful results anyway.

the error status is required to be sticky after failure of dlopen or
dlsym until cleared by dlerror. applications and especially libraries
should never rely on this since it is not thread-safe and subject to
race conditions, but glib does anyway.

i'm not sure that it's "correct" for dlopen to block cancellation
when calling constructors for libraries it loads, but it sure seems
like the right thing. in any case, dlopen itself needs cancellation
blocked.

this is mainly in hopes of supporting c++ (not yet possible for other
reasons) but will also help applications/libraries which use (and more
often, abuse) the gcc __attribute__((__constructor__)) feature in "C"
code.

x86_64 and arm versions of the new startup asm are untested and may
have minor problems.

these don't work (or do anything at all) but at least make it possible
to static link programs that insist on "having" dynamic loading
support...as long as they don't actually need to use it.

adding real support for dlopen/dlsym with static linking is going to
be significantly more difficult...

this issue affected programs which use global variables exported by
non-libc libraries.

even with this change, PIE will not work yet due to deficiencies in
the crt1.o startup code.

this fixes an issue using gold instead of gnu ld for linking. it also
should eliminate the need of the startup code to even load/pass the
got address to the dynamic linker.

based on patch submitted by sh4rm4 with minor cosmetic changes.

further cleanup will follow.

this only affects non-ascii symbol names, which are probably not in
use anyway..

it does not work, but some configure scripts will falsely detect
support then generate programs that crash when they call dlopen.

this does not change behavior, but the idea is to avoid letting other
code build up between these two points, whereby the environment
variables might get used before security it checked.

the asm wrapper is needed to get the return address without
compiler-specific extensions.

instead of creating temp dso objects on the stack and moving them to
the heap if dlopen/dlsym are used, use static objects to begin with,
and just donate them to malloc if we no longer need them.

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.

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

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

eventually (once dlopen exists) this behavior will be conditional on
dlopen/dlsym not being reachable.