On Thu, 7 Jun 2007, Brian Dessent wrote:
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
Ah! Thanks. Interesting....
Hmm, although.... not single one of his arguments is applicable to the
problem of distributing a cross compiler to a team of coworkers using
different versions of different distributions of Linux.
ie. In this case statically linking the tool chain _is_ the right solution.
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.
Could I ship my versions of the .so's into a sub-directory of the gcc
package and use LD_PRELOAD or something to load those in preference to
the system ones?
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.
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.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@xxxxxxxxxx
New Zealand
