In article <f4adc872c7afbe49a9cede5c75191c2734ab6...@dvrmbx02.corp.atmel.com> you write:
>Rarely do one set of modules, compiled with one set of >compiler flags, get linked to another set of modules, compiled with a >different, incompatible set of compiler flags. As Johann already pointed out, avr-libc is compiled with default C flags (i.e. none of those -m or -f options beyond -mmcu is applied). Now, if you look into the Internet, the compile-time options there are full of -f and -m stuff (including, but not limited to, the Mfile template, the WinAVR Makefile template, and Atmel Studio generated code). Consequently, there's a clash between any these object modules, and avr-libc itself. As most projects link against avr-libc, they are always at risk. >If we start including those compiler flags, where does it end? How >many should we include and check for? Only those that affect the ABI. Johann mentioned them. Of course, it would have been nice if people wouldn't have started using these ABI-incompatibility options in the first place, but they do. Yes, I'm partially guilty for spreading them around :) by not thoroughly thinking about what has once been distributed with Mfile. I feel quite sorry for that. We might perhaps concentrate on the more severe of those flags (-mint8 [cough, cough] and -fshort-enums immediately come to mind, as they affect the size of certain objects). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list