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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.