Re: Building _statically linked_ crosscompiler toolchain.

[Brian Dessent <brian@dessent.net>]

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