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

Dirk Behme dirk.behme at googlemail.com
Sun Jul 12 21:06:33 CEST 2009


Dear Wolfgang,

Wolfgang Denk wrote:
> 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.

So to do in in positive logic, what do you propose how to enable it? 
In the other mail you mentioned "The selection could be done by 
passing some argument or environment variables to "make""?

Maybe you could give some (Makefile?) (pseudo?) code that 
Jean-Christophe gets an idea how to do this correctly? Sorry if this 
was given already in the Makefile discussion and I missed it.

Many thanks

Dirk




More information about the U-Boot mailing list