On Tuesday 08 November 2011 21:53:04 Graeme Russ wrote: > Oops, I meant U-Boot implements a subset of (g)libc. I think I understand > why - U-Boot needs specific implementations of stdio (printf() and friends) > Because we need to implement _some_ of glibc, we need to implement all (or > at least all the functions we use) otherwise we will get all sorts of > symbol conflicts in the linker
glibc assumes an OS. there's no way around that. u-boot doesn't have an OS, so it has never linked against glibc (ignoring the "sandbox" arch). libgcc is a different issue: it rarely (if ever) relies on an OS. it's largely pure math functions, so u-boot has historically used it since things "just worked". the reason for arm getting the private libgcc is because (1) newer versions of libgcc started to rely on the OS (see the whole libgcc-likes-to-call-abort()) and (2) the ABI hell that ARM is currently in -- the hard/soft/vfp/etc..., and little vs big endian. it ends up being pretty hard to get a single sane arm toolchain to build all the u-boot arm targets. for most arches though, these libgcc issues don't come up, so they don't support the private libgcc option. i think wrapping the few bad funcs like coreboot does (i.e. Gabe's patch here) makes sense. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
