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

[Michael Zimmermann]

> 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.

I agree with this change but is this even true? my toolchain(linaro) has 28
different versions of libgcc.a

Thanks
Michael

On Mon, Jun 6, 2016 at 7:35 PM, Simon Glass <sjg at chromium.org> wrote:

> On 4 June 2016 at 02:00, Tom Rini <trini at konsulko.com> wrote:
> > 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.
>
> Thank you Marek!
>
> - Simon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>