Dear Remy,
In message 20081031224856.847997187@bohmer.net you wrote:
Currently U-boot is linking against libgcc. This should not be needed because
And where would the GCC compiler gets its builtin functions from, then?
the compiler toolchain is usually compiled with a certain OS interface in mind, and can even be configured for GNU-EABI interfaces.
The toolchain is not OS dependent. It implements a cetrain ABI. And libgcc provides the needed support functions.
This can cause linking conflicts in U-boot when linking to libgcc.
I have an idea what you mean, but as stated here it's wrong.
It usually becomes really visible that these conflicts are there when some piece of code requires an external routine that is not available in U-boot itself.
This must never happen. U-Boot is supposed to be self-contained, except for any compiler-speeific functions which are provided by the compiler itself - in libgcc.a (assuming you use GCC).
Such an unresolved external are finally searched in the libgcc library, because U-boot is told to link against. If the compiler happened to be a EABI compiler, linking will definately fail. These are not a compiler problems, but U-boot problems, because
No, it will not, unless it is misconfigured.
U-boot needs to keep its own pants up (It is not linking to any OS, it is standalone)
Correct. But we cannot know what the compiler may need or provide.
If the compiler is _not_ a EABI compiler toolchain, linking might succeed, but its behaviour will be undefined, because it is unknown what the external dependencies of such libraries will be. (syscalls required?)
Huch? I cannot make any sense of this.
While looking at compiler includes, the only header used from GCC (I have seen) seems to be the stdarg.h header, which is even doubtful to include in U-boot, because of the same reasons not to link against libgcc. This patch only removes the linking part to libgcc.
Oops? How would you implement support for variable number of arguments then, when you remove the only standard way to do it?
I tested it on several ARM boards, and linking still works fine...
And, do they also run fine?
Several older mailthreads that show similar issues (just a simple grep): http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg03176.html
I think the code would not run (because it uses an incompatible [with the compiler used] ABI version) if you omitted linking against libgcc here.
http://lists.denx.de/pipermail/u-boot/2008-August/039526.html
Different problem, has nothing to do with linking against libgcc per se.
Has nothing to do with libgcc.a
Your patch will break a lot of PPC boards, for example:
Configuring for BC3450 board... post/libpost.a(post.o): In function `post_time_ms': /work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3' make: *** [u-boot] Error 1
Configuring for cm5200 board... post/libpost.a(post.o): In function `post_time_ms': /work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3' make: *** [u-boot] Error 1
Configuring for fo300 board... post/libpost.a(post.o): In function `post_time_ms': /work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'
Configuring for TB5200 board... post/libpost.a(post.o): In function `post_time_ms': /work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'
Configuring for TQM5200 board... post/libpost.a(post.o): In function `post_time_ms': /work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3' make: *** [u-boot] Error 1
Configuring for TQM5200_B board... post/libpost.a(post.o): In function `post_time_ms': /work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3' make: *** [u-boot] Error 1
Configuring for TQM5200S board... post/libpost.a(post.o): In function `post_time_ms': /work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3' make: *** [u-boot] Error 1
and so on.
NAK.
Best regards,
Wolfgang Denk