From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1418 invoked by alias); 10 Dec 2002 04:59:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1341 invoked from network); 10 Dec 2002 04:59:11 -0000 Received: from unknown (HELO desire.geoffk.org) (12.235.56.190) by sources.redhat.com with SMTP; 10 Dec 2002 04:59:11 -0000 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id gBA4x1828480; Mon, 9 Dec 2002 20:59:01 -0800 X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f To: Alexandre Oliva Cc: Nathanael Nerode , gdb-patches@sources.redhat.com, binutils@sources.redhat.com, newlib@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: [RFC] Update to current automake/autoconf/libtool versions. References: <20021205223538.GA24616@doctormoo> <87adjk83ce.fsf@egil.codesourcery.com> <874r9pleth.fsf@egil.codesourcery.com> From: Geoff Keating Date: Mon, 09 Dec 2002 21:52:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00315.txt.bz2 Alexandre Oliva writes: > I don't get it. Why does being able to link have anything to do with > being native? Being able to *run* tests has to do with being native, > but that's not the point, and autoconf already avoids running tests > when cross-building. But being able to link has to do with whether > the libraries that the compiler links in by default are present or > not. That's the purpose of AC_NO_EXECUTABLES: to disable link tests > while building a library that the compiler driver would attempt to link > in by default, such as newlib, libstdc++ or libgcj. Aah, I see. No, that's not the purpose of AC_NO_EXECUTABLES, or at least it's not what GCC wants out of it. Some platforms can't link anything at all without special care. For instance, you might need to know what board you plan to run the executable on and pass an appropriate flag (or supply an appropriate crt0 by hand). For another example, vxworks can't and doesn't link anything, the final link takes place at runtime on the board, "executables" are created using 'ld -r', and you can refer to any symbols you like in the hope that they'll be available later. It's assumed that in a native case, this sort of thing won't happen, thus the existing behaviour. Maybe instead you could perform a configure-time test to see if the platform can link anything at all (and will fail to link with an obviously bogus symbol), and then base the decision of whether to run link tests on that, instead of the current approximation, but there'll still be some cases when linking is not possible, and other cases (the majority) in which link tests are possible and desirable. -- - Geoffrey Keating