From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6524 invoked by alias); 8 Jun 2007 00:28:22 -0000 Received: (qmail 6514 invoked by uid 22791); 8 Jun 2007 00:28:21 -0000 X-Spam-Check-By: sourceware.org Received: from dessent.net (HELO dessent.net) (69.60.119.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 08 Jun 2007 00:28:19 +0000 Received: from localhost ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1HwSKu-00049z-69; Fri, 08 Jun 2007 00:28:16 +0000 Message-ID: <4668A29F.509800ED@dessent.net> Date: Fri, 08 Jun 2007 00:28:00 -0000 From: Brian Dessent Reply-To: gcc-help@gcc.gnu.org X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: John Carter CC: gcc-help@gcc.gnu.org Subject: Re: Building _statically linked_ crosscompiler toolchain. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-06/txt/msg00089.txt.bz2 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. 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. 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. Can't you just identify whatever it is that is causing the problem and build that library static? For example, if you drop the gmp/mpfr sources into the gcc tree it will be built and linked statically with gcc, rather than using the system copy which is probably shared and which probably doesn't exist on most systems by default. And you can --disable-nls to remove any dependencies on libiconv et al., although on linux systems that stuff should all be handled by glibc rather than discrete libs. 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. Brian