From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10216 invoked by alias); 30 Nov 2007 18:25:48 -0000 Received: (qmail 10200 invoked by uid 22791); 30 Nov 2007 18:25:47 -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; Fri, 30 Nov 2007 18:25:41 +0000 Received: (qmail 10800 invoked from network); 30 Nov 2007 18:25:39 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Nov 2007 18:25:39 -0000 Message-ID: <4750559E.2090800@codesourcery.com> Date: Fri, 30 Nov 2007 21:08:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Rask Ingemann Lambertsen CC: Bernd Schmidt , Jie Zhang , gcc@gcc.gnu.org, GCC Patches , rsandifo@nildram.co.uk Subject: Re: Link tests after GCC_NO_EXECUTABLES References: <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> <87fxyqdc45.fsf@firetop.home> <474D943C.4030106@codesourcery.com> <20071128210420.GH17368@sygehus.dk> <474DF7E4.6050308@codesourcery.com> <20071130181424.GO17368@sygehus.dk> In-Reply-To: <20071130181424.GO17368@sygehus.dk> 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/msg01720.txt.bz2 Rask Ingemann Lambertsen wrote: >> The issue isn't just Newlib; it's the "BSP" (crt0, system-call >> implementations, etc.) that you might have in your individual system. >> Some BSPs add considerable functionality beyond that provided by Newlib >> itself, and we don't want libstdc++ to detect and rely on that. > > Ok, I got that. I suppose that means you don't actually have a way of > making libstdc++ use such extra functionality? Correct. > You wouldn't be using those libraries -- I wouldn't even expect people to > actually wait for the libraries to build -- just check that 'configure > --without-link-tests' runs to completion with no errors, then press ^C. Oh, I understand now; that makes sense to me. >>> I have a feeling it would be more robust to simulate the link tests >>> inside the autoconf/libtool macros themselves as opposed to explicitly >>> avoiding them in each and every configure.{ac,in}. Supply an option >>> --simulate-link-tests=file_with_results with the default being no and be >>> happy. >> We would still need to hard-code things. > > Yes. The difference being it wouldn't break the first time someone edits > configure.ac. --simulate-link-tests=file would be similar to > --cache-file=file, but anything not specified in 'file' would default to > 'no' instead of being probed for. We would ship a file with the hard-coded > answers. It would need no hacks, tricks or work-arounds in configure.ac, and > it would deal with all the libraries, present, past and future, in one fell > swoop. That sounds plausible too. For libstdc++, there's a fair amount of target-specificity, so you'd presumably end up with multiple cache files for various targets, but that sounds like it would work. The tradeoff is that you might end up adding checks for functions that are in fact available in Newlib, but, because nobody added them to the cache file, wouldn't be used. The advantage to the current setup is that you get a loud failure, and have to go actually work out the right answer. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713