[avr-libc-dev] Re: Revised release criteria for GCC 4.0

[Bernardo Innocenti]

Ralf Corsepius wrote:
> On Thu, 2004-12-16 at 23:01 +0100, Bernardo Innocenti wrote:

> > uClibc only works on top of Linux kernels, it's not autoconf
> > based. glibc supports both Linux and Hurd, and it also used to
> > support Solaris.  Windows targets use either MSVCRT (non-free)
> > or cygwin (is it a full libc?).
>
> Cygwin and RTEMS both are based on newlib.
>
> Their "actual libc" is split into several libs which together form
> "libc". One of whose libs is newlib, while the others are provided by
> the OS.

Maybe the same technique could be used to build a
comprehensive avr-libc by combining newlib with
additional CPU-specific functions?


> > We don't actually need to import sources in our repository.
> > Just add the required rules in the top-level configure.in
> > and Makefile.in.
>
> Several years ago (ca. when egcs was current), we had considered the
> same step, because the split between newlib, gcc and libc-
> functionalities in RTEMS causes a permanent struggle with all three of
> them.
>
> However, we have given in this undertaking.

The top-level configure.in and Makefile.in are soon going to be
rewritten to switch to the latest versions of the auto-tools.

This could be a good time to discuss with the maintainer
about adding hooks to build an external libc?

avr-libc would be easy to integrate.  uClibc would be harder
as it's not autoconfiscated (it's baded on the kbuild
infrastructure of the Linux kernel).



> > This stuff is very specific to the AVR architecture and
> > I doubt the newlib maintainers would want to maintain them
> > in their tree.
>
> Exactly. Also, there isn't a need to do so, because tasks are strictly
> separated between newlib and RTEMS (rsp. libgloss for bare targets).
>
> In general, newlib only provides the libc infrastructure without much
> customization for a particular CPU. 
>
> RTEMS (rsp. libgloss) can provide such customizations (headers with
> registers defines etc.) and also has to provide a certain set of
> specialized headers/functions for a particular target.

I like this way.  Maybe it could be used to build the avr target too.


> I.e. RTEMS probably will adopt parts of avr-libc, and probably also will
> probably propose to adopt parts of avr-libc into newlib, if avr-libc's
> licensing and ABI permits it. Typical candidates for such kind of
> adoptation into newlib would be memcpy etc. and asm-written libm
> implementations. I already talked to some avr-libc maintainer (IIRC, it
> was Eric Weddington) and he was not opposed to it.

The licenses appear to be compatible.  In another thread,
Eric Weddington said he'd be willing to work together if
it was possible to get CVS write access for the avr-libc
developers and a reasonable commit policy.


> > But libgloss is not being excluded for the avr-* target,
> > and it breaks the build.
>
> That's true. newlib doesn't support bare avr-* targets, but newlib
> supports avr-rtems*.

In yet another thread, Paul Schlie found out that libgloss
builds fine once the target macros to specify type sizes are
properly fixed up.  There's some confusion in the AVR backend
to work around the assumption sizeof(int) == sizeof(cpu register).

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/