From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30847 invoked by alias); 27 Aug 2003 17:15:09 -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 30827 invoked from network); 27 Aug 2003 17:15:07 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 27 Aug 2003 17:15:07 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19s3sx-0004Oi-Ec; Wed, 27 Aug 2003 13:15:07 -0400 Date: Wed, 27 Aug 2003 17:15:00 -0000 From: Daniel Jacobowitz To: gcc-patches@gcc.gnu.org Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: [toplevel] GCC_NO_EXECUTABLES Message-ID: <20030827171507.GA14215@nevyn.them.org> Mail-Followup-To: gcc-patches@gcc.gnu.org, binutils@sources.redhat.com, gdb-patches@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00481.txt.bz2 I'll submit this piece separately from the users of it... This is a modified version of AC_NO_EXECUTABLES. Yes, I'm aware that this should be submitted to Autoconf eventually, probably to replace AC_NO_EXECUTABLES; I would like it to stew in the GCC tree for a little while first, however. It's closer to the internals of autoconf than I really wanted it to be. DJ, I know you asked for this to be added to acx.m4 instead. Unfortunately, it uses constructs that autoconf 2.13 can't parse, thus breaking regenerating the toplevel configure. So I put it in a separate file after all. Tested, along with the patches to follow momentarily, on an extensive collection of targets (all --build=i686-linux). Is this OK? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 2003-08-27 Daniel Jacobowitz * config/no-executables.m4: New file. # GCC_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 the previous AC_NO_EXECUTABLES, this test does not # disable link tests at autoconf time, but at configure time. # This allows AC_NO_EXECUTABLES to be invoked conditionally. AC_DEFUN_ONCE([GCC_NO_EXECUTABLES], [m4_divert_push([KILL]) AC_BEFORE([$0], [_AC_COMPILER_EXEEXT]) AC_BEFORE([$0], [AC_LINK_IFELSE]) m4_define([_AC_COMPILER_EXEEXT], AC_LANG_CONFTEST([AC_LANG_PROGRAM()]) # FIXME: Cleanup? AS_IF([AC_TRY_EVAL(ac_link)], [gcc_no_link=no], [gcc_no_link=yes]) if test x$gcc_no_link = xyes; then # 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= else m4_defn([_AC_COMPILER_EXEEXT])dnl fi ) m4_define([AC_LINK_IFELSE], if test x$gcc_no_link = xyes; then AC_MSG_ERROR([Link tests are not allowed after [[$0]].]) fi m4_defn([AC_LINK_IFELSE])) dnl This is a shame. We have to provide a default for some link tests, dnl similar to the default for run tests. m4_define([AC_FUNC_MMAP], if test x$gcc_no_link = xyes; then if test "x${ac_cv_func_mmap_fixed_mapped+set}" != xset; then ac_cv_func_mmap_fixed_mapped=no fi fi if test "x${ac_cv_func_mmap_fixed_mapped+set}" != xset; then m4_defn([AC_FUNC_MMAP]) fi) m4_divert_pop()dnl ])# GCC_NO_EXECUTABLES