Building _statically linked_ crosscompiler toolchain.

[Brian Dessent]

John Carter wrote:

> ie. In this case statically linking the tool chain _is_ the right solution.

In your opinion.  Not in the opinion of others.

> On the otherhand, if there was a way of deploying...
> 
> $ ldd sparc-elf-gcc
>          linux-gate.so.1 =>  (0xffffe000)
>          libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e86000)
>          /lib/ld-linux.so.2 (0xb7fdb000)
> 
> the relevant .so's _without_ creating gnarly conflicts with the
> distro's resident versions that may be a solution.

Sure.  <http://gcc.gnu.org/ml/gcc-help/2006-07/msg00126.html>.  However,
I don't know what will happen when the compiler driver goes to invoke
the various subprocesses: cc1, cc1plus, collect2, as, ld, ...  You might
have to use such a wrapper for every binary in the toolchain, which
would be incredibly ugly.  At what point does this become more work than
just installing a vmware copy of an old distro?

> Hmm. I seem to remember that didn't work. ie. it compiled and linked
> but the system libraries were still sharable. I think libtool requires
> -all-static if you want the libc statically linked as well, but the
> gcc build barfs if you try that.

That doesn't make any sense.  For one thing, gcc itself doesn't use
libtool at all, it's only used for target libraries.  And since this is
a crosscompiler, target libraries wouldn't have anything to do with the
host libc anyway.  And secondly, LDFLAGS won't even be considered when
building target libraries, only binaries that run on the host; there is
a whole parallel set of variables (*FLAGS_FOR_TARGET IIRC) used for
building target code. 

Brian