[Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7

[Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7

[Romain Naour]

std::strtoll is only supported since C++11.

Fixes:
http://autobuild.buildroot.net/results/cae/cae3cda9be779ea8359f94d13bbbca97e68495ca/

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
---
 package/dawgdic/Config.in | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/package/dawgdic/Config.in b/package/dawgdic/Config.in
index ce0b466..8ef9902 100644
--- a/package/dawgdic/Config.in
+++ b/package/dawgdic/Config.in
@@ -1,6 +1,8 @@
 config BR2_PACKAGE_DAWGDIC
 	bool "dawgdic"
 	depends on BR2_INSTALL_LIBSTDCPP
+	# std=c11
+	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
 	help
 	  dawgdic provides a library for building and accessing
 	  dictionaries implemented with directed acyclic word graphs
@@ -13,5 +15,5 @@ config BR2_PACKAGE_DAWGDIC
 
 	  https://github.com/stil/dawgdic
 
-comment "dawgdic needs a toolchain w/ C++"
-	depends on !BR2_INSTALL_LIBSTDCPP
+comment "dawgdic needs a toolchain w/ C++, gcc >= 4.7"
+	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
-- 
2.4.3

[Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7

[Thomas Petazzoni]

Dear Romain Naour,

On Sat,  8 Aug 2015 11:35:43 +0200, Romain Naour wrote:
> std::strtoll is only supported since C++11.
> 
> Fixes:
> http://autobuild.buildroot.net/results/cae/cae3cda9be779ea8359f94d13bbbca97e68495ca/
> 
> Signed-off-by: Romain Naour <romain.naour@openwide.fr>
> ---
>  package/dawgdic/Config.in | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

Applied, thanks.

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

[Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7

[Nicolas Cavallari]

On 08/08/2015 11:35, Romain Naour wrote:
> std::strtoll is only supported since C++11.
>
> Fixes:
> http://autobuild.buildroot.net/results/cae/cae3cda9be779ea8359f94d13bbbca97e68495ca/
>
> Signed-off-by: Romain Naour <romain.naour@openwide.fr>
> ---
>   package/dawgdic/Config.in | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/package/dawgdic/Config.in b/package/dawgdic/Config.in
> index ce0b466..8ef9902 100644
> --- a/package/dawgdic/Config.in
> +++ b/package/dawgdic/Config.in
> @@ -1,6 +1,8 @@
>   config BR2_PACKAGE_DAWGDIC
>   	bool "dawgdic"
>   	depends on BR2_INSTALL_LIBSTDCPP
> +	# std=c11
> +	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
The string conversion functions also exist in 4.6[1].

However, there is another problem: If an external toolchain is built 
using GCC and uclibc without any additional patches, then you will not 
have them, because of a too-broad feature check in libstdc++ that checks 
if the C library has complete support for C99[2].

This problem is still unresolved even with the latest GCC. buildroot 
patches GCC to fix this, but if an external toolchain does not ...

[1]:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/c_std/cstdlib;h=c3fe8aa4507d51375474c2914fb3e812b3a136e0;hb=632cb4d5f22f598d1395fbae90a10fb679e06054

[2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393

[Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7

[Thomas Petazzoni]

Dear Nicolas Cavallari,

On Sat, 08 Aug 2015 16:53:04 +0200, Nicolas Cavallari wrote:

> > diff --git a/package/dawgdic/Config.in b/package/dawgdic/Config.in
> > index ce0b466..8ef9902 100644
> > --- a/package/dawgdic/Config.in
> > +++ b/package/dawgdic/Config.in
> > @@ -1,6 +1,8 @@
> >   config BR2_PACKAGE_DAWGDIC
> >   	bool "dawgdic"
> >   	depends on BR2_INSTALL_LIBSTDCPP
> > +	# std=c11
> > +	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
> The string conversion functions also exist in 4.6[1].

Indeed. I've committed a fix to enable dawgdic for gcc 4.6:

	http://git.buildroot.net/buildroot/commit/?id=8069253ad178441521e584b02e84be9b88bc85c4

> However, there is another problem: If an external toolchain is built 
> using GCC and uclibc without any additional patches, then you will not 
> have them, because of a too-broad feature check in libstdc++ that checks 
> if the C library has complete support for C99[2].
> 
> This problem is still unresolved even with the latest GCC. buildroot 
> patches GCC to fix this, but if an external toolchain does not ...

We simply can't support all possible uClibc external toolchains. If you
come with an external toolchain that has a uClibc configuration
completely different than the one in Buildroot, then you will get tons
of failures. This is what happened with the pre-built ARC toolchain
from Synopsys, and we ended up disabling it because it was breaking too
many of the Buildroot assumptions on the uClibc configuration.

But indeed, due to this gcc shortcoming, none of the uClibc external
toolchains that are not built with Buildroot can be used. Do we really
want to fix this problem?

Or maybe this means that the idea of using the gcc version was not a
good idea, and we should really have feature-based Config.in options,
like TOOLCHAIN_HAS_STD_STRTOLL.

Thoughts?

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

[Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7

[Romain Naour]

Hi Nicolas,

Le 08/08/2015 16:53, Nicolas Cavallari a ?crit :
> On 08/08/2015 11:35, Romain Naour wrote:
>> std::strtoll is only supported since C++11.
>>
>> Fixes:
>> http://autobuild.buildroot.net/results/cae/cae3cda9be779ea8359f94d13bbbca97e68495ca/
>>
>>
>> Signed-off-by: Romain Naour <romain.naour@openwide.fr>
>> ---
>>   package/dawgdic/Config.in | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/dawgdic/Config.in b/package/dawgdic/Config.in
>> index ce0b466..8ef9902 100644
>> --- a/package/dawgdic/Config.in
>> +++ b/package/dawgdic/Config.in
>> @@ -1,6 +1,8 @@
>>   config BR2_PACKAGE_DAWGDIC
>>       bool "dawgdic"
>>       depends on BR2_INSTALL_LIBSTDCPP
>> +    # std=c11
>> +    depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
> The string conversion functions also exist in 4.6[1].
> 
> However, there is another problem: If an external toolchain is built using GCC
> and uclibc without any additional patches, then you will not have them, because
> of a too-broad feature check in libstdc++ that checks if the C library has
> complete support for C99[2].
> 
> This problem is still unresolved even with the latest GCC. buildroot patches GCC
> to fix this, but if an external toolchain does not ...
> 

Thanks for the report.

I followed the cppreference site:
http://en.cppreference.com/w/cpp/string/byte/strtol (C++11)

Since C++11 start with gcc 4.7, so I haven't looked further...
My bad.

Best regards,
Romain Naour

> [1]:
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/c_std/cstdlib;h=c3fe8aa4507d51375474c2914fb3e812b3a136e0;hb=632cb4d5f22f598d1395fbae90a10fb679e06054
> 
> 
> [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393

[Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7

[Nicolas Cavallari]

On 08/08/2015 17:14, Thomas Petazzoni wrote:
> Dear Nicolas Cavallari,
> 
> On Sat, 08 Aug 2015 16:53:04 +0200, Nicolas Cavallari wrote:
>> However, there is another problem: If an external toolchain is built 
>> using GCC and uclibc without any additional patches, then you will not 
>> have them, because of a too-broad feature check in libstdc++ that checks 
>> if the C library has complete support for C99[2].
>>
>> This problem is still unresolved even with the latest GCC. buildroot 
>> patches GCC to fix this, but if an external toolchain does not ...
> 
> We simply can't support all possible uClibc external toolchains. If you
> come with an external toolchain that has a uClibc configuration
> completely different than the one in Buildroot, then you will get tons
> of failures. This is what happened with the pre-built ARC toolchain
> from Synopsys, and we ended up disabling it because it was breaking too
> many of the Buildroot assumptions on the uClibc configuration.
> 
> But indeed, due to this gcc shortcoming, none of the uClibc external
> toolchains that are not built with Buildroot can be used. Do we really
> want to fix this problem?

I was just pointing out the problem. A possible solution in this case
is to add a patch replacing std::strtoll with strtoll().

> Or maybe this means that the idea of using the gcc version was not a
> good idea, and we should really have feature-based Config.in options,
> like TOOLCHAIN_HAS_STD_STRTOLL.

None of the two solution will fully solves the problem. C++11 support
in GCC 4.6-4.9 is immature.  There are too many unimplemented or buggy
features and regressions to track them with feature-based Config.in
options or even GCC major version ranges, because fixes (and
regressions) are also introduced in minor releases.

The only sane thing to do would be for me to start fighting with the
gcc test suite again and (assuming i succeed,) submit those patches,
then wait for the old gcc versions to phase out.