From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4570 invoked by alias); 10 Dec 2002 02:56:27 -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 4432 invoked from network); 10 Dec 2002 02:56:25 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 10 Dec 2002 02:56:25 -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 gBA2u8N12699; Mon, 9 Dec 2002 21:56:08 -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 gBA2u7ZP005966; Tue, 10 Dec 2002 00:56:07 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5/Submit) id gBA2u6uQ005962; Tue, 10 Dec 2002 00:56:06 -0200 To: Zack Weinberg 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: Alexandre Oliva Organization: GCC Team, Red Hat Date: Mon, 09 Dec 2002 19:16:00 -0000 In-Reply-To: <874r9pleth.fsf@egil.codesourcery.com> 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/msg00312.txt.bz2 On Dec 7, 2002, Zack Weinberg wrote: > Alexandre Oliva writes: >> On Dec 5, 2002, Zack Weinberg wrote: >> >>> AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of >>> AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf >>> to barf if an AC_TRY_LINK test appears anywhere in the script being >>> generated. >> >> Please tell me why (2) doesn't make sense. >> >> If AC_PROG_CC_WORKS can't even link a do-nothing program, how would >> you expect to get any useful results from AC_TRY_LINK? > Because libstdc++'s AC_TRY_LINK tests are only executed in a situation > where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation). 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. That said, I'm not sure it should be used for libstdc++, since there's no reason to use g++: we should use gcc instead, even if we perform C++ link tests. Ditto for libjava, I suppose, but I realize it would be far trickier to get libjava to link C programs :-) Still, I think AC_NO_EXECUTABLES may affect all linking whatsoever, not only that of the language in effect at the point it appears, which does indeed make it useless for anything other that newlib. But, for newlib, preventing link tests *is* the right thing to do, and I contend that it's the right thing to do for any language affected by the AC_NO_EXECUTABLES declaration. -- 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