From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14665 invoked by alias); 28 Nov 2007 01:05:49 -0000 Received: (qmail 14589 invoked by uid 22791); 28 Nov 2007 01:05:48 -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:05:35 +0000 Received: (qmail 16434 invoked from network); 28 Nov 2007 01:05:33 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Nov 2007 01:05:33 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.68) (envelope-from ) id 1IxBMq-00052c-Mg; Wed, 28 Nov 2007 01:05:32 +0000 Date: Wed, 28 Nov 2007 08:16:00 -0000 From: "Joseph S. Myers" To: Mark Mitchell cc: Bernd Schmidt , Jie Zhang , gcc@gcc.gnu.org, GCC Patches , Richard Sandiford Subject: Re: Link tests after GCC_NO_EXECUTABLES In-Reply-To: <474CACB5.2040704@codesourcery.com> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/msg01538.txt.bz2 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). It is, after all, the case that you cannot create a proper libstdc++ shared library on a glibc system without linking it against a shared glibc so that it is bound to the right symbol versions in that glibc (static libraries do not generally remain compatible across glibc upgrades where symbols the static libraries use get new versions), and so you must already have a C library you can link against in order for libstdc++ to build, so you may as well use that library at configure time. Some other targets similarly do many link checks in libstdc++-v3/crossconfig.m4. 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. -- Joseph S. Myers joseph@codesourcery.com