[Buildroot] The C++11 issue

[Buildroot] The C++11 issue

[Thomas Petazzoni]

Hello,

A number of packages start to depend on C++11 features, which are not
available in all toolchains: toolchains using old compiler versions
(such as the Blackfin one), but also some older Crosstool-NG generated
toolchains.

This is causing a number of build failures these days, such as:

        bfin |                  jsoncpp-1.6.0 | NOK | http://autobuild.buildroot.net/results/7fac9e4b3aa0746c860fd032a4b7b8663fb46fc8/
        bfin |                  jsoncpp-1.6.0 | NOK | http://autobuild.buildroot.net/results/20b3f33e61286891a7804352c25326ea9faccfbb/
        bfin |                  jsoncpp-1.6.0 | NOK | http://autobuild.buildroot.net/results/e482ba1d06c7fe2736ab3e79796297db8fbea187/
         arm |                  jsoncpp-1.6.0 | NOK | http://autobuild.buildroot.net/results/1bf20d204042810bedad58dd2466bde9ae7b3fd6/

(std::snprintf is a C++11 feature)

So, it looks like we need to add a BR2_TOOLCHAIN_HAS_CXX11 option, with
the usual handling.

However, it is not very clear-cut what is a C++11 supporting toolchain,
and what is not: C++11 was added progressively in gcc, and there are
still a few things missing apparently. According to
https://gcc.gnu.org/projects/cxx0x.html, most of the compiler related
features have been merged by gcc 4.8. But in terms of libstdc++
support, the page
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x
is a lot less clear, as it only indicates the mainline gcc status, and
not the gcc releases.

So how do we decide whether a particular toolchain has C++11 support ?
Do we simply decide that gcc >= 4.8 have sufficient C++11 support for
now, and we'll adjust things later if needed ?

What do you think ?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] The C++11 issue

[Arnout Vandecappelle]

On 21/03/15 10:28, Thomas Petazzoni wrote:
> Hello,
> 
> A number of packages start to depend on C++11 features, which are not
> available in all toolchains: toolchains using old compiler versions
> (such as the Blackfin one), but also some older Crosstool-NG generated
> toolchains.

[snip]

> So how do we decide whether a particular toolchain has C++11 support ?
> Do we simply decide that gcc >= 4.8 have sufficient C++11 support for
> now, and we'll adjust things later if needed ?

 Given that:

- even gcc 4.9 could still have some missing libstdc++ features;
- C++14 is on the way;
- we only support gcc as a compiler,

I would say that instead of BR2_TOOLCHAIN_HAS_CXX11, we could use
BR2_GCC_AT_LEAST_4_X similar to the headers. That, at least, is unambiguous. It
has the additional advantage that sometimes we may need the version for some
things unrelated to C++, e.g. support for some compiler flags.

 It does require more Config.in symbols, but at the moment 4.8 and 4.9 are
probably sufficient. But then again, adding an additional symbol is not that
much work so I'd include 4.7 as well.


 BTW, now that bfin internal compiler is gone, can we deprecate 4.5?

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] The C++11 issue

[Bernd Kuhls]

Arnout Vandecappelle <arnout@mind.be> wrote in 
news:550D8592.5040300 at mind.be:

>  BTW, now that bfin internal compiler is gone, can we deprecate 4.5?

Hi,

upcoming Kodi 15.0 Isengard fails to compile with BR2_GCC_VERSION_4_5_X on 
BR2_ARCH="x86_64" due to C++11 features being included in Kodi source code. 
Using BR2_GCC_VERSION_4_7_X it works fine however. So I vote for removing 
gcc-4.5.x support from Buildroot.

Regards, Bernd

[Buildroot] The C++11 issue

[Gustavo Zacarias]

On 03/21/2015 11:52 AM, Arnout Vandecappelle wrote:

>  BTW, now that bfin internal compiler is gone, can we deprecate 4.5?

Yes, i'll send a patch shortly to deprecate it, we've already discussed
this with Thomas on IRC.
Regards.

[Buildroot] The C++11 issue

[Romain Naour]

Hi Thomas,

Le 21/03/2015 10:28, Thomas Petazzoni a ?crit :
> Hello,
> 
> A number of packages start to depend on C++11 features, which are not
> available in all toolchains: toolchains using old compiler versions
> (such as the Blackfin one), but also some older Crosstool-NG generated
> toolchains.
> 
> This is causing a number of build failures these days, such as:
> 
>         bfin |                  jsoncpp-1.6.0 | NOK | http://autobuild.buildroot.net/results/7fac9e4b3aa0746c860fd032a4b7b8663fb46fc8/
>         bfin |                  jsoncpp-1.6.0 | NOK | http://autobuild.buildroot.net/results/20b3f33e61286891a7804352c25326ea9faccfbb/
>         bfin |                  jsoncpp-1.6.0 | NOK | http://autobuild.buildroot.net/results/e482ba1d06c7fe2736ab3e79796297db8fbea187/
>          arm |                  jsoncpp-1.6.0 | NOK | http://autobuild.buildroot.net/results/1bf20d204042810bedad58dd2466bde9ae7b3fd6/
> 
> (std::snprintf is a C++11 feature)
> 
> So, it looks like we need to add a BR2_TOOLCHAIN_HAS_CXX11 option, with
> the usual handling.
> 
> However, it is not very clear-cut what is a C++11 supporting toolchain,
> and what is not: C++11 was added progressively in gcc, and there are
> still a few things missing apparently. According to
> https://gcc.gnu.org/projects/cxx0x.html, most of the compiler related
> features have been merged by gcc 4.8. But in terms of libstdc++
> support, the page
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x
> is a lot less clear, as it only indicates the mainline gcc status, and
> not the gcc releases.
> 
> So how do we decide whether a particular toolchain has C++11 support ?
> Do we simply decide that gcc >= 4.8 have sufficient C++11 support for
> now, and we'll adjust things later if needed ?
> 
> What do you think ?

Some host packages start to require c++11 too, like host-thrift.

http://autobuild.buildroot.net/?reason=host-thrift-0.9.2

(similar issue with target's thrift)
http://autobuild.buildroot.net/results/633/63340efff9adae966ec1d74ebc123d0437b75b63/build-end.log

In the case of host-thrift, the check for C++11 is horribly broken since there
is *sometime* some garbage in ax_cxx_compile_cxx11_required variable.

I can't reproduce the host-thrift issue on my Debian6 VM which use a gcc 4.4
because of that.

The custom m4 macro AX_CXX_COMPILE_STDCXX_11 used in configure.ac would stop the
build if no C++11 support is available:

AX_CXX_COMPILE_STDCXX_11([noext])

But if you look at the configure script generated by autoreconf,
ax_cxx_compile_cxx11_required is initialized with "truednl" !

ax_cxx_compile_cxx11_required=truednl

Then the build system fall back in C++11 optional requirement mode and finishes
the build...

All that to say that we might need also a check for C++11 for the host.

Otherwise, I like Arnout's proposal about BR2_GCC_AT_LEAST_4_X symbols.

Best regards,
Romain

> 
> Thomas
>