[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix PR bootstrap/42798

From: Ralf Wildenhues
Subject: Re: [PATCH] Fix PR bootstrap/42798
Date: Mon, 7 Jun 2010 22:24:15 +0200
User-agent: Mutt/1.5.20 (2009-10-28)

[ 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_CHECK_DECLS([basename]) dnl defines HAVE_DECL_BASENAME

  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 *)'])])

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]