| Message ID | CAAVOa6h4O-sgCjFZbVLDptQ+r+4CVPDz=y2yvu_nfoE=eTUzow@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Skip check for dlopen() when compiling libstdcxx with avrlibc | expand |
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? >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?
On Sun, Sep 2, 2018 at 11:00 PM Jonathan Wakely <jwakely@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
On 02/09/18 23:36 +0300, Adrian Stratulat wrote: >On Sun, Sep 2, 2018 at 11:00 PM Jonathan Wakely <jwakely@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]). OK, that explains it, thanks. >> >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). OK great. Unless Denis (AVR maintainer) objects I'll apply this to trunk.
Index: libstdc++-v3/ChangeLog =================================================================== --- libstdc++-v3/ChangeLog (revision 264043) +++ libstdc++-v3/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2018-09-02 Adrian Stratulat <adrian.stratulat91@gmail.com> + + * configure.ac: Skip dlopen check for avrlibc builds. + * configure: Regenerate + 2018-09-02 François Dumont <fdumont@gcc.gnu.org> * include/debug/safe_iterator.h Index: libstdc++-v3/configure =================================================================== --- libstdc++-v3/configure (revision 264043) +++ libstdc++-v3/configure (working copy) @@ -5376,7 +5376,9 @@ $as_echo "$as_me: OS config directory is # Libtool setup. -if test "x${with_newlib}" != "xyes"; then +if test "x${with_newlib}" != "xyes" && + test "x${with_avrlibc}" != "xyes"; +then enable_dlopen=yes Index: libstdc++-v3/configure.ac =================================================================== --- libstdc++-v3/configure.ac (revision 264043) +++ libstdc++-v3/configure.ac (working copy) @@ -89,7 +89,9 @@ CXXFLAGS="$save_CXXFLAGS" GLIBCXX_CONFIGURE # Libtool setup. -if test "x${with_newlib}" != "xyes"; then +if test "x${with_newlib}" != "xyes" && + test "x${with_avrlibc}" != "xyes"; +then AC_LIBTOOL_DLOPEN fi AM_PROG_LIBTOOL