public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zack@codesourcery.com>
To: Nathanael Nerode <neroden@twcny.rr.com>
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.
Date: Thu, 05 Dec 2002 15:19:00 -0000	[thread overview]
Message-ID: <87adjk83ce.fsf@egil.codesourcery.com> (raw)
In-Reply-To: <20021205223538.GA24616@doctormoo> (Nathanael Nerode's message of "Thu, 5 Dec 2002 17:35:38 -0500")

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

  reply	other threads:[~2002-12-05 23:15 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-05 14:36 Nathanael Nerode
2002-12-05 15:19 ` Zack Weinberg [this message]
2002-12-06  9:33   ` Tom Tromey
2002-12-07 12:55   ` Alexandre Oliva
2002-12-07 13:19     ` Zack Weinberg
2002-12-09 18:57       ` Alexandre Oliva
2002-12-09 21:52         ` Geoff Keating
2002-12-09 22:10           ` AC_NO_EXECUTABLES is useless for GCC Alexandre Oliva
2002-12-09 22:27             ` Ian Lance Taylor
2002-12-08 13:48     ` [RFC] Update to current automake/autoconf/libtool versions Tom Tromey
     [not found] <9A4230D6-1D26-11D7-BFCA-00039396EEB8@apple.com>
2003-01-12 20:20 ` Alexandre Oliva
  -- strict thread matches above, loose matches on Subject: below --
2003-01-01 10:39 Nathanael Nerode
     [not found] <20021206005522.GA11907@doctormoo>
     [not found] ` <87of7sa16x.fsf@egil.codesourcery.com>
2002-12-12 13:29   ` Nathanael Nerode
2002-12-13  5:31     ` Alexandre Oliva
2002-12-10 19:33 Henry Nelson
2002-12-05 14:40 Joern Rennecke
2002-12-05 11:08 Nathanael Nerode
2002-12-05 11:31 ` Andrew Cagney
2002-12-05 13:31 ` Zack Weinberg
2002-12-05 14:29   ` Alan Modra
2002-12-05 15:14     ` Ian Lance Taylor
2002-12-05 15:32       ` Alan Modra
2002-12-05 15:45         ` Ian Lance Taylor
2002-12-05 16:26           ` Andrew Cagney
2002-12-05 15:47         ` Mike Stump
2002-12-05 16:30           ` Alan Modra
2002-12-05 16:36             ` Zack Weinberg
2002-12-08  2:48         ` Klee Dienes
2002-12-05 14:07 ` Christopher Faylor
2002-12-06  7:25 ` Maciej W. Rozycki
2002-12-08  3:23 ` Klee Dienes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87adjk83ce.fsf@egil.codesourcery.com \
    --to=zack@codesourcery.com \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=neroden@twcny.rr.com \
    --cc=newlib@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).