[Buildroot] [PATCH] package/cmake: bump version to 3.10.0 and add license hash
Peter Korsgaard
peter at korsgaard.com
Mon Dec 18 22:15:42 UTC 2017
>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at free.fr> writes:
Hi,
> Alternatively, we could also consider bumping our own requirements now,
> requiring a newer base system.
> Yes, that would mean leaving out in the cold people stuck on *very
> ancient* enterprise-class distros (which IMHO would be a bit sad). But I
> would prefer that rather than springling a dependency in all packages...
> Unless we also build our own host toolchain? ;-] Well, probably a host
> C/C++ compiler would be enough to build is needed, until we also need to
> build binutils and a C library and whatnot... This should be avoided if
> at all possible.
Argh, let's not go there! ;)
> emplace_hint() has been added in gcc-4.7 (listed as a defect in 4.6).
> However, some of the build failures are on a machine with gcc-4.7.2;
> http://autobuild.buildroot.org/results/ae8/ae88e2addefab8c7ccefa853c87313034ea241bc/build-end.log
> [--SNIP--]
> -- The C compiler identification is GNU 4.7.2
> -- The CXX compiler identification is GNU 4.7.2
> [--SNIP--]
> cmGlobalNinjaGenerator.cxx:1077:40: error: 'class std::map<const
> cmGeneratorTarget*, std::set<std::basic_string<char> > >' has no member
> named 'emplace_hint'
> But all the failures occur on gcc-20...
> I looke at my autobuilder, and it uses gcc-4.8.2, and cmake builds fine
> with that...
> gcc-4.8 was released in March 2013, which will be almost 5 years ago
> when we tag LTS 2018.02. So maybe we can keep using cmake-3.9 up until
> 2018.02, then update our requirements to require a host gcc >= 4.8m
> which will allow us to bump cmake to 3.10.
> I agree that, with time passing, more and more packages will require
> C++11, so it will make sense to require proper C++11 support for the
> host compiler.
Yes, maybe that is indeed the best way forward - Post 2018.02 that is.
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list