in old versions of pcc, the directory containing libpcc.a was not in
the library path, and other options like -print-file-name may have
been needed to locate it. however, -print-file-name itself seems to
have been added around the same time that the directory was added to
the search path, and moreover, I see no evidence that older versions
of pcc are capable of building a working musl shared library. thus, it
seems reasonable to just test whether -lpcc is accepted.

pcc wrongly passes any option beginning with -m to the linker, and
will break at link time if these options were added to CFLAGS. testing
linking lets us catch this at configure time and skip them.

this is necessary to allow $CC with arguments in it

for some reason this option is undocumented. not sure when it was
added, so I'm using a configure test. gcc was already setting the mark
correctly for C files, but assembler source files would need ugly
.note boilerplate in every single file to achieve this without the
option to the assembler.

blame whoever thought it would be a good idea to make the stack
executable by default rather than doing it the other way around...

based on initial work by rdp, with heavy modifications. some features
including threads are untested because qemu app-level emulation seems
to be broken and I do not have a proper system image for testing.

this should both fix the issue with ARM needing -lgcc_eh (although
that's really a bug in the libgcc build process that's causing
considerable bloat, which should be fixed) and make it easier to build
musl using clang/llvm in place of gcc. unfortunately I don't know a
good way to detect and support pcc's -lpcc since it's not in pcc's
default library search path...

if needed for debugging, it will be output in the .debug_frame section
instead, where it is not part of the loaded program and where the
strip command is free to strip it.

based on the patches contributed by boris brezillon.

basically, this version of the code was obtained by starting with
rdp's work from his ellcc source tree, adapting it to musl's build
system and coding style, auditing the bits headers for discrepencies
with kernel definitions or glibc/LSB ABI or large file issues, fixing
up incompatibility with the old binutils from aboriginal linux, and
adding some new special cases to deal with the oddities of sigaction
and pipe syscall interfaces on mips.

at present, minimal test programs work, but some interfaces are broken
or missing. threaded programs probably will not link.

this option is expensive and only used on old gcc's that lack
-fexcess-precision=standed, but it's not needed on non-i386 archs
where floating point does not have excess precision anyway.

if musl ever supports m68k, i think it will need to be special-cased
too. i'm not aware of any other archs with excess precision.

this issue affects the last gpl2 version of binutils, which some
people are still using out of aversion to gpl3. musl requires
-Bsymbolic-functions because it's the only way to make a libc.so
that's able to operate prior to dynamic linking but that still behaves
correctly with respect to global vars that may be moved to the main
program via copy relocations.

it's possible that the user has provided a compiler that does not have
any libc to link to, so linking a main program is a bad idea. instead,
generate an empty shared library with no dependencies.

in theory we could support stack protector in the libc itself, and
users wanting to experiment with such usage could add
-fstack-protector to CFLAGS intentionally. but to avoid breakage in
the default case, override broken distro-patched gcc that forces stack
protector on.

some broken distro-provided toolchains have modified gcc to produce
only "gnu hash" dynamic hash table by default. as this is unsupported
by musl, that results in a non-working libc.so. we detect and switch
this on in configure rather than hard-coding it in the Makefile
because it's not supported by old binutils versions, but that might
not even be relevant since old binutils versions already fail from
-Bsymbolic-functions being missing. at some point I may review whether
this should just go in the Makefile...

this script is not based on autoconf; however it attempts to follow
the same interface contracts for ease of integration with build
systems. it is also not necessary to use musl. manually written
config.mak files are still supported, as is building without any
config.mak at all as long as you are happy with the default options
and you supply at least ARCH on the command line to make.