From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20465 invoked by alias); 5 Dec 2002 23:15:32 -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 20435 invoked from network); 5 Dec 2002 23:15:30 -0000 Received: from unknown (HELO egil.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 5 Dec 2002 23:15:30 -0000 Received: from zack by egil.codesourcery.com with local (Exim 3.36 #1 (Debian)) id 18K5DN-00067m-00; Thu, 05 Dec 2002 15:15:29 -0800 To: Nathanael Nerode Cc: 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> From: Zack Weinberg Date: Thu, 05 Dec 2002 15:19:00 -0000 In-Reply-To: <20021205223538.GA24616@doctormoo> (Nathanael Nerode's message of "Thu, 5 Dec 2002 17:35:38 -0500") Message-ID: <87adjk83ce.fsf@egil.codesourcery.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00202.txt.bz2 Nathanael Nerode writes: >>I'd like to remind everyone involved that last I checked it was flat >>impossible to do what libstdc++-v3/configure.in needs to do, using >>autoconf 2.5x. I am not particularly sanguine about the situation > > Flat impossible? > > Wow. Like I said, I'd be delighted to be proved wrong. > I'd be interested to hear more about the problem. Why can't it be > dealt with by using private macros? It was a couple years ago, but I think I still remember pretty clearly. First off, you've probably met this stuff (from libstdc++/aclocal.m4): # Never versions of autoconf add an underscore to these functions. # Prevent future problems ... ifdef([AC_PROG_CC_G],[],[define([AC_PROG_CC_G],defn([_AC_PROG_CC_G]))]) ifdef([AC_PROG_CC_GNU],[],[define([AC_PROG_CC_GNU],defn([_AC_PROG_CC_GNU]))]) ifdef([AC_PROG_CXX_G],[],[define([AC_PROG_CXX_G],defn([_AC_PROG_CXX_G]))]) ifdef([AC_PROG_CXX_GNU],[],[define([AC_PROG_CXX_GNU],defn([_AC_PROG_CXX_GNU]))]) # AC_PROG_CC # FIXME: We temporarily define our own version of AC_PROG_CC. This is # copied from autoconf 2.12, but does not call AC_PROG_CC_WORKS. We # are probably using a cross compiler, which will not be able to fully # link an executable. This is addressed in later versions of autoconf. AC_DEFUN(LIB_AC_PROG_CC, [AC_BEFORE([$0], [AC_PROG_CPP])dnl dnl Fool anybody using AC_PROG_CC. AC_PROVIDE([AC_PROG_CC]) AC_CHECK_PROG(CC, gcc, gcc) if test -z "$CC"; then AC_CHECK_PROG(CC, cc, cc, , , /usr/ucb/cc) test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH]) fi AC_PROG_CC_GNU if test $ac_cv_prog_gcc = yes; then GCC=yes dnl Check whether -g works, even if CFLAGS is set, in case the package dnl plays around with CFLAGS (such as to build both debugging and dnl normal versions of a library), tasteless as that idea is. ac_test_CFLAGS="${CFLAGS+set}" ac_save_CFLAGS="$CFLAGS" CFLAGS= AC_PROG_CC_G if test "$ac_test_CFLAGS" = set; then CFLAGS="$ac_save_CFLAGS" elif test $ac_cv_prog_cc_g = yes; then CFLAGS="-g -O2" else CFLAGS="-O2" fi else GCC= test "${CFLAGS+set}" = set || CFLAGS="-g" fi ]) This is a clone of the 2.13 AC_PROG_CC with some minor modifications: specifically, the AC_PROG_CC_WORKS call was removed. With autoconf 2.50+, the internal structure of AC_PROG_CC is totally different, and this definition breaks. (The "newer versions of autoconf" stuff was someone's attempt to fix it, but it doesn't work.) Someone on the autoconf team knew about this and tried to help out by providing an undocumented macro called AC_NO_EXECUTABLES: # 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 abble to provide the services its users # needs. # # 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. AC_DEFUN_ONCE([AC_NO_EXECUTABLES], [m4_divert_push([KILL]) AC_BEFORE([$0], [_AC_COMPILER_EXEEXT_WORKS]) AC_BEFORE([$0], [_AC_COMPILER_EXEEXT]) m4_define([_AC_COMPILER_EXEEXT_WORKS], [cross_compiling=maybe ]) m4_define([_AC_COMPILER_EXEEXT], [EXEEXT= ]) m4_define([AC_LINK_IFELSE], [AC_FATAL([All the tests involving linking were disabled by $0])]) m4_divert_pop()dnl ])# AC_NO_EXECUTABLES (lang.m4 from autoconf 2.56) 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. libstdc++-v3/configure.in has lots of AC_TRY_LINK tests. They are only executed in a native compilation, but that's not good enough for AC_NO_EXECUTABLES. Going over it all again, I realize that we could probably just redefine AC_NO_EXECUTABLES to do what we want. We'd have to specialize its definition for every version of autoconf that we cared about, and check at every new release that it hadn't broken, but it would work. I guess it's not impossible after all. zw