From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11723 invoked by alias); 28 Nov 2007 21:04:51 -0000 Received: (qmail 11636 invoked by uid 22791); 28 Nov 2007 21:04:37 -0000 X-Spam-Check-By: sourceware.org Received: from pfepa.post.tele.dk (HELO pfepa.post.tele.dk) (195.41.46.235) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Nov 2007 21:04:28 +0000 Received: from x1-6-00-0f-9f-c6-3e-90 (x1-6-00-0f-9f-c6-3e-90.k75.webspeed.dk [80.197.1.215]) by pfepa.post.tele.dk (Postfix) with ESMTP id 30490FAC012; Wed, 28 Nov 2007 22:04:22 +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 lASL4Mqe011335; Wed, 28 Nov 2007 22:04:22 +0100 Received: (from rask@localhost) by x1-6-00-0f-9f-c6-3e-90 (8.14.0/8.14.0/Submit) id lASL4LZE011334; Wed, 28 Nov 2007 22:04:21 +0100 Date: Wed, 28 Nov 2007 23:03:00 -0000 From: Rask Ingemann Lambertsen To: Mark Mitchell Cc: Bernd Schmidt , Jie Zhang , gcc@gcc.gnu.org, GCC Patches , rsandifo@nildram.co.uk Subject: Re: Link tests after GCC_NO_EXECUTABLES Message-ID: <20071128210420.GH17368@sygehus.dk> References: <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> <87fxyqdc45.fsf@firetop.home> <474D943C.4030106@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474D943C.4030106@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-11/txt/msg01595.txt.bz2 On Wed, Nov 28, 2007 at 08:15:56AM -0800, Mark Mitchell wrote: > > If I'm understanding correctly: > > * You, Benjamin, and I think the previous behavior was best. > > * Bernd is flexible, as long as it works. > > * Rask prefers the new behavior because he thinks it will be more robust. > > Rask, we may have to agree to disagree, as it's clear we both understand > the pros and cons. I agree that making things link is more likely to > work, in the sense that it puts a lower burden on run-time library > configure scripts -- but I also think it increases the risk that the > configure scripts get the wrong answer. Here's a detail I'm missing. If you configure --with-newlib (or get it implicitly) and then link with something else when using the toolchain, then the answers will be wrong, but I don't see how that's any worse than assuming a set of hard coded link test results. > And, in some cases, there isn't > any way to get a bare-metal toolchain to link; the necessary bits may be > outside Newlib itself and provided only by the end user. That's not in itself a problem; you could supply --with-sysroot assuming you have all the necessary parts built already. It's only when you need GCC to build those other parts needed to link that it becomes a mess. At the moment, --with-newlib is a special case in that it allows you to configure and build a newlib target from scratch with just "configure ...; make" while e.g. glibc and uClibc targets need a more elaborate process, including building GCC twice in many cases, and perhaps installing intermediate libraries to satisfy link tests. A more general --with-libc=dirname option would configure and build in "dirname", then configure libstdc++ etc. with a "-B dirname" option to make link tests work. > But, for a bare-metal toolchain, I don't think we need that. So, I'm > guessing that: > > if test "x${with_newlib}" != "xyes"; then > AC_LIBTOOL_DLOPEN > fi > > will fix the problem. How about an explicit option --without-link-tests, --disable-link-tests or something like that? Most people don't test on bare-metal targets and won't notice if they break, but given an explicit option to turn off link tests, you could make it a requirement to test that configure works with link tests disabled before checking in changes to configure.{ac,in}. > (We already have checks for $with_newlib > elsewhere in configure.ac, so I think this is in the same spirit, though > a libstdc++ maintainer would of course be best to review the patch.) 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. A bit like having created config.cache by hand before configuring, I suppose. > Bernd, Richard, Rask, would one of you be willing to explore that route? I see that Richard has already started, so I'll leave it to him. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year