_GLIBCXX14_CONSTEXPR

Marc Glisse marc.glisse@inria.fr
Sun Jan 4 17:38:00 GMT 2015


On Sun, 4 Jan 2015, Tim Prince wrote:

> On 1/4/2015 7:42 AM, Jonathan Wakely wrote:
>> On 4 January 2015 at 09:26, Marc Glisse wrote:
>>> On Sat, 3 Jan 2015, Tim Prince wrote:
>>>
>>>> What is this new feature which breaks stl_algo.h  ?
>>>>
>>>> g++   -c loopstl.cpp
>>>>
>>>> In file included from /usr/local/gcc5.0/include/c++/5.0.0/functional:49:0,
>>>>                 from loopstl.cpp:17:
>>>> /usr/local/gcc5.0/include/c++/5.0.0/bits/stl_function.h:169:7: error:
>>>> ‘_GLIBCXX14_CONSTEXPR’ does not name a type
>>>>       _GLIBCXX14_CONSTEXPR
>>>>       ^
>>>>
>>>> I'm trying to use std::max_element et al in the old way which has worked
>>>> for years, and was still working in g++ 5.0 build of Dec. 18.
>>>
>>> The first thing <functional> and most headers do is include bits/c++config.h
>>> which defines _GLIBCXX14_CONSTEXPR as empty. Could you check that the right
>>> version of c++config.h does indeed get included?
>> If it's not defined it means you built and/or installed GCC wrong.
>>
>> A fresh build in an empty directory should solve it, and might be
>> simpler than figuring out what you did wrong.
> Fresh build makes no difference.  How should "right version of"
> c++config.h become included?  The one placed in the installation
> directory has the conditional definitions of
>
> _GLIBCXX14_CONSTEXPR
> but even if that path is added to the build by -I it has no effect.

Did you compile with -E and check what files were included? Do you have a 
clean environment?

-- 
Marc Glisse



More information about the Gcc-help mailing list