On Fri, 11 Mar 2022 at 15:35, Detlef Vollmann wrote: > > On 3/11/22 16:12, Jonathan Wakely wrote: > > On Fri, 11 Mar 2022 at 14:28, Detlef Vollmann wrote: > >> With this and the other fix I was able to build the complete > >> libstdc++ for AVR based on AVR Libc 2.0 (plus some ad hoc > >> AVR header fixes) from git master 5e28be89. > > > > Nice. I finally figure out that I need to use --enable-libstdcxx *not* > > --enable-libstdc++-v3 to build for AVR, > Yes, I had the same problem. > A comment in the 'configure' script still says libstdc++-v3
Yes, I have a patch to fix that. > and in the configure docs at > <https://gcc.gnu.org/install/configure.html> > or > <https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html> > there's neither :-( > > > and now I get errors due to > > EOVERFLOW being undefined. Is that what you fixed? > One of them. > > > We should make that work. Arguably, all values of std::errc should > > exist, even if the OS <errno.h> doesn't provide a constant. We could > > define the missing ones ourselves, choosing numbers > 1000 (and hope > > the OS uses small numbers for its own errno values). > I simply defined all that were required. > > I've attached a tarball with all my header fixes. Thanks. Now I'm getting a build failure because libtol wasn't created in the avr/libstdc++-v3 directory of the build tree, but I'll have to look into that next week. /bin/sh: ../libtool: No such file or directory > To get them picked up while compiling libstdc++ I had to > put them into ${prefix}/avr/lib/include. > > But these are really ad hoc, some of the problems I think should > be fixed in the libstdc++ sources. > E.g. I think it's wrong to expect that specific functions are > available if a respective header is available (e.g. close() > in unistd.h). Yes, that was me being lazy.
