From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28341 invoked by alias); 5 Dec 2007 17:22:43 -0000 Received: (qmail 28315 invoked by uid 22791); 5 Dec 2007 17:22:41 -0000 X-Spam-Check-By: sourceware.org Received: from pfepc.post.tele.dk (HELO pfepc.post.tele.dk) (195.41.46.237) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Dec 2007 17:22:33 +0000 Received: from x1-6-00-0f-9f-c6-3e-90 (unknown [80.197.1.215]) by pfepc.post.tele.dk (Postfix) with ESMTP id 8DD558A0051; Wed, 5 Dec 2007 18:22:27 +0100 (CET) Received: from x1-6-00-0f-9f-c6-3e-90 (localhost.localdomain [127.0.0.1]) by x1-6-00-0f-9f-c6-3e-90 (8.14.0/8.14.0) with ESMTP id lB5HMQxN001329; Wed, 5 Dec 2007 18:22:27 +0100 Received: (from rask@localhost) by x1-6-00-0f-9f-c6-3e-90 (8.14.0/8.14.0/Submit) id lB5HMOLJ001328; Wed, 5 Dec 2007 18:22:24 +0100 Date: Wed, 05 Dec 2007 17:22:00 -0000 From: Rask Ingemann Lambertsen To: Mark Mitchell Cc: GCC Patches , rsandifo@nildram.co.uk Subject: Re: Link tests after GCC_NO_EXECUTABLES Message-ID: <20071205172224.GM17368@sygehus.dk> References: <474DF7E4.6050308@codesourcery.com> <20071130181424.GO17368@sygehus.dk> <4750559E.2090800@codesourcery.com> <20071130211005.GQ17368@sygehus.dk> <87d4tqu4nv.fsf@firetop.home> <20071201115252.GS17368@sygehus.dk> <20071201120251.GT17368@sygehus.dk> <20071201223447.GU17368@sygehus.dk> <47531F54.6010802@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47531F54.6010802@codesourcery.com> User-Agent: Mutt/1.5.14 (2007-02-12) 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-12/txt/msg00199.txt.bz2 On Sun, Dec 02, 2007 at 01:10:44PM -0800, Mark Mitchell wrote: > > My only concern with this approach is that Newlib might not be entirely > consistent across configurations and architectures. The libstdc++ > approach presumably entails some manual verification of each function's > presence or absence; before we claim that "Newlib has foo" someone > verifies that. I don't know if this is a problem in practice. > > For example, these lines seem like things that might vary. > > > +have_fpsetmask=${have_fpsetmask=no} > ... > > +have_sync_fetch_and_add=${have_sync_fetch_and_add=no} > > I suppose we could solve that problem, if it arises, with different > config.cache files for different targets. Perhaps it would be best to > generalize this by adding a top-level --with-target-lib-cache= option, > and then, if that's not present, and $with_newlib is set, passing in the > Newlib cache that you have? > > That would give people a way to say that for their particular RTOS > and/or C library the following functions are available. > > In theory, at least, we might also have differences between multilibs. > It Would Be Nice to be moving GCC in the direction of allowing different > multilibs for different operating systems and/or C libraries. So, I > suppose the all-singing, all-dancing version of this would be some > option that allows you to specify a cache file per multilib. But, I > think that could be left for later. I think it wouldn't be all that difficult. The top-level configure could try to append the target name to the default config.cache and use that as the default for the --with-target-lib-cache= option. The multilibs are handled by config-ml.in which could try to append the multilib name and see if that file exists, and if not, just use what was passed down from the top level. Less than twenty lines of code on a good day. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year