this overhauls part of the build system in order to support multiple
toolchain wrapper scripts, as opposed to solely the musl-gcc wrapper as
before. it thereby replaces --enable-gcc-wrapper with --enable-wrapper=...,
which has the options 'auto' (the default, detect whether to use wrappers),
'all' (build and install all wrappers), 'no' (don't build any) and finally
the options named after the individual compiler scripts (currently only
'gcc' is available) to build and install only that wrapper.
the old --enable-gcc-wrapper is removed from --help, but still available.

it also modifies the wrappers to use the C compiler specified to the build
system as 'inner' compiler, when applicable. as wrapper detection works by
probing this compiler, it may not work with any other.

static-linked PIE files need startup code to relocate themselves, much
like the dynamic linker does. rcrt1.c reuses the code in dlstart.c,
stage 1 of the dynamic linker, which in turn reuses crt_arch.h, to
achieve static PIE with no new code. only relative relocations are
supported.

existing toolchains that don't yet support static PIE directly can be
repurposed by passing "-shared -Wl,-Bstatic -Wl,-Bsymbolic" instead of
"-static -pie" and substituting rcrt1.o in place of crt1.o.

all libraries being linked must be built as PIC/PIE; TEXTRELs are not
supported at this time.

commit de2b67f8 attempted to avoid
having vis.h affect crt files, but the Makefile variable used,
CRT_LIBS, refers to the final output copies in the lib directory, not
the copies in the crt build directory, and thus the -DCRT was not
applied.

while unlikely to be noticed, this regression probably broke
production of PIE executables whose main functions are not in the
executable but rather a shared library.

this is implemented via the build system and does not affect source
files. the idea is to use protected or hidden visibility to prevent
the compiler from pessimizing function calls within a shared (or
position-independent static) libc in the form of overhead setting up
for a call through the PLT. the ld-time symbol binding via the
-Bsymbolic-functions option already optimized out the PLT itself, but
not the code in the caller needed to support a call through the PLT.
on some archs this overhead can be substantial; on others it's
trivial.

this was already essentially possible as a result of the previous
commits changing the dynamic linker/thread pointer bootstrap process.
this commit mainly adds build system infrastructure:

configure no longer attempts to disable stack protector. instead it
simply determines how so the makefile can disable stack protector for
a few translation units used during early startup.

stack protector is also disabled for memcpy and memset since compilers
(incorrectly) generate calls to them on some archs to implement
struct initialization and assignment, and such calls may creep into
early initialization.

no explicit attempt to enable stack protector is made by configure at
this time; any stack protector option supported by the compiler can be
passed to configure in CFLAGS, and if the compiler uses stack
protector by default, this default is respected.

this overhaul further reduces the amount of arch-specific code needed
by the dynamic linker and removes a number of assumptions, including:

- that symbolic function references inside libc are bound at link time
  via the linker option -Bsymbolic-functions.

- that libc functions used by the dynamic linker do not require
  access to data symbols.

- that static/internal function calls and data accesses can be made
  without performing any relocations, or that arch-specific startup
  code handled any such relocations needed.

removing these assumptions paves the way for allowing libc.so itself
to be built with stack protector (among other things), and is achieved
by a three-stage bootstrap process:

1. relative relocations are processed with a flat function.
2. symbolic relocations are processed with no external calls/data.
3. main program and dependency libs are processed with a
   fully-functional libc/ldso.

reduction in arch-specific code is achived through the following:

- crt_arch.h, used for generating crt1.o, now provides the entry point
  for the dynamic linker too.

- asm is no longer responsible for skipping the beginning of argv[]
  when ldso is invoked as a command.

- the functionality previously provided by __reloc_self for heavily
  GOT-dependent RISC archs is now the arch-agnostic stage-1.

- arch-specific relocation type codes are mapped directly as macros
  rather than via an inline translation function/switch statement.

my old, out-of-tree release script that performed a clone rather than
using git archive checked the VERSION file to make sure that it
matched before doing a release. I believe there should be a way to do
the same with git commands (without resorting to checking out the
desired tag) but I have not yet found a way, so care should be taken
when using these targets that the correctness of the VERSION file is
not overlooked.

the main motivation for this change is to aid in debugging. since the
main program's entry point is also named _start, it was difficult to
set breakpoints or quickly identify which _start execution stopped in.

the wildcard function in GNU make includes dangling symlinks; if any
exist under the .git directory, they would get added as dependencies,
causing make to exit with an error due to lacking a rule to build the
missing file.

as far as I can tell, git operations which should force version.h to
be rebuilt must all touch the mtime of the top-level .git directory.

this is still experimental and subject to change. for git checkouts,
an attempt is made to record the exact revision to aid in bug reports
and debugging. no version information is recorded in the static libc.a
or binaries it's linked into.

DESTDIR was wrongly included in the symlink contents.

this was inadvertently removed when switching to the new install.sh.

the historical (non-standardized) install command is really
inappropriate for installing binaries/libraries on a system that
utilizes memory-mapped executable files. rather than replacing an
existing file atomically, it overwrites the existing file. this can
cause running programs to see a partially-modified version of the
file, resulting in unpredictable behavior, or SIGBUS. a MAP_COPY mode
for mmap would get around this problem, but Linux lacks MAP_COPY.

the shell script added with this commit works around the problem by
writing temporary files and moving them into place. unlike the
historical install utility, it also support a -l option for installing
a symbolic link atomically, via the same method.

ln -sf is non-atomic; it unlinks the destination first. instead, make
a temporary link and rename it into place.

this commit also fixes some of the dependency tracking behavior for
the link. depending on the directory it's to be installed in is not
reasonable; it causes a new link to be attempted if the library
directory has been modified, but does not attempt to make a new link
just because libc has been updated. instead, depend on the target to
be linked to. this will ensure that, if prefix has changed but
syslibdir has not, the link will be updated to point to the new
prefix.

instead of subarchs getting their own .s files which are used directly
by the makefile to replace the .c file, they now must provide a .sub
file whose contents are a pathname, relative to the location of the
.sub file, which will substitute for the .c file. essentially these
files are acting as symbolic links, but implemented as text files.

this rule was omitted in previous subarch asm commit

the default subarch is the one whose full name is just the base arch
name, with no suffixes. normally, either the asm in the default
subarch is suitable for all subarch variants, or separate asm is
mandatory for each variant. however, in the case of asm which is
purely for optimization purposes, it's possible to have asm that only
works (or only performs well) on the default subarch, and not any othe
the other variants. thus, I have added a mechanism to give a name to
the default variant, for example "armel" for the default,
little-endian arm. further such default-subarch names can be added in
the future as needed.

the only immediate effect of this commit is enabling PIE support on
some archs that did not previously have any Scrt1.s, since the
existing asm files for crt1 override this C code. so some of the
crt_arch.h files committed are only there for the sake of documenting
what their archs "would do" if they used the new C-based crt1.

the expectation is that new archs should use this new system rather
than using heavy asm for crt1. aside from being easier and less
error-prone, it also ensures that PIE support is available immediately
(since Scrt1.o is generated from the same C source, using -fPIC)
rather than having to be added as an afterthought in the porting
process.

the motivation for this patch is that the vast majority of libc is
code that does not benefit at all from optimizations, but that certain
components like string/memory operations can be major performance
bottlenecks.

at the same time, the old -falign-*=1 options are removed, since they
were only beneficial for avoiding bloat when global -O3 was used, and
in that case, they may have prevented some of the performance gains.

to be the most useful, this patch will need further tuning. in
particular, research is needed to determine which components should be
built with -O3 by default, and it may be desirable to remove the
hard-coded -O3 and instead allow more customization of the
optimization level used for selected modules.

the arch-specific bits/alltypes.h.sh has been replaced with a generic
alltypes.h.in and minimal arch-specific bits/alltypes.h.in.

this commit is intended to have no functional changes except:
- exposing additional symbols that POSIX allows but does not require
- changing the C++ name mangling for some types
- fixing the signedness of blksize_t on powerpc (POSIX requires signed)
- fixing the limit macros for sig_atomic_t on x86_64
- making dev_t an unsigned type (ABI matching goal, and more logical)

in addition, some types that were wrongly defined with long on 32-bit
archs were changed to int, and vice versa; this change is
non-functional except for the possibility of making pointer types
mismatch, and only affects programs that were using them incorrectly,
and only at build-time, not runtime.

the following changes were made in the interest of moving
non-arch-specific types out of the alltypes system and into the
headers they're associated with, and also will tend to improve
application compatibility:
- netdb.h now includes netinet/in.h (for socklen_t and uint32_t)
- netinet/in.h now includes sys/socket.h and inttypes.h
- sys/resource.h now includes sys/time.h (for struct timeval)
- sys/wait.h now includes signal.h (for siginfo_t)
- langinfo.h now includes nl_types.h (for nl_item)

for the types in stdint.h:
- types which are of no interest to other headers were moved out of
  the alltypes system.
- fast types for 8- and 64-bit are hard-coded (at least for now); only
  the 16- and 32-bit ones have reason to vary by arch.

and the following types have been changed for C++ ABI purposes;
- mbstate_t now has a struct tag, __mbstate_t
- FILE's struct tag has been changed to _IO_FILE
- DIR's struct tag has been changed to __dirstream
- locale_t's struct tag has been changed to __locale_struct
- pthread_t is defined as unsigned long in C++ mode only
- fpos_t now has a struct tag, _G_fpos64_t
- fsid_t's struct tag has been changed to __fsid_t
- idtype_t has been made an enum type (also required by POSIX)
- nl_catd has been changed from long to void *
- siginfo_t's struct tag has been removed
- sigset_t's has been given a struct tag, __sigset_t
- stack_t has been given a struct tag, sigaltstack
- suseconds_t has been changed to long on 32-bit archs
- [u]intptr_t have been changed from long to int rank on 32-bit archs
- dev_t has been made unsigned

summary of tests that have been performed against these changes:
- nsz's libc-test (diff -u before and after)
- C++ ABI check symbol dump (diff -u before, after, glibc)
- grepped for __NEED, made sure types needed are still in alltypes
- built gcc 3.4.6

previously, determination of the list of header files for installation
depended on the include/bits symlink (to the arch-specific files)
already having been created. in other words, running "make install"
immediately after configure without first running "make" caused the
bits headers not to be installed.

the solution I have applied is to pull the list of headers directly
from arch/$(ARCH)/bits rather than include/bits, and likewise to
install directly from arch/$(ARCH)/bits rather than via the symlink.

at this point, the only purpose served by keeping the symlink around
is that it enables use of the in-tree headers and libs directly via -I
and -L, which can be useful when testing against a new version of the
library before installing it. on the other hand, removing the bits
symlink would be beneficial if we ever want to support building
multiple archs in the same source tree.

it serves no purpose (binaries linked against musl as -lc/libc.so
automatically get the right DT_NEEDED value of libc.so) and causes
ldconfig to misbehave (making a symlink to ld-musl named libc.so in
/lib). ldconfig is not used on pure musl systems, but if ld-musl is
installed on a system where it's not the primary libc, this will
pollute the system /lib with a symlink to musl named libc.so, which
should NOT exist and could cause problems linking native apps. also,
the existence of the soname caused spurious warnings from ldconfig
when /lib and /usr/lib were the same physical directory.

this is useful when the underlying gcc is already a wrapper, which is
the case at least on some uclibc-based system images. it's also useful
for running an older/newer/nondefault version of gcc.

I originally added -O3 for shared libraries to counteract very bad
behavior by GCC when building PIC code: it insists on reloading the
GOT register in static functions that need it, even if the address of
the function is never leaked from the translation unit and all local
callers of the function have already loaded the GOT register. this
measurably degrades performance in a few key areas like malloc. the
inlining done at -O3 avoids the issue, but that's really not a good
reason for overriding the user's choice of optimization level.

patch by Luca Barbato (lu_zero)

this is mainly a development convenience but will also ensure users
building from latest git always get up-to-date arch-specific dynamic
linker code without having to "make clean".

this allows config.mak to override the default -lgcc for building with
other compilers such as pcc/clang/etc.

these new rules should avoid spurious error messages when the
directory (usually /lib) and the dynamic linker symlink already exist,
and minimize the spam when they can't be created.

hopefully the annoyance of this will be minimal. these files all
define internal interfaces which can change at any time; if different
modules are using different versions of the interfaces, the library
will badly break. ideally we would scan and add the dependency only
for C files that actually reference the affected interfaces, but for
now, err on the side of caution and force a rebuild of everything if
any of them have changed.

this commit is in preparation for the upcoming ssp overhaul commit,
which will change internals of the pthread struct.

the major change here is that CFLAGS is now a variable that can be
changed entirely under user control, without causing essential flags
to be lost. previously, "CFLAGS += ..." was valid in config.mak, but
using "CFLAGS = ..." in config.mak would have badly broken the build
process unless the user took care to copy the necessary flags out of
the main Makefile.

I have also added a distclean target that removes config.mak.

as far as I can tell, it's not useful and never way. I wrote it way
back under the assumption that non-weak symbols in the POSIX or
extension namespace could conflict with legitimate uses of the same
symbol name in the main program or other libraries, but that does not
seem to be the case.

the _concept_ of this wrapper has been tested extensively, but the
integration with the build/install system, and using a persistent
specfile rather than one generated at build-time, have not been
heavily tested and may need minor tweaks.

this approach should be a lot more robust (and easier to improve) than
writing a shell script that's responsible for trying to mimic gcc's
logic about whether it's compiling or linking, building shared libs or
executable files, etc. it's also lighter weight and should result in
mildly faster builds when using the wrapper.