On 1/4/2015 12:37 PM, Marc Glisse wrote: > 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? > Yes, sorting out -E shows that some of these .h files are updating only in a newer directory which comes later on the search path than the directory which was used a month ago. So the advice about clean environment includes cleaning out the old installation directories. -- Tim Prince
