From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12688 invoked by alias); 10 Dec 2002 05:52:57 -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 12604 invoked from network); 10 Dec 2002 05:52:55 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 10 Dec 2002 05:52:55 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva2.cipe.redhat.com [10.0.1.156]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id gBA5qQN02316; Tue, 10 Dec 2002 00:52:26 -0500 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5) with ESMTP id gBA5qQZP009487; Tue, 10 Dec 2002 03:52:26 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5/Submit) id gBA5qPsQ009483; Tue, 10 Dec 2002 03:52:25 -0200 To: Geoff Keating Cc: Nathanael Nerode , gdb-patches@sources.redhat.com, binutils@sources.redhat.com, newlib@sources.redhat.com, gcc@gcc.gnu.org, autoconf@gnu.org Subject: AC_NO_EXECUTABLES is useless for GCC References: <20021205223538.GA24616@doctormoo> <87adjk83ce.fsf@egil.codesourcery.com> <874r9pleth.fsf@egil.codesourcery.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Mon, 09 Dec 2002 22:05:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00316.txt.bz2 On Dec 10, 2002, Geoff Keating wrote: > 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. I see. Oh, well... I was missing this bit of info when I designed AC_NO_EXECUTABLES :-( My apologies... > 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. I think we'll be better served by declarative macros such as AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail out if it fails, but rather it sets a variable indicating the result of the test, such that we could base our decision on whether to perform additional link tests on this variable. Does it sound like this would work? Do we actually need AC_*_LINK_MAY_FAIL, or would a single AC_LINK_MAY_FAIL macro be sufficient for libstdc++ and libgcj's needs? Or perhaps we could make do with a configure argument that would tell autoconf it's ok if the initial link test fails. It could even short-circuit all other configure link tests, such that one might be able to configure a package containing link tests for a system that doesn't really support linking. The reason to not have this behavior enabled by default is that we do want to detect situations when the compiler is broken (the number of bogus reports caused by them used to be huge when we didn't do it), but if a standard configure argument disables the test, I think we're kind of ok. Thoughts? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer