[U-Boot] [U-Boot,12/12] lib: Enable private libgcc by default

[Tom Rini]

On Thu, May 26, 2016 at 06:01:47PM +0200, Marek Vasut wrote:

> This patch decouples U-Boot binary from the toolchain on systems where
> private libgcc is available. Instead of pulling in functions provided
> by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
> functions. These functions are usually imported from Linux kernel, which
> also uses it's own libgcc functions instead of the ones provided by the
> toolchain.
> 
> This patch solves a rather common problem. The toolchain can usually
> generate code for many variants of target architecture and often even
> different endianness. The libgcc on the other hand is usually compiled
> for one particular configuration and the functions provided by it may
> or may not be suited for use in U-Boot. This can manifest in two ways,
> either the U-Boot fails to compile altogether and linker will complain
> or, in the much worse case, the resulting U-Boot will build, but will
> misbehave in very subtle and hard to debug ways.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Albert Aribaud <albert.u.boot at aribaud.net>
> Cc: Masahiro Yamada <yamada.masahiro at socionext.com>
> Cc: Simon Glass <sjg at chromium.org>
> Cc: Tom Rini <trini at konsulko.com>
> Reviewed-by: Tom Rini <trini at konsulko.com>

Applied to u-boot/master, thanks!

And since this change was contentious when previously proposed, I'm
going to explain why I'm taking this now.  There are a number of
correctly configured toolchains out there today that fail to build
U-Boot on some platforms.  This is because we're giving the compiler
conflicting requests (build soft-float! use whatever libgcc you have!).
The era of multilib toolchains being prevalent (at least for 32bit ARM)
is long over.  The right thing to have done, always, would be to provide
the required functions ourselves so that we are in control.  So, thanks
again Marek for following up on the series as I had asked you to, this
fixes build failures for me on about a dozen platforms.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160603/fd3ac1fa/attachment.sig>