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.

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

the linker script caused a bogus DT_NEEDED entry

the use of this test will be much stricter than glibc and other
typical implementations; the environment will not be honored
whatsoever unless the program is confirmed non-suid/sgid by the aux
vector the kernel passed in. no fallback to slow syscall-based
checking is used if the kernel fails to provide the information; we
simply assume the worst (suid) in this case and refuse to honor
environment.

leaving it uninitialized caused unpredictable crashes or worse due to
calling an indeterminate function pointer.

some notes:
- library search path is hard coded
- x86_64 code is untested and may not work
- dlopen/dlsym is not yet implemented
- relocations in read-only memory won't work

this seems to be necessary to make the linker accept the functions in
a shared library (perhaps to generate PLT entries?)

strictly speaking libc-internal asm should not need it. i might clean
that up later.

if thread id was reused by the kernel between the time pthread_kill
read it from the userspace pthread_t object and the time of the tgkill
syscall, a signal could be sent to the wrong thread. the tgkill
syscall was supposed to prevent this race (versus the old tkill
syscall) but it can't; it can only help in the case where the tid is
reused in a different process, but not when the tid is reused in the
same process.

the only solution i can see is an extra lock to prevent threads from
exiting while another thread is trying to pthread_kill them. it should
be very very cheap in the non-contended case.

previously a long-running dtor could cause pthread_detach to block.

these are useless and have caused problems for users trying to build
with non-gnu tools like tcc's assembler.

at present the i386 code does not support sse floating point, which is
not part of the standard i386 abi. while it may be desirable to
support it later, doing so will reduce performance and require some
tricks to probe if sse support is present.

this first commit is i386-only, but it should be trivial to port the
asm to x86_64.

even if size_t was 32-bit already, the fact that the value was
unsigned and that gcc is too stupid to figure out it would be positive
as a signed quantity (due to the immediately-prior arithmetic and
conditionals) results in gcc compiling the integer-to-float conversion
as zero extension to 64 bits followed by an "fildll" (64 bit)
instruction rather than a simple "fildl" (32 bit) instruction on x86.
reportedly fildll is very slow on certain p4-class machines; even if
not, the new code is slightly smaller.

looks like busybox is going to want it, and apparently some other
low-level network software does too...