[RFC] Update to current automake/autoconf/libtool versions.

Zack Weinberg zack@codesourcery.com
Thu Dec 5 15:19:00 GMT 2002


Nathanael Nerode <neroden@twcny.rr.com> 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



More information about the Gdb-patches mailing list