On Sun, Sep 2, 2018 at 11:00 PM Jonathan Wakely <jwak...@redhat.com> wrote: > > On 02/09/18 22:18 +0300, Adrian Stratulat wrote: > >Hello, > > > >II tried compiling avr-gcc (AVR 8-bit target) with libstdcxx support, > >and even if I set the configure parameters to be "disable-shared" and > >"enable-static", the "configure" step fails because it checks for > >dlopen() support in avrlibc (which doesn't exist). > > Why has nobody noticed this problem before? You're not the first > person to build avr-gcc. Does nobody else build libstdc++ for AVR?
Libstdc++ support for avr-gcc was added in 2016 [1] and wasn't used widely, as the avr-libc project considers libstdc++ to be unsupported [2]. When the initial developer tried to get the library added to the ArchLinux package system, the package maintainer hit the same error I was seeing [3]. Also, it seems that this corner-case of the config causes problems from time to time, on embedded/non-mainstream platforms ([4], [5]). > >I see that in the newlib case, the failing step is skipped, so I've > >just added branch to the condition, to skip the same check for > >avrlibc. > > That seems reasonable. > > >Please double-check this patch, as it's my first commit to the GCC > >project, and I had to manually adjust a couple of things for the > >regeneration step to work out. > > Has it been tested? Does it work? For the AVR platform? Yes, I did test it and it works: compiled an avr-g++ instance with libstdc++ and then used a couple of features from C++17 (std::optional<> templates). [1] https://patchwork.ozlabs.org/patch/670656/ [2] https://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus [3] https://bugs.archlinux.org/task/56293 [4] https://gcc.gnu.org/ml/gcc/2008-03/msg00515.html [5] https://forum.osdev.org/viewtopic.php?f=13&t=29983
