From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2325 invoked by alias); 28 Nov 2007 01:15:49 -0000 Received: (qmail 2314 invoked by uid 22791); 28 Nov 2007 01:15:49 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Nov 2007 01:15:43 +0000 Received: (qmail 17107 invoked from network); 28 Nov 2007 01:15:41 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Nov 2007 01:15:41 -0000 Message-ID: <474CC128.1050005@codesourcery.com> Date: Wed, 28 Nov 2007 10:01:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Joseph S. Myers" CC: Bernd Schmidt , Jie Zhang , gcc@gcc.gnu.org, GCC Patches , Richard Sandiford Subject: Re: Link tests after GCC_NO_EXECUTABLES References: <46EFBCC1.6070200@gmail.com> <46EFC383.7020503@t-online.de> <46EFC9E9.7090201@gmail.com> <46EFCEF9.3060304@t-online.de> <46EFCF7A.2080704@gmail.com> <46EFD236.6080907@t-online.de> <46EFDA4D.3070006@gmail.com> <474C0C52.8050503@t-online.de> <474C8FA4.2040603@codesourcery.com> <474C95BA.1060807@t-online.de> <474C96C1.7010208@codesourcery.com> <474C98AA.50105@t-online.de> <474C9A65.2060902@codesourcery.com> <474C9B33.8060503@t-online.de> <474C9CBD.2070708@codesourcery.com> <474C9E12.6050903@t-online.de> <474CACB5.2040704@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg01542.txt.bz2 Joseph S. Myers wrote: > On Tue, 27 Nov 2007, Mark Mitchell wrote: > >> In any case, I think this is something that ought to be decided as a >> global policy for GCC and its run-time libraries, not something that >> differs between ports. In particular, if run-time libraries are allowed >> to depend on linking in their configure tests, that's something everyone >> should know. > > For GNU/Linux, we decided some time ago that libstdc++ configuration would > require link tests in order to identify the precise functions available in > that particular multilib's libc version and configuration (depending, for > example, on how uClibc is configured). Yes, that makes sense to me. Bare metal systems are of course somewhat different. What do you think about that? > If only static libraries are being built, it may be possible to build them > without linking, and in such cases it may be possible to define a generic > set of libc symbols considered to be present, as libstdc++-v3/configure.ac > does with newlib. Do you understand how MIPS/Power works? I'd really like to know what the difference is. It might be an easy difference to resolve, or there might be something more fundamental, but before we do anything I'd like to know why one works and the other doesn't. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713