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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Reply via email to