[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Daniel Schwierzeck <daniel.schwierzeck@gmail.com>]

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.

-- 
- Daniel