From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2948 invoked by alias); 8 Jun 2007 05:28:35 -0000 Received: (qmail 2938 invoked by uid 22791); 8 Jun 2007 05:28:34 -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 05:28:32 +0000 Received: from localhost ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1HwWzJ-0005JJ-R2; Fri, 08 Jun 2007 05:26:17 +0000 Message-ID: <4668E878.BED59C12@dessent.net> Date: Fri, 08 Jun 2007 05: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: <"4668A29F.5 0 9800ED"@dessent.net><46 68CF36.239D1814@dessent.net> 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/msg00095.txt.bz2 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. . 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