As Weddington, Eric wrote: > > Target maintainers: I'd like to understand why it is necessary to > > disable libssp for AVR, AIX and Microblaze, and libstdc++-v3 for AVR > > (and what use C++ is on AVR without libstdc++-v3 - do you use another > > C++ library?). [...]
> Regarding the AVR port, AFAIK, it's just historical. At one point > libssp didn't build for the avr, and we ended up just disabling it > so users could build out of the box. IIRC, the entire SSP feature wants to write to a file, so it obviously requires full stdio file support, including fopen() and fclose(). As the AVR port does not imply any kind of operating system (the library is just "bare metal", sitting on top of the CPU with no assumptions about the controller's peripherals whatsoever), there is no file system support in avr-libc. > Yes, we can an do build the c++ compiler for the avr target, and we > do have users using it (with an increasing number of c++ > users). Again, AFAIK, libstc++-v3 has never been able to be built > for the avr target, and no, we are not using another c++ library. Last time I've been looking into it (which has been many years ago), it somehow broke when compiling exception support, supposedly lacking some kind of target-specific default exception handling implementation. That could probably be done though. I simply stopped then when realizing that a "Hello world!" with (faked) exception support ended up with approximately 30 KiB of code, which was about a quarter of the flash ROM size of the biggest AVR microcontroller available by that time ;-), assuming nobody in AVR-land would really want to use exceptions under those circumstances anyway. It's possibler there's another couple of minor stumbling blocks here as well, though I think it's nothing impossible to fix. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
