Hello,
With the late increase in number of clang users, we're getting a number
of bugs related to the packages relying on gnu89/gnu99 standards
compiler compliance without proper checks for it. Those packages fail
to build because clang uses strict -std=c99 by default, and they fail
to provide
On 02/02/2013 05:13 AM, Michał Górny wrote:
In order to solve that properly, I would like to request having two new
macros in autoconf: AC_PROG_CC_GNU89 and AC_PROG_CC_GNU99, in a similar
manner to the AC_PROG_CC_C99 macro.
We've been moving in the opposite direction:
AC_PROG_CC_STDC,
On Sat, 02 Feb 2013 08:36:17 -0800
Paul Eggert egg...@cs.ucla.edu wrote:
On 02/02/2013 05:13 AM, Michał Górny wrote:
In order to solve that properly, I would like to request having two new
macros in autoconf: AC_PROG_CC_GNU89 and AC_PROG_CC_GNU99, in a similar
manner to the AC_PROG_CC_C99
On 02/02/2013 09:09 AM, Michał Górny wrote:
The major issue we've been having is difference in inline semantics
between gnu89 and c99. It hit us at least with libgcrypt [1,2],
pkg-config [3,4], e2fsprogs [5].
OK, this is a different matter than what AC_PROG_CC will do.
AC_PROG_CC will enable
The attached patch introduces three macros:
AC_CXX_CONSTEXPR
AC_CXX_FINAL
AC_CXX_NULLPTR
which behave like AC_C_CONST et al but are for the new
C++11 constextr, final and nullptr keywords. I can add
additional macros for other keywords, but not all of them
have the possibility of falling
Roger Leigh rle...@codelibre.net writes:
The attached patch introduces three macros:
AC_CXX_CONSTEXPR
AC_CXX_FINAL
AC_CXX_NULLPTR
which behave like AC_C_CONST et al but are for the new
C++11 constextr, final and nullptr keywords.
All of these seem a bit questionable...
The problem
