[U-Boot] [patch 1/1] Remove linking to libgcc while compiling U-boot

[Wolfgang Denk <wd@denx.de>]

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 at 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.

> 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: wd at denx.de
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