Subject: bug#31347: closed (Re: bug#31347: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 10 Dec 2021 07:39:01 +0000

Your bug report

#31347: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
31347: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31347
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#31347: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4
From: Mike Frysinger <[email-masked]>
To: Jamal Natour <[email-masked]>
Cc: [email-masked], Mike Miller <[email-masked]>
Date: Fri, 10 Dec 2021 02:38:19 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

On 03 May 2018 10:11, Jamal Natour wrote:
> As a user of C++11 and C++14, I use the ax_cxx_compile_stdcxx variants,
> these have seemed to work on the various combinations of
> platforms/compilers I've used.
> 
> https://github.com/jamal-fuma/fuma_m4/blob/master/ax_cxx_compile_stdcxx.m4
> https://github.com/jamal-fuma/fuma_m4/blob/master/ax_cxx_compile_stdcxx_14.m4
> 
> Perhaps these will offer a workaround until such time as you can solve
> the issue.

yeah, i'm kind of inclined to say use macros from the autoconf archive instead:
https://www.gnu.org/software/autoconf-archive/

that said, the latest autoconf release defaults to C11 if it can find it, so
maybe the issue in general is moot ?

you might have found a real bug, but i'm not sure how much effort we want to
put into having internal autoconf macros redefined.   
-mike

Subject: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4
From: Mike Miller <[email-masked]>
To: [email-masked]
Date: Wed, 2 May 2018 15:56:01 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

In GNU Octave, we are embracing a lot of C++11, and so we are using the
gnulib std-gnu11.m4 drop-in to ensure that the compiler conforms to the
latest standards. I think several other GNU projects also use this file.

The std-gnu11.m4 file defines AC_PROG_CC and AC_PROG_CXX replacements,
which I think are backported from Autoconf git.

In a trivial project, for example

    AC_INIT([test], [0])
    AM_INIT_AUTOMAKE([1.14 foreign])
    AC_PROG_CC
    AC_CONFIG_FILES([Makefile])
    AC_OUTPUT

the AM_PROG_CC_C_O feature test is automatically called, as expected and
described in the Automake 1.14 NEWS.

With std-gnu11.m4 added to this project, however, the AM_PROG_CC_C_O
macro is no longer called, either automatically or manually. The
intention of Automake to ensure that this test is always done is
defeated simply by including this file.

If a call to the real macro

    _AM_PROG_CC_C_O

is added after AC_PROG_CC, then the feature test is restored.

I know enough m4 to get by, but I suspect this has to do with the order
of inclusion, and that Automake redefines AC_PROG_CC to call its own
_AM_PROG_CC_C_O, which is later clobbered by the inclusion of
std-gnu11.m4.

Is there anything Automake can do to ensure that AM_PROG_CC_C_O is
called even if AC_PROG_CC is redefined locally?

Even if you judge this not to be an Automake bug, I wanted to bring this
to your attention, since the std-gnu11.m4 file is the recommended way to
rely on modern language standards support at the moment.

Thanks,

-- 
mike