Building _statically linked_ crosscompiler toolchain.

[Brian Dessent]

John Carter wrote:

> The question is "What is The One True Way (or any blooming way) to
> build a _completely_ statically linked gcc crosscompiler toolchain?"

I think you'll find that there is never a "One True Way" for anything
when dealing with toolchains.

I could be wrong, but if you configure with --disable-shared, that will
apply both to the toolchain as well as the target libraries, which is
certainly not what you want.  I.e. you don't want to deprive your target
machine of a shared libstdc++, libgcc, etc. just because of host machine
environment variances.

It sounds like attempting to make the entire toolchain static is a bit
of an overcompensation.  It's not like gcc and binutils have many
host-library dependencies.  Can't you just identify whatever it is that
is causing the problem and build that library static?  For example, if
you drop the gmp/mpfr sources into the gcc tree it will be built and
linked statically with gcc, rather than using the system copy which is
probably shared and which probably doesn't exist on most systems by
default.  And you can --disable-nls to remove any dependencies on
libiconv et al., although on linux systems that stuff should all be
handled by glibc rather than discrete libs.

If it's simply a matter of glibc symbol versioning then the solution is
simply to build on the oldest system you intend to support.

Brian