* Rich Felker <dalias@libc.org> [2016-05-03 00:48:36 -0400]:
> I've made a number of improvements and fixes to musl-cross-make which
> are in the upstream repo now, based on bug reports I got:
> 
> - Spurious dependency on flex (upstream's fault, worked around)
> - Spurious dependency on texinfo (ditto)

gcc assumes you want to install info files if BUILD_INFO
is set, which is set based on MAKEINFO, however you cannot
override that, because the configure script will find a
working makeinfo if there is one on the system anyway..

explicit gcc_cv_prog_makeinfo_modern=no solves this in gcc
directories. (the man pages are still installed)

possibly make -o info -o install-info -o install-man
can do this too (havent tested).

> - Ability to use pre-installed gmp/mpc/mpfr libs
> - Config examples for static linking, no-debug builds.

this is not enough:
COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os" LDFLAGS="-s"

target libs still have the full debug path in them,
for that you also need:
COMMON_CONFIG += CFLAGS_FOR_TARGET="-g0 -Os" CXXFLAGS_FOR_TARGET="-g0 -Os" LDFLAGS_FOR_TARGET="-s"

however libgcc seems to be built specially and -g
is always passed there (after CFLAGS_FOR_TARGET),
but one can drop the build path prefix by
COMMON_CONFIG += --with-debug-prefix-map=$(PWD)=

musl is built differently (LDFLAGS is needed because of libgcc):
MUSL_CONFIG += --disable-debug LDFLAGS=-s

i'm not sure if it's a good idea distributing the
toolchain without debug info, but this is needed
if you want to avoid leaking the build path.
the abs build path is still present in all the .la
and .a files and in
lib/gcc/x86_64-linux-musl/5.2.0/install-tools/mkheaders.conf
for me the host lib path managed to get into
lib64/libcc1.so.0.0.0 (via rpath).

> 
> https://github.com/richfelker/musl-cross-make
> 
> A few things I still plan to add at some point:
> 
> - Support for GCC 6, maybe older GCC's too
> - Fixing configure bottlenecks with config.cache
> - Getting "make check" working
> - Automating multi-target builds
> - Automating building binary static-linked-vs-musl toolchains
> 
> Let me know if any major bugs/inconveniences remain that I should
> prioritize fixing.

the target libs are installed under lib64/,
i think the usr/ and lib64/ symlinks are useful
(so it can be used as rootfs without fiddling
with etc/ld-musl*.path).

i think
GCC_CONFIG += --disable-gnu-indirect-function
is important, otherwise libatomic will be broken.

gcc-6 will need
GCC_CONFIG += --disable-libmpx

and libstdc++ only uses vdso clock_gettime
with --enable-libstdcxx-time