This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Building _statically linked_ crosscompiler toolchain.
- From: John Carter <john dot carter at tait dot co dot nz>
- To: gcc-help at gcc dot gnu dot org
- Date: Fri, 08 Jun 2007 14:04:33 +1200 (NZST)
- Subject: Re: Building _statically linked_ crosscompiler toolchain.
- References: <Pine.LNX.4.64.0706081145370.4424@parore.tait.co.nz><4668A29F.50 9800ED@dessent.net>
On Thu, 7 Jun 2007, Brian Dessent wrote:
John Carter wrote:
The question is "What is The One True Way (or any blooming way) to
build a _completely_ statically linked gcc crosscompiler toolchain?"
I think you'll find that there is never a "One True Way" for anything
when dealing with toolchains.
Sigh! Too Horribly True.
I could be wrong, but if you configure with --disable-shared, that will
apply both to the toolchain as well as the target libraries, which is
certainly not what you want. I.e. you don't want to deprive your target
machine of a shared libstdc++, libgcc, etc. just because of host machine
environment variances.
a. It certainly _is_ what I want... The target system is a tiny
embedded device where everything _must_ be statically linked.
b. No, it doesn't solve the problem of sharing the built toolchain
with my colleagues.
It sounds like attempting to make the entire toolchain static is a bit
of an overcompensation. It's not like gcc and binutils have many
host-library dependencies.
You only need one.
libc.
If it's simply a matter of glibc symbol versioning then the solution is
simply to build on the oldest system you intend to support.
ie. Build the biggest meanest package on the gnu planet on the oldest
slowest, smallest disk, ram system in the company. Sigh!
Even then, looking at the libc version numbers on the latest
greatest... I don't think that will work.
Hmm.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand