avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated


From: Weddington, Eric
Subject: Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated
Date: Thu, 16 Aug 2012 21:16:16 +0000


> -----Original Message-----
> From: David Brown [mailto:address@hidden
> Sent: Wednesday, August 15, 2012 1:04 AM
> To: Weddington, Eric
> Cc: John Voltz; address@hidden
> Subject: Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated
> 
> On 14/08/2012 22:50, Weddington, Eric wrote:
> >
> > Ah, ok.
> >
> > That package contains *patches* to the indicated released versions.
> > Since the avr-libc and avr-gdb subdirectories are empty, that means
> > that there were no patches to the released versions that was used in
> > building the AVR Toolchain.
> >
> > We're working right now to correct that for the next (upcoming)
> > release of AVR Toolchain to make sure that we also offer the full
> > modified source in addition to the patches.
> >
> 
> Will you keep the patches clearly available as well? 

Yes, I said above that we working to provide both.

> Incidentally, is there a source of the patches other than via Atmel's
> website and the toolchain downloads?  It doesn't hinder me unduly that
> you have to fill in a form to register for each download (though it
> irritates me immensely), but I can imagine that some people disapprove
> of it.  I would expect that people making packages for Debian, for
> example, would be uncomfortable with the idea.  Is there any sort of
> publicly available website showing the current list of patches, or an
> overview of what they are?  (This is just out of curiosity on my part.)

We're working on that part, too. Stay tuned. ;-)

 
> Of course, the ideal situation is that there are no patches - but gcc
> development does not tend to work like that!

And it's unrealistic. New devices are always coming out, and support for those 
devices has to be added, and it doesn't always match the release cycles of GCC 
and of toolchain distributions. There's just too many tools and projects 
involved, each with their own release cycle.

Eric



reply via email to

[Prev in Thread] Current Thread [Next in Thread]