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

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

[Nathanael Nerode]

>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.

And for the top level, all I had to do was define my own entire set of
macros to replace the AC_CHECK_TOOL and AC_PROG_* collection. :-)

I'd be interested to hear more about the problem.  Why can't it be dealt 
with by using private macros?

--Nathanael

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

[Zack Weinberg]

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

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

[Tom Tromey]

>>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:

Zack> Someone on the autoconf team knew about this and tried to help out by
Zack> providing an undocumented macro called AC_NO_EXECUTABLES:

Zack> # FIXME: The GCC team has specific needs which the current Autoconf
Zack> # framework cannot solve elegantly.  This macro implements a dirty
Zack> # hack until Autoconf is abble to provide the services its users
Zack> # needs.

Zack> They are only executed in a native compilation, but that's not good
Zack> enough for AC_NO_EXECUTABLES.

Presumably if AC_NO_EXECUTABLES exists solely for the use of gcc, then
it could be changed to do what gcc actually requires.

Tom

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

[Alexandre Oliva]

On Dec  5, 2002, Zack Weinberg <zack@codesourcery.com> wrote:

> 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.

Please tell me why (2) doesn't make sense.

If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
you expect to get any useful results from AC_TRY_LINK?

> libstdc++-v3/configure.in has lots of AC_TRY_LINK tests.

If we know AC_PROG_CC_WORKS fails, it is a mistake to use AC_TRY_LINK
tests.  Removing the constraint from autoconf will do us no good.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

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

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Dec  5, 2002, Zack Weinberg <zack@codesourcery.com> wrote:
>
>> 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.
>
> Please tell me why (2) doesn't make sense.
>
> If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
> you expect to get any useful results from AC_TRY_LINK?

Because libstdc++'s AC_TRY_LINK tests are only executed in a situation
where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation).

zw

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

[Alexandre Oliva]

On Dec  7, 2002, Zack Weinberg <zack@codesourcery.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> On Dec  5, 2002, Zack Weinberg <zack@codesourcery.com> wrote:
>> 
>>> 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.
>> 
>> Please tell me why (2) doesn't make sense.
>> 
>> If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
>> you expect to get any useful results from AC_TRY_LINK?

> Because libstdc++'s AC_TRY_LINK tests are only executed in a situation
> where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation).

I don't get it.  Why does being able to link have anything to do with
being native?  Being able to *run* tests has to do with being native,
but that's not the point, and autoconf already avoids running tests
when cross-building.  But being able to link has to do with whether
the libraries that the compiler links in by default are present or
not.  That's the purpose of AC_NO_EXECUTABLES: to disable link tests
while building a library that the compiler driver would attempt to link
in by default, such as newlib, libstdc++ or libgcj.

That said, I'm not sure it should be used for libstdc++, since there's
no reason to use g++: we should use gcc instead, even if we perform
C++ link tests.  Ditto for libjava, I suppose, but I realize it would
be far trickier to get libjava to link C programs :-)

Still, I think AC_NO_EXECUTABLES may affect all linking whatsoever,
not only that of the language in effect at the point it appears, which
does indeed make it useless for anything other that newlib.  But, for
newlib, preventing link tests *is* the right thing to do, and I
contend that it's the right thing to do for any language affected by
the AC_NO_EXECUTABLES declaration.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

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

[Geoff Keating]

Alexandre Oliva <aoliva@redhat.com> writes:

> I don't get it.  Why does being able to link have anything to do with
> being native?  Being able to *run* tests has to do with being native,
> but that's not the point, and autoconf already avoids running tests
> when cross-building.  But being able to link has to do with whether
> the libraries that the compiler links in by default are present or
> not.  That's the purpose of AC_NO_EXECUTABLES: to disable link tests
> while building a library that the compiler driver would attempt to link
> in by default, such as newlib, libstdc++ or libgcj.

Aah, I see.  No, that's not the purpose of AC_NO_EXECUTABLES, or at
least it's not what GCC wants out of it.  Some platforms can't link
anything at all without special care.  For instance, you might need to
know what board you plan to run the executable on and pass an
appropriate flag (or supply an appropriate crt0 by hand).  For another
example, vxworks can't and doesn't link anything, the final link takes
place at runtime on the board, "executables" are created using 'ld
-r', and you can refer to any symbols you like in the hope that
they'll be available later.

It's assumed that in a native case, this sort of thing won't happen,
thus the existing behaviour.  Maybe instead you could perform a
configure-time test to see if the platform can link anything at all
(and will fail to link with an obviously bogus symbol), and then base
the decision of whether to run link tests on that, instead of the
current approximation, but there'll still be some cases when linking
is not possible, and other cases (the majority) in which link tests
are possible and desirable.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

AC_NO_EXECUTABLES is useless for GCC

[Alexandre Oliva]

On Dec 10, 2002, Geoff Keating <geoffk@geoffk.org> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> I don't get it.  Why does being able to link have anything to do with
>> being native?  Being able to *run* tests has to do with being native,
>> but that's not the point, and autoconf already avoids running tests
>> when cross-building.  But being able to link has to do with whether
>> the libraries that the compiler links in by default are present or
>> not.  That's the purpose of AC_NO_EXECUTABLES: to disable link tests
>> while building a library that the compiler driver would attempt to link
>> in by default, such as newlib, libstdc++ or libgcj.

> Aah, I see.  No, that's not the purpose of AC_NO_EXECUTABLES, or at
> least it's not what GCC wants out of it.  Some platforms can't link
> anything at all without special care.  For instance, you might need to
> know what board you plan to run the executable on and pass an
> appropriate flag (or supply an appropriate crt0 by hand).  For another
> example, vxworks can't and doesn't link anything, the final link takes
> place at runtime on the board, "executables" are created using 'ld
> -r', and you can refer to any symbols you like in the hope that
> they'll be available later.

I see.  Oh, well...  I was missing this bit of info when I designed
AC_NO_EXECUTABLES :-(  My apologies...

> It's assumed that in a native case, this sort of thing won't happen,
> thus the existing behaviour.  Maybe instead you could perform a
> configure-time test to see if the platform can link anything at all
> (and will fail to link with an obviously bogus symbol), and then base
> the decision of whether to run link tests on that, instead of the
> current approximation, but there'll still be some cases when linking
> is not possible, and other cases (the majority) in which link tests
> are possible and desirable.

I think we'll be better served by declarative macros such as
AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated
sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail
out if it fails, but rather it sets a variable indicating the result
of the test, such that we could base our decision on whether to
perform additional link tests on this variable.  Does it sound like
this would work?

Do we actually need AC_*_LINK_MAY_FAIL, or would a single
AC_LINK_MAY_FAIL macro be sufficient for libstdc++ and libgcj's needs?


Or perhaps we could make do with a configure argument that would tell
autoconf it's ok if the initial link test fails.  It could even
short-circuit all other configure link tests, such that one might be
able to configure a package containing link tests for a system that
doesn't really support linking.  The reason to not have this behavior
enabled by default is that we do want to detect situations when the
compiler is broken (the number of bogus reports caused by them used to
be huge when we didn't do it), but if a standard configure argument
disables the test, I think we're kind of ok.

Thoughts?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: AC_NO_EXECUTABLES is useless for GCC

[Ian Lance Taylor]

Alexandre Oliva <aoliva@redhat.com> writes:

> I think we'll be better served by declarative macros such as
> AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated
> sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail
> out if it fails, but rather it sets a variable indicating the result
> of the test, such that we could base our decision on whether to
> perform additional link tests on this variable.  Does it sound like
> this would work?

This approach sounds weird to me.  The basic problem is that
AC_PROG_CC does the wrong thing for libstdc++ and a few other
configure scripts--namely, it executes the test of whether the
compiler works.  It seems to me that AC_PROG_CC should call some
helper macros--perhaps just two--and that libstdc++ should call a
subset of those helper macros--perhaps just one.

Adding macros which change the behaviour of other macros seems
confusing.  I don't see the advantage of that at all.

Ian

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

[Tom Tromey]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

>> But, (2) it causes autoconf to barf if an AC_TRY_LINK test appears
>> anywhere in the script being generated.

Alexandre> Please tell me why (2) doesn't make sense.

Alexandre> If AC_PROG_CC_WORKS can't even link a do-nothing program,
Alexandre> how would you expect to get any useful results from
Alexandre> AC_TRY_LINK?

The autoconf code in question completely disables AC_LINK_IFELSE.
However, we know we can successfully do link tests when building
natively.  And, at least in libgcj's case, this knowledge is important
because we use it to make libgcj more functional when built native.

FYI I sent a patch to the autoconf list.

Tom