From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Date: Thu, 2 Jul 2015 07:49:21 +0200 [thread overview]
Message-ID: <20150702074921.7f9bc12c@lilith> (raw)
In-Reply-To: <55947A25.5020702@gmail.com>
Hello Daniel,
(not sure how in my previous reply I managed to drop Masahiro off the
discussion; fixing that, and apologies)
On Thu, 02 Jul 2015 01:39:17 +0200, Daniel Schwierzeck
<daniel.schwierzeck@gmail.com> wrote:
>
>
> Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
> > Hello Wolfgang,
> >
> > On Wed, 01 Jul 2015 23:50:17 +0200, Wolfgang Denk <wd@denx.de> wrote:
> >
> >> Actually I think it is inherently wrong to enable
> >> CONFIG_USE_PRIVATE_LIBGCC by default.
> >>
> >> This option is intended as a workaround for broken toolchains, until
> >> these get fixed. By enabling this by default, we miss do not notice
> >> the problems our tool chain has, and therefore these never get fixed,
> >> i. e. brokenness grows. This cannot be good.
> >>
> >> CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
> >> never ever a default setting.
> >
> > Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
> > enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
> > we allow it by default for all architectures, or we forbid it by
> > default for all architectures, but I don't like the idea of a
> > heterogeneous per-arch default setting.
> >
>
> CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports
> a private libgcc, then it should always use it. I think for U-Boot it is
> better and safer to have all code under control instead of pulling in
> external code from toolchains which are often somehow broken.
>
> Speaking for MIPS we have boards with all combinations of Big
> Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc
> binary for each FPU variant, but almost no toolchain supports this. Thus
> you need different toolchains for different boards. This is a PITA for
> users or developers who want to use buildman. Always using
> CONFIG_USE_PRIVATE_LIBGCC=yes was the only painless way so far. That is
> why we chose to enable CONFIG_USE_PRIVATE_LIBGCC by default.
>
> BTW: Linux kernel or Barebox always use a private libgcc.
Seems like there is room for debate on the topic, then, which I'll
start in another topic.
From a short-term perspective, I will defer the present patch because
applying it makes U-Boot support fifteen less targets than not applying
it, which I think we can agree goes in the cons list of both approaches.
> --
> - Daniel
Amicalement,
--
Albert.
next prev parent reply other threads:[~2015-07-02 5:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 12:37 [U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default Masahiro Yamada
2015-04-16 9:21 ` Albert ARIBAUD
2015-07-01 21:21 ` Albert ARIBAUD
2015-07-01 21:40 ` Albert ARIBAUD
2015-07-02 12:21 ` Masahiro Yamada
2015-07-02 12:43 ` Albert ARIBAUD
2015-07-02 12:54 ` Masahiro Yamada
2015-07-02 13:03 ` Albert ARIBAUD
2015-07-01 21:42 ` [U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address) Albert ARIBAUD
2015-07-01 21:50 ` Wolfgang Denk
2015-07-01 22:04 ` Albert ARIBAUD
2015-07-01 23:39 ` Daniel Schwierzeck
2015-07-02 5:49 ` Albert ARIBAUD [this message]
2015-07-02 7:39 ` Wolfgang Denk
2015-07-02 12:40 ` Masahiro Yamada
2015-07-03 9:53 ` Wolfgang Denk
2015-07-02 12:46 ` Daniel Schwierzeck
2015-07-03 9:59 ` Wolfgang Denk
2015-07-02 12:18 ` Masahiro Yamada
2015-07-02 12:29 ` Masahiro Yamada
2015-07-03 9:29 ` Wolfgang Denk
2015-07-02 7:34 ` Wolfgang Denk
2015-07-02 12:12 ` Masahiro Yamada
2015-07-03 9:25 ` Wolfgang Denk
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=20150702074921.7f9bc12c@lilith \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/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