Re: [PATCH] Fix PR bootstrap/42798

[Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>]

[ adding bug-autoconf ]

* Ian Lance Taylor wrote on Mon, Jun 07, 2010 at 04:03:47PM CEST:
> Ralf Wildenhues writes:
> > * Ian Lance Taylor wrote on Sun, Jun 06, 2010 at 11:42:13PM CEST:
> >
> >> My question about a basename declaration in the system header was a
> >> genuine question.  My concern is that on some systems this patch might
> >> decide incorrectly whether or not basename is defined, which could
> >> then possibly lead to a compilation error when libiberty.h is
> >> included.
> >
> > This concern should be addressed with my reply
> > <http://sourceware.org/ml/binutils/2010-06/msg00059.html>:
> > In short, the Autoconf change is designed to handle exactly this case
> > right both in C and in C++ mode.
> 
> That doesn't really address my concern.  That shows that autoconf will
> get a workable answer if I use only C++.  But there is only one
> config.h file.  gold has both .c and .cc files (the .c files are used
> via AC_REPLACE_FUNCS).  It's not obvious to me that a version of
> HAVE_DECL_BASENAME for C++ will necessarily work when compiling C.

OK, fair point.  The current Autoconf solution for AC_CHECK_DECLS
assumes that the developer either uses the answer for the compiler
language tested only, or that the answer is consistent between the
C and the C++ compiler.

When we find a case where this assumption does not hold, we can still
work with the current framework by using AC_CHECK_DECL (without 'S')
and setting per-language defines, e.g.:

  AC_LANG_PUSH([C])
  AC_CHECK_DECLS([basename]) dnl defines HAVE_DECL_BASENAME
  AC_LANG_POP([C])

  AC_LANG_PUSH([C++])
  AC_CHECK_DECL([basename(char *)],
                [AC_DEFINE([HAVE_DECL_BASENAME_CXX], [1],
                           [Define to 1 if you have a C++ declaration ]dnl
                           [of `basename(char *)'])])
  AC_LANG_POP([C++])

and then go from there.

But I don't think we need to go there unless we find a system that
warrants this.  Autoconf is assuming similar in a number of cases
already: With AC_C_RESTRICT, it first tries a spelling of restrict
that is likely to work with both C++ and C compilers, but only the
C compiler is tested (and when you mix compilers from different
vendors, such as GNU and Solaris, this is a problem).

Cheers,
Ralf