[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090712161700.GD21651 at game.jcrosoft.org> you wrote:
>
> > Right. And each of these is supposed to come with it's own version of
> > libgcc, configured exactly for  the  requirements  of  this  specific
> > version and configuration of GCC.
> the problem is that it's not really possible on arm
> because you will need a toolchain for u-boot and an other for the userland
> and in somecase an other for the kernel

You mean it is impossible to build a tool chain for ARM that can be
used to build U-Boot, Linux, and user space code?  I can't believe
that ARM support in GCC is that seriously broken.

> We can not trust at all the libgcc provide by the toolchains we have see this
> kind of problem thousand of times on the kernel and of course in U-Boot
> and it's not the only arch to have this kind of problem the mips have too.

What do you mean?  Are  there  examples  where  the  libgcc  provided
functions  are  incorrect?  But  then  -  isn't the Linux kernel code
drived from the very same set of sources?

The only problems that I have seen in the past is  that  for  example
libgcc   code   assumes  hardware  FP  support  (ironically  even  on
processors that never had a FPU) while U-Boot uses "-msoft-float". In
that case it would be sufficient  if  the  GCC  builders  provided  a
version of libgcc configured for soft-float.

Are you aware of problems that have a different nature, i. e. where
the libgcc provided source code is actually incorrect for some
system?

> I can give 10's of toolchains which are correctly configured but never acheive
> to build u-boot or the kernel just because of the libgcc.

The questionhere is probably how you define "correctly". If these tool
chains are supposed to be used for U-Boot and kenrel development, then
they are probably at least not complete. 

> Btw it will not be a huge work for U-Boot at all as we do this job in the
> kernel anyway

You still have to keep both in sync.

And as I mantioned before: I do not oppose the change itself. I agree
that it is useful and actually a very good idea to support users  who
really  need  this.  The only things I oppose are (1) making this the
default (or even mandatory) for all tool chains  and  (2)  making  it
architecture-dependent.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the beginning, there was nothing, which exploded.
                                - Terry Pratchett, _Lords and Ladies_