[ 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
