> -----Original Message----- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: Thursday, March 31, 2011 5:41 PM > To: gcc-patches@gcc.gnu.org > Cc: bonz...@gnu.org; d...@redhat.com; nero...@gcc.gnu.org; > aol...@redhat.com; ralf.wildenh...@gmx.de; cherty...@gmail.com; > ae...@post.ru; Weddington, Eric; dje....@gmail.com; ea...@eagercon.com > Subject: Split up toplevel library-disabling cases > > 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?). Note that changing libstdc++-v3/acinclude.m4 to build > only freestanding libraries for a target may be an alternative to > disabling libstdc++-v3 completely for that system. If the libraries > don't need disabling, they shouldn't be disabled, to keep down the > amount of ad hoc tests for particular targets at toplevel. If they do > need disabling, there should be comments to explain why.
Hi Joseph, 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. I don't recall anyone seriously looked into it. 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. It's been on our todo list for years to try and solve the build issues, but, as usual, it's a time and resource issue. Bottom line is that we would eventually like to get these two build issues fixed. However, we don't even have bug reports opened up for these issues. Eric Weddington
