This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Split up toplevel library-disabling cases
- From: Joerg Wunsch <j at uriah dot heep dot sax dot de>
- To: "Weddington, Eric" <Eric dot Weddington at atmel dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, bonzini at gnu dot org, dj at redhat dot com, neroden at gcc dot gnu dot org, aoliva at redhat dot com, Ralf dot Wildenhues at gmx dot de, chertykov at gmail dot com, aesok at post dot ru, dje dot gcc at gmail dot com, eager at eagercon dot com
- Date: Fri, 1 Apr 2011 08:14:29 +0200
- Subject: Re: Split up toplevel library-disabling cases
- References: <Pine.LNX.4.64.1103292045250.2595@digraph.polyomino.org.uk> <Pine.LNX.4.64.1103312337050.14316@digraph.polyomino.org.uk> <8D64F155F1C88743BFDC71288E8E2DA8011BAF7D@csomb01.corp.atmel.com>
- Reply-to: Joerg Wunsch <joerg_wunsch at uriah dot heep dot sax dot de>
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. ;-)