Dear Remy, In message <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]/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. > http://lists.denx.de/pipermail/u-boot/2007-July/022881.html 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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Computers make excellent and efficient servants, but I have no wish to serve under them. Captain, a starship also runs on loyalty to one man. And nothing can replace it or him. -- Spock, "The Ultimate Computer", stardate 4729.4 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
