Dear Wolfgang,
Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090712161700.GD21651@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