> However, there is a version 3.4.5 release of the Atmel sources which > we should upgrade to. It's still based on gcc 4.8.1 though.
Yes, I tried to build avr-libc 1.8.1 with that first, but it doesn't contain some vital patches that are in gcc 4.9.1. Those patches actually come from Atmel employees, thus my argument for switching to vanilla gcc instead of waiting for an official Atmel release. > whoever of the two that are most "out of date" varies from time to > time and from feature to feature. I guess it depends on where in their > release cycle they are and how hard a time Atmel is having to get > their patches accepted upstream. Also, there seems to be some patches > in binutils that avr-develoopers depend on, that will never be > accepted upstream (for whatever reason). Also, when using the Atmel > release we get a full toolchain (gcc, binutils and libc) well tested > to work for avr develoopment. In this this case I'd argue that the "best" course of action would be to offer two packages: One that is based on the same sources as the rest of the binutils/gcc packages in Debian (plus vanilla avr-libc), and one that builds from Atmel toolchain sources. However, I understand that this would lead to some confusion for users and also meant additional work. On a different note, I do think that debian/rules should be improved a bit. It lacks quilt support (patches are hand-applied) and the whole build process is bit hackish. When I built my custom gcc-avr and avr-libc packages, I had to fix paths and patches manually. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
