2015-07-02 16:39 GMT+09:00 Wolfgang Denk wd@denx.de:
Dear Daniel,
In message 55947A25.5020702@gmail.com you wrote:
CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports a private libgcc, then it should always use it. I think for U-Boot it is better and safer to have all code under control instead of pulling in external code from toolchains which are often somehow broken.
This is the wrong approach. If a tool is broken, it should be reported, and fixed.
Speaking for MIPS we have boards with all combinations of Big Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc binary for each FPU variant, but almost no toolchain supports this. Thus
Why would that be the case? We do not use any floating point stuff in U-Boot...
I agree that there is the endianess issue - MIPS is currently the only architecture (I am aware of) that supports both BE and LE con- figurations. But this is a tool chain issue! You will need support from the tool chain not only for U-Boot (and the kernel), but also for user space. If your tool chain is nbroken, it needs fixing.
BTW: Linux kernel or Barebox always use a private libgcc.
And what do you do about user space with such a broken tool chain?
It does not help to paper over problems.
Some people might want to build only U-boot from source code and install a pre-built distribution, maybe ?