[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