On Saturday 20 June 2009 09:57:51 Jean-Christophe PLAGNIOL-VILLARD wrote: > On 09:33 Sat 20 Jun , Mike Frysinger wrote: > > On Saturday 20 June 2009 09:01:36 Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On 08:57 Sat 20 Jun , Mike Frysinger wrote: > > > > On Saturday 20 June 2009 07:30:41 Jean-Christophe wrote: > > > > > On 07:08 Sat 20 Jun , Mike Frysinger wrote: > > > > > > On Saturday 20 June 2009 06:40:07 Jean-Christophe wrote: > > > > > > > On 06:18 Sat 20 Jun , Mike Frysinger wrote: > > > > > > > > On Saturday 20 June 2009 05:33:26 Jean-Christophe wrote: > > > > > > > > > This patch moves the libgcc Makefile inclusion from the > > > > > > > > > toplevel Makefile to the arch_config.mk files. This is in > > > > > > > > > preparation for the ARM architecture to move away from > > > > > > > > > including libgcc function and only using self-contained > > > > > > > > > U-Boot functions as done in Linux. > > > > > > > > > > > > > > > > why not change the top level Makefile to read: > > > > > > > > PLATFORM_LIBGCC ?= ... > > > > > > > > > > > > > > > > then any board/arch that doesnt want it can simply do: > > > > > > > > PLATFORM_LIBGCC = # dont want it > > > > > > > > > > > > > > because you need to provide the equivalent functions for > > > > > > > standalone application and api and U-Boot ofcourse > > > > > > > > > > > > so move it to config.mk. this doesnt change the important point: > > > > > > leave PLATFORM_LIBGCC default in the toplevel common files. what > > > > > > i proposed doesnt limit what you want to do with arm in any way. > > > > > > > > > > I think it's better to let it at arch level and force any new arch > > > > > adding to manage it instead provide a default one > > > > > > > > considering most arches want this code, i dont think so. you're > > > > proposing we duplicate the same common code in all arches to support > > > > one deviating arch -- arm. the defaults should reflect the common > > > > state while the deviating ones change the behavior as they like. > > > > > > This is where I disagree other arch as mips and other will also need to > > > move away from the needs to include libgcc to be really toolchain > > > independant > > > > > > I do think it's really important for U-Boot be able to have full > > > control to have a functions embedded into. > > > > > > So stop to have libgcc include by default will really reflect it > > > > so you have two arches (mips/arm) that you dont want to use libgcc. that > > is still vastly the minority. if we ever do get most ports not using > > libgcc, then pushing it to the arch configs makes sense. but we havent > > and we arent even close. > > which minoroty?
the majority use libgcc > I just give you example but you will see arm, mips, sh, powerpc etc... > toolchains problem just because we use the libgcc 4 is still the minority, but this is Woflgang's call > I've patch in qualification for mips and sh so it will not be so long > maybe 2 or 3 weeks considering my proposed change is much simpler, and would allow for trivial migration as you converted things, it still makes more sense. > > how you want to manage libgcc dependency is your prerogative ... it > > doesnt mean you should be forcing other people to follow suit. > > you can do your own choice but I steel think it's a good improvement it depends on the arch. for ones doing stupid things (like arm), thats one thing. but for others, it's simply a waste of time and unnecessary overhead. i'm not about to *copy* the exact sources from gcc just to avoid -lgcc. -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