On Tuesday 07 April 2009 14:29:06 Yann E. MORIN wrote: > On Tuesday 07 April 2009 08:55:25 Mike Frysinger wrote: > > On Tuesday 07 April 2009 01:26:33 Sagar Borikar wrote: > > > Just wanted to check whether cortex A8 (ARM) is supported in uClibc? > > > > uClibc doesnt care what ARM variant you're using. it does have optional > > support for things like EABI/thumb/interwork, but that's a different > > question. > > So why is there that choice when ARM is selected? > <snip> > And each of the choices above are turned into a specific selection of > compiler options.
if you already know the answer, why are you asking ? > Of course the processor variant we're building uClibc to run on matters! that's the decision of the compiler and/or user, not uClibc. building uClibc with a different CFLAG certainly does not mean "uClibc supports XXX cpu". thus it does not care what processor *you're* compiling it for. > Please find attached a patch to add basic (and untested!) support for > Cortex-A8, just for the sake of having a starting point. Unless I'm > mistaken, that's all there is to it... > I'll try to test this in the evening (GMT+2) or tomorrow... > > Also note that most other architectures also have a variant selection: > cris, h8300, i386, mips, powerpc, superh, sh64 (which has only one variant > available, but the menu is here), sparc. i dont think we should keep enabling lazy people. either the right options are selected by gcc in their toolchain, or they should manually add the -mcpu or whatever flags to their extra cflags. extending this crap in our build system is a waste of time. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc