Cortex A8 support for uclibc

[Yann E. MORIN]

Hector,
All,

On Tuesday 07 April 2009 22:31:07 Hector Oron wrote:
> > I'm all for throwing away this mess as well. As new variants arrive, we'll
> > add more of this stuff. And when one will try to compile with a gcc that
-------------------------------------------------------------^^^^
> > is not recent enough, the -mcpu and -mtune options will not be recognised,
> > and the build will break, and we'll be blamed for that.
> I do not understand very well which build break, what do you 
> understand by variants and stuff?
> "One will try to compile a gcc", here what matters is the one that
> tries to compile uclibc.

I said:  to compile _with_ a gcc
Indeed the compiler that matters is the one building uClibc. :-)

I should have been a bit more clear in my phrasing:
 - if we keep adding new CFLAGS for each new variant that pops up,
 - and if the user building _uClibc_ _with_ a compiler that is too old
   to recognise this variant,
 - then the _uClibc_ build will fail
 - and the user will complain to _us_

[--SNIP--]
> maintaining uClibc to be able to compile on A8, uClibc 
> maintainers have to do an unneeded extra work making sure library is
> compiles which that flavour.

And I agree that, until one such maintainer sees interest in making it
build and maintaining it, the user has to fix it by itself (possibly with
some help from the maintainers, yet).

> I would say, and I am none here, that if 
> you use that flavour, your patches when 'stuff' breaks might be very
> welcome.

Which is a totally different matter from offering the choice to build for
Cortex-A8 (or any other variant of any other architecture, FWIW) in the
uClibc menuconfig.

Of course, if someone builds uClibc for a variant we did not test against,
the build /might/ break. And if that persons wants it to be fixed, he/she
will have to come up with a patch. That a uClibc maintainer sees interest
in this variant is yet another matter...

> Indeed, I think it would be very cool to maintain that flavour, if you
> want a starting point you could start by setting some daily builder
> and make sure it compiles fine everyday, just being in a while
> maintainer loop. Does it makes any sense? :)

Yes. But I think I was not clear enough in my wordings. Does my clarification,
well, clarifies it? ;-)

Oh, by the way, I successfully built a uClibc-0.9.30.1 based toolchain
for a Cortex-A8. The toolchain is configured to spit out code optimised
for this processor by default, so setting "Generic ARM" in the uClibc
menuconfig was perfect.

Just, as Mike points out, this should just be the case every time:
 - don't set the variant in the uClibc config,
 - but rely on the user to correctly setup the C compiler to emit code
   appropriate for the targeted variant by default.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'