From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5946 invoked by alias); 26 Nov 2004 01:09:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5931 invoked from network); 26 Nov 2004 01:09:05 -0000 Received: from unknown (HELO relay.pair.com) (209.68.1.20) by sourceware.org with SMTP; 26 Nov 2004 01:09:05 -0000 Received: (qmail 45707 invoked from network); 26 Nov 2004 01:09:04 -0000 Received: from unknown (HELO ?192.168.1.12?) (unknown) by unknown with SMTP; 26 Nov 2004 01:09:04 -0000 X-pair-Authenticated: 219.162.234.247 Message-ID: <41A6826D.3010107@pogma.com> Date: Fri, 26 Nov 2004 03:26:00 -0000 From: Peter O'Gorman User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) MIME-Version: 1.0 To: Stan Shebs CC: Benjamin Kosnik , gcc@gcc.gnu.org Subject: Re: 64-bit configure hell References: <20041125102826.1cf9ebb5.bkoz@redhat.com> <41A64456.7010304@apple.com> In-Reply-To: <41A64456.7010304@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg01008.txt.bz2 Stan Shebs wrote: > The crux of the problem seems to be _AC_COMPILER_EXEEXT_WORKS in > autoconf's lang.m4, which looks like it fishes for a usable file > extension by trying to run programs with various names. Isn't this what AC_NO_EXECUTABLES (also in lang.m4) is for? from cvs autoconf's lang.m4: # AC_NO_EXECUTABLES # ----------------- # FIXME: The GCC team has specific needs which the current Autoconf # framework cannot solve elegantly. This macro implements a dirty # hack until Autoconf is able to provide the services its users # need. # # Several of the support libraries that are often built with GCC can't # assume the tool-chain is already capable of linking a program: the # compiler often expects to be able to link with some of such # libraries. # # In several of these libraries, workarounds have been introduced to # avoid the AC_PROG_CC_WORKS test, that would just abort their # configuration. The introduction of AC_EXEEXT, enabled either by # libtool or by CVS autoconf, have just made matters worse. # # Unlike an earlier version of this macro, using AC_NO_EXECUTABLES does # not disable link tests at autoconf time, but at configure time. # This allows AC_NO_EXECUTABLES to be invoked conditionally. AC_DEFUN_ONCE([AC_NO_EXECUTABLES], [m4_divert_push([KILL]) m4_divert_text([DEFAULTS], [ac_no_link=no]) AC_BEFORE([$0], [_AC_COMPILER_EXEEXT]) AC_BEFORE([$0], [AC_LINK_IFELSE]) m4_define([_AC_COMPILER_EXEEXT], [AC_LANG_CONFTEST([AC_LANG_PROGRAM()]) if AC_TRY_EVAL(ac_link); then ac_no_link=no ]m4_defn([_AC_COMPILER_EXEEXT])[ else ac_no_link=yes # Setting cross_compile will disable run tests; it will # also disable AC_CHECK_FILE but that's generally # correct if we can't link. cross_compiling=yes EXEEXT= _AC_COMPILER_EXEEXT_CROSS fi ]) m4_define([AC_LINK_IFELSE], [if test x$ac_no_link = xyes; then AC_MSG_ERROR([Link tests are not allowed after AC@&t@_NO_EXECUTABLES.]) fi ]m4_defn([AC_LINK_IFELSE])) m4_divert_pop()dnl ])# AC_NO_EXECUTABLES Peter -- Peter O'Gorman - http://www.pogma.com