package/dawgdic: needs gcc >= 4.7
PATCH 1/1 package/dawgdic: needs gcc >= 4.7
std::strtoll is only supported since C++11.
Fixes:
http://autobuild.buildroot.net/results/cae/cae3cda9be779ea8359f94d13bbbca97e68495ca/
--- package/dawgdic/Config.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
package/dawgdic/Config.in +4 -2
@@ -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
Signature · 1 line
2.4.3
Thomas Petazzoni
AppliedPATCH 1/1 package/dawgdic: needs gcc >= 4.7
Dear Romain Naour,
Quoted 9 lines · Romain Naour
std::strtollis only supported since C++11.Fixes:
http://autobuild.buildroot.net/results/cae/cae3cda9be779ea8359f94d13bbbca97e68495ca/Signed-off-by Romain Naour <[email protected]>--- package/dawgdic/Config.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Applied, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/dawgdic: needs gcc >= 4.7
In reply to Romain NaourQuoted 15 lines · Romain Naour
std::strtollis only supported since C++11.Fixes:
http://autobuild.buildroot.net/results/cae/cae3cda9be779ea8359f94d13bbbca97e68495ca/Signed-off-by Romain Naour <[email protected]>--- package/dawgdic/Config.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)package/dawgdic/Config.in +0
-0
package/dawgdic/Config.in line 5
Quoted 5 lines
package/dawgdic/Config.in +2
-0@@ -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 ...
PATCH 1/1 package/dawgdic: needs gcc >= 4.7
Dear Nicolas Cavallari,
Quoted 11 lines · Nicolas Cavallari
package/dawgdic/Config.in line 5
Quoted 10 lines
package/dawgdic/Config.in +2
-0@@ -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_7The 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
Quoted 7 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/dawgdic: needs gcc >= 4.7
Quoted 18 lines · Thomas Petazzoni
Dear Nicolas Cavallari,
Quoted 7 lines · Nicolas Cavallari
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.
Quoted 3 lines
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().
Quoted 3 lines
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.
PATCH 1/1 package/dawgdic: needs gcc >= 4.7
In reply to Nicolas CavallariHi Nicolas,
Le 08/08/2015 16:53, Nicolas Cavallari a ?crit :
Quoted 24 lines · Romain Naour
Quoted 16 lines
std::strtollis only supported since C++11.Fixes:
http://autobuild.buildroot.net/results/cae/cae3cda9be779ea8359f94d13bbbca97e68495ca/Signed-off-by Romain Naour <[email protected]>--- package/dawgdic/Config.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)package/dawgdic/Config.in +0
-0package/dawgdic/Config.in line 5
Quoted 5 lines
package/dawgdic/Config.in +2
-0@@ -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_7The string conversion functions also exist in 4.6[1].
Quoted 8 lines
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