[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++ pre-processor flags not updated by ax_cxx_compile_stdcxx.m4

From: Moritz Klammler
Subject: Re: C++ pre-processor flags not updated by ax_cxx_compile_stdcxx.m4
Date: Mon, 21 Mar 2016 22:30:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Thanks, I can confirm this.  It seems that this is documented (if maybe
not desired) behavior.  The documentation [1] of the `AC_PROG_CXXCPP`
macro says:

> Set output variable `CXXCPP` to a command that runs the C++
> preprocessor.  If `$CXX -E` doesn't work, `/lib/cpp` is used.  It is
> only portable to run `CXXCPP` on files with a `.c`, `.C`, or `.cc`
> extension.

Therefore, if you invoke `AC_PROG_CXXCPP` *before*
`AX_CXX_COMPILE_STDCXX`, the standard selection switch does not affect
the pre-processor.  The solution is to call the macros in this order:


    # Check for headers ...

This ordering dependency might not be pretty, but I don't see anything
we could do about it at this point.

Alternatively, if you don't actually need it, you could consider leaving
out the call to `AC_PROG_CXXCPP` completely.


Kip Warner <address@hidden> writes:

> [[PGP Signed Part:No public key for 2D79DF2BB6E28B6D created at 
> 2016-03-21T00:34:15+0100 using DSA]]
> On Sat, 2016-03-19 at 04:53 +0100, Moritz Klammler wrote:
>> Are you using the latest version of `AX_CXX_COMPILE_STDCXX` [1]?  I
>> think this should have been fixed by Joshua's latest patch [2] which
>> changed the macro to append the `-std=c++14` flag to the `CXX` rather
>> than to the `CXXFLAGS` variable so the pre-processor should now pick 
>> it up as well.
> Hey Moritz. Yes, I am using the latest release from [1].
>> I've tested with the following setup and it seems to work properly 
>> with the latest version.
>>     $ ls
>> m4/
>>     $ cat
>>     AC_PREREQ([2.69])
>>     AC_INIT([example], [1.0], address@hidden)
>>     AC_CONFIG_MACRO_DIR([m4])
>>     AC_PROG_CXX
>>     AC_LANG_PUSH([C++])
>>     AC_CHECK_HEADERS([initializer_list])
>>     AC_LANG_POP([C++])
>>     AC_OUTPUT
>>     $ ls m4/
>>     ax_cxx_compile_stdcxx.m4  ax_cxx_compile_stdcxx_14.m4
>>     $ autoreconf && ./configure
>>     # ...
> I confirm the same results. However, if you add AC_PROG_CXXCPP just
> before the AX_CXX_COMPILE_STDCXX_14 expansion, I see the following:
>     $ ./configure 
>     checking for g++... g++
>     checking whether the C++ compiler works... yes
>     checking for C++ compiler default output file name... a.out
>     checking for suffix of executables... 
>     checking whether we are cross compiling... no
>     checking for suffix of object files... o
>     checking whether we are using the GNU C++ compiler... yes
>     checking whether g++ accepts -g... yes
>     checking how to run the C++ preprocessor... g++ -E
>     checking whether we are using the GNU C++ compiler... (cached) yes
>     checking whether g++ accepts -g... (cached) yes
>     checking whether g++ supports C++14 features by default... no
>     checking whether g++ supports C++14 features with -std=gnu++14... yes
>     checking for grep that handles long lines and -e... /bin/grep
>     checking for egrep... /bin/grep -E
>     checking for ANSI C header files... yes
>     checking for sys/types.h... yes
>     checking for sys/stat.h... yes
>     checking for stdlib.h... yes
>     checking for string.h... yes
>     checking for memory.h... yes
>     checking for strings.h... yes
>     checking for inttypes.h... yes
>     checking for stdint.h... yes
>     checking for unistd.h... yes
>     checking initializer_list usability... yes
>     checking initializer_list presence... no
>     configure: WARNING: initializer_list: accepted by the compiler, rejected 
> by the preprocessor!
>     configure: WARNING: initializer_list: proceeding with the compiler's 
> result
>     checking for initializer_list... yes
>     configure: creating ./config.status
> I hope that helps.


Public Key:
Fingerprint:  2732 DA32 C8D0 EEEC A081  BE9D CF6C 5166 F393 A9C0

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]