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

[GNU bug Tracking System]

Your message dated Fri, 10 Dec 2021 02:38:19 -0500
with message-id <YbMD69Hcb/kJPN68@vapier>
and subject line Re: bug#31347: AM_PROG_CC_C_O is disabled by gnulib 
std-gnu11.m4
has caused the debbugs.gnu.org bug report #31347,
regarding AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


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

--- Begin Message --- Subject: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4 Date: Wed, 2 May 2018 15:56:01 -0700 User-agent: Mutt/1.9.4 (2018-02-28)

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
Description: PGP signature

--- End Message ---

--- Begin Message --- 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

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
Description: PGP signature

--- End Message ---