Follow-up Comment #6, patch #8587 (project avr-libc): > For backward compatibility with older compiler versions: > avr-libc build mechanism can detect gcc version and > configure either old libs or libdev.a. Is this option ok?
Yes, I was already about to suggest this. Without such an option, by our own standards[*], we'd have to bump the major version number due to a change in the API. In consequence, this would also mean to maintain an SVN branch for the old revision line for some time, and to merge all important bug fixes from trunk to the branch. We used to do this in the past, but it's quite a bit of work. [*] http://www.nongnu.org/avr-libc/user-manual/release_method.html However, if the autoconf stuff can detect whether the compiler used supports automatic libdev.a inclusion or not, and the build adapts to it, the change is going to be smooth enough so anyone compiling a toolchain (e.g. Linux distribution maintainers) will get a consistent toolchain without breaking the user interface. To get me right: I'm not opposed to the change as such, I've never been really happy with the way the EEPROM functions have been done so far. This was just a stop-gap measure introduced by its time to work around other problems, while libdev.a + an appropriate compiler modification is certainly much more elegant. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/patch/?8587> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
