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
