John Carter wrote: > People keep saying that....but never saying in what way doesn't it work or why. http://people.redhat.com/drepper/no_static_linking.html > a. It certainly _is_ what I want... The target system is a tiny > embedded device where everything _must_ be statically linked. It's hard to guess what you want when you didn't state it in your original message. > b. No, it doesn't solve the problem of sharing the built toolchain > with my colleagues. Right, because --disable-shared does not mean statically link against libc, it means don't build shared libraries. > You only need one. > > libc. If you mean that differing libc versions can be a problem when distributing binaries, then sure. If you mean that gcc only needs libc, then you're not using a recent version as gmp and mpfr have been host library requirements since 4.0 for gfortran and since 4.2 (or 4.1?) for the entire compiler. > ie. Build the biggest meanest package on the gnu planet on the oldest > slowest, smallest disk, ram system in the company. Sigh! You can do it with a chroot on a fast machine. You can do it with Xen/Vmware/etc on a fast machine. It's usually an infrequent event that you need to rebuild the toolchain itself. Besides, it has nothing to do with it being gcc or being a large package, this is the general method to achieve binary compatibility for any package on a wide range of systems. > Even then, looking at the libc version numbers on the latest > greatest... I don't think that will work. That's not true. Glibc symbol versioning goes to farily great lengths to assure backwards binary compatibility, so don't write it off. But this means only that binaries compiled against an older version of the library work correctly with a newer version, and never the reverse. If really want to statically link the toolchain, you can start with: path/to/configure --foo=bar ... LDFLAGS="-static" I just tried this on gcc trunk with a C-only non-bootstrap native and it worked fine, but you might have to make further adjustments. Although even after stripping cc1 is nearly 9MB so I can't imagine that this is very efficient memory-wise or performance-wise. Brian
