RE: [avr-libc-dev] Patches for 1.7.1?

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Per Arnold Blaasmo
> Sent: Friday, March 25, 2011 2:29 AM
> To: address@hidden
> Subject: FW: [avr-libc-dev] Patches for 1.7.1?
> 
> Hi,
> You guys must remember that these patches is the one Atmel currently
> uses in the toolchain built for AVR Studio 5.
> 
> It is not the official avr-libc patches.
> The avr-libc might or might not accept these patches in the future and
> make a new version of avr-libc with these patches. Atmel hope the
> project will want to use them.
> 
> Atmel will always be in front of the community project internally so
> Atmel will probably always have patches to the latest public version.
> 
> Regarding build errors, they should of course not be there. But
> currently the state of the AVR Studio 5 is changing before a public
> release and there might be error.
>
> Putting those patches on the website is an answer to the debate about
> whether waiting until we do a official public release of AVR Studio 5 or
> doing it with each beta release.

Putting Atmel's patches on the website was only required to conform to the 
GPLv3 license. It is required to conform to the GPLv3 license regardless of how 
AVR Studio 5 is labeled. The GPLv3 doesn't care if you call it a "beta" release 
or not. If you convey the executable (object) code to a user, you are required 
to provide the source code. And this was only required for GNU Binutils, GCC, 
and GDB as they are the ones with a GPLv3 license.

Putting patches to other projects on the Atmel website is only a nice 
convenience to the rest of the user community. But if Atmel is going to provide 
such a convenience, then it behooves you to make sure that it actually works.

> Regarding public or non-public devices. Atmel do have some devices that
> needs some basic support and Atmel wants to have that in the toolchain.
> 
> For the non-public parts Atmel need to keep header files and some other
> description files away from public. I am sure you all can understand
> that.

Yes, absolutely. Then don't provide those avr-libc patches in the publicly 
available patch set. That should solve the build error problem.


> avr-libc has made itself dependent on some header file info to be able
> to generate a crt0.o file for each device. I would like that dependency
> to be removed (like other libc project is not dependent on each devices
> header files), so that Atmel can release non-public packages to
> customers that are entitled to that to get support for an non-public
> device without recompiling avr-libc. I hope that can be possible in the
> future.

Probably not. This is the way that is has been working for years. Recompiling 
avr-libc is not that big of a hassle. You have to recompile binutils and gcc 
anyway. I was able to provide private part support for customers without 
requiring any changes.