Feature request: AC_PROG_CC_* macros for gnu89/gnu99-compliant compiler

[Michał Górny]

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 proper -std=gnu89 or -std=gnu99.

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.

I'm not sure what checks can be used to distinguish between strict
standards and GNU ones. But the general idea is that those macros
should cause clang to be run with '-std=gnu89' or '-std=gnu99'
as required by the package.

What are your thoughts?

[Paul Eggert]

Post by Michał Górny
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, AC_PROG_CC_C89 and AC_PROG_CC_C99 will be marked as
obsolescent in the next version of Autoconf. The idea
is that AC_PROG_CC should "just work", and maintainers
shouldn't have to fiddle with all those AC_PROG_CC_whatever
macros whenever a new compiler comes out.

Can you give an example of a package that has a problem,
and symptoms of the problem? That might help us come up with
a better solution. For example, what happens if you configure
with "./configure CC='clang -std=gnu11'"?

[Michał Górny]

On Sat, 02 Feb 2013 08:36:17 -0800

Post by Paul Eggert

Post by Michał Górny
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.

AC_PROG_CC_STDC, AC_PROG_CC_C89 and AC_PROG_CC_C99 will be marked as
obsolescent in the next version of Autoconf. The idea
is that AC_PROG_CC should "just work", and maintainers
shouldn't have to fiddle with all those AC_PROG_CC_whatever
macros whenever a new compiler comes out.
Can you give an example of a package that has a problem,
and symptoms of the problem? That might help us come up with
a better solution. For example, what happens if you configure
with "./configure CC='clang -std=gnu11'"?

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

The usual way of fixing it on our side was appending 'std=gnu89'
or a similar option. But I believe configure scripts should handle this
for us...

[1]:https://bugs.gentoo.org/show_bug.cgi?id=420899
[2]:https://bugs.g10code.com/gnupg/issue1406
[3]:https://bugs.gentoo.org/show_bug.cgi?id=297248
[4]:https://bugs.freedesktop.org/show_bug.cgi?id=29313
[5]:https://bugs.gentoo.org/show_bug.cgi?id=297243

[Paul Eggert]

Post by Michał Górny
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 extensions if available. But the
inline semantics issue is something where, if I understand things
correctly, a package explicitly wants the old GNU inline semantics
for 'inline', and doesn't want the C99 semantics for 'inline'
that is supported by clang and by newer versions of GCC.
That's not an extension: it's a change to the language.

One possibility is that Autoconf could add a macro
AC_CC_OLD_GNU_INLINE, or something like that, which
would cause 'configure' to arrange for the old GNU inline
semantics and to fail if this can't be arranged.
Is that a macro that you could write?

But maybe we don't need to have such a macro.
Aren't the packages in question intended to
be used with newer compilers? If so, they need to be updated
to use C99 semantics for 'inline', since we can't expect every
new compiler to support the old GCC 'inline' semantics. And then
AC_PROG_CC will already do what we want, since it'll (in the next
version of Autoconf, anyway), ask newer GCCs to use the C99-compatible
'inline' semantics. By "newer GCCs" I mean GCC 4.3 or later, if
I'm reading the release notes correctly.