Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7
Date: Sat, 8 Aug 2015 17:14:28 +0200	[thread overview]
Message-ID: <20150808171428.68f11d28@free-electrons.com> (raw)
In-Reply-To: <55C617D0.3050800@green-communications.fr>

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

  reply	other threads:[~2015-08-08 15:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-08  9:35 [Buildroot] [PATCH] package/dawgdic: needs gcc >= 4.7 Romain Naour
2015-08-08 10:06 ` Thomas Petazzoni
2015-08-08 14:53 ` Nicolas Cavallari
2015-08-08 15:14   ` Thomas Petazzoni [this message]
2015-08-11  9:04     ` Nicolas Cavallari
2015-08-08 16:55   ` Romain Naour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150808171428.68f11d28@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox