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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31347 in the body.
You can then email your comments to 31347 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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 1 (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)]

Message #8 received at 31347 <at> debbugs.gnu.org (full text, mbox):

From: Jamal Natour <jamal.natour <at> fumasoftware.com>
To: Mike Miller <mtmiller <at> octave.org>
Cc: 31347 <at> debbugs.gnu.org
Subject: Re: bug#31347: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4
Date: Thu, 3 May 2018 10:11:50 +0100

Hi,

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.

HTH

Jamal

On 15:56 Wed 02 May 2018    , Mike Miller wrote:
> 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



--
Fuma Software Ltd.
Kemp House, 152-160 City Road, London, EC1V 2NX

mob : +44(0)7830 164 097
tel : +44(0)2070 961 904
mail: jamal.natour <at> fumasoftware.com
Registered in England and Wales 6870430

Message #13 received at 31347-done <at> debbugs.gnu.org (full text, mbox):

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 1 (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)]

Previous Next

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