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
