GNU bug report logs - #31347
AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Mike Miller <mtmiller <at> octave.org>
Subject: bug#31347: closed (Re: bug#31347: AM_PROG_CC_C_O is disabled by
 gnulib std-gnu11.m4)
Date: Fri, 10 Dec 2021 07:39:01 +0000

[Message part 1 (text/plain, inline)]

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 31347 <at> debbugs.gnu.org.

-- 
31347: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31347
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Mike Frysinger <vapier <at> gentoo.org>
To: Jamal Natour <jamal.natour <at> fumasoftware.com>
Cc: 31347-done <at> debbugs.gnu.org, Mike Miller <mtmiller <at> octave.org>
Subject: Re: bug#31347: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4
Date: Fri, 10 Dec 2021 02:38:19 -0500

[Message part 3 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

[Message part 5 (message/rfc822, inline)]

From: Mike Miller <mtmiller <at> octave.org>
To: bug-automake <at> gnu.org
Subject: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4
Date: Wed, 2 May 2018 15:56:01 -0700

[Message part 6 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.