On Tue, Jan 19, 2010 at 8:59 PM, Stefan Reinauer stepan@openbios.org wrote:
On 1/19/10 8:00 PM, Blue Swirl wrote:
But frankly, the better solution would be to drop our libgcc copy and use that of gcc again... It was a design mistake to let our own copy sneak in.
I disagree. Having our own libgcc makes OpenBIOS independent of any installed libc headers of the host.
libgcc and libc headers have nothing to do with each other. libgcc is part of gcc, and any gcc without libgcc is to be considered an incomplete toolchain.
You can also use target-elf/-eabi cross-compilers, which are easier to build than for example target-linux.
Yes, but if those are built correctly, they still come with libgcc. If they don't, it makes more sense to file a bug report with the toolchain provider than to duplicate parts of the toolchain in openbios.
The problem was with older 3.x (maybe early 4.x) series in cross-compile mode, so bug reports may not help.
At least for Sparc32/64, the administrative burden has not been very big, though I don't know about PPC.
The administrative burden is higher than using a complete toolchain... Who is supplying gcc without libgcc anyways?
Some numbers: there were just 12 commits regarding libgcc since r4 (!) introduced it in 2006, some of them were generic cleanups.
This is the same approach as taken by Linux.
Not a very good argument. libgcc is part of gcc. So there is no reason to duplicate it in any project. This is not some OS dependency like crt0.o but very gcc intrinsic.
If we decide to only support new GCCs, I guess libgcc support could be dropped. Maybe it's OK after all, for example I don't have the buggy 3.x versions of the cross-compilers anymore. With the 4.2.4 version which I'm using, there is a libgcc.a for all target architectures.