Thank you very much.
вт, 15 дек. 2020 г. в 12:48, Jonathan Wakely <jwak...@redhat.com>:
> On 10/12/20 18:39 +0100, Vladimir V via Libstdc++ wrote:
> >Hello.
> >
> >Could you please have a look at my trivial patch.
> >It works as intended with avr-libc and doesn't seem to introduce
> >regressions for x86_64 hosts.
>
> I've pushed this to master now, thanks for the patch.
>
> >What would be your suggestions for testing?
> >
> >Thank you
> >Vladimir
> >
> >чт, 10 дек. 2020 г. в 00:00, Vladimir V <vv.os....@gmail.com>:
> >
> >> Thank you for the quick response.
> >> The patch solves the problem.
> >>
> >> ср, 9 дек. 2020 г. в 18:01, Jonathan Wakely <jwak...@redhat.com>:
> >>
> >>> On 09/12/20 12:49 +0000, Jonathan Wakely wrote:
> >>> >On 09/12/20 13:32 +0100, Vladimir V wrote:
> >>> >>Hello.
> >>> >>
> >>> >>While testing with the current upstream I encountered a compilation
> >>> issue.
> >>> >>Although I build with "--disable-threads" flag the following error
> >>> occurs:
> >>> >>
> >>> >>../../../../../libstdc++-v3/src/c++11/thread.cc:39:4: error: #error
> "No
> >>> >>sleep function known for this target"
> >>> >>
> >>> >>Previously the check was inside the #ifdef _GLIBCXX_HAS_GTHREADS
> that
> >>> >>prevented the error from happening (in my case with gcc v10.1),
> >>> >>So I would like to ask if the thread.cc should be involved in the
> build
> >>> if
> >>> >>the threads support is configured to be disabled?
> >>> >
> >>> >Yes, the file is always built, but which definitions it contains
> >>> >depends on what is configured for the target.
> >>> >
> >>> >The std::this_thread::sleep_for and std::this_thread::sleep_until
> >>> >functions don't actually depend on threads at all. They just sleep.
> >>> >
> >>> >But that still requires target support, just different support from
> >>> >threads.
> >>> >
> >>> >>And if it should, then can the condition be reworked to cover the
> >>> described
> >>> >>case?
> >>> >
> >>> >Yes, I'll do that. Thanks for bringing it to my attention.
> >>> >
> >>> >I assume we can't use avr-libc's delay functions, because they depend
> >>> >on the CPU clock frequency, which isn't known when we compile
> >>> >libstdc++. So I'll just suppress the declarations of those functions
> >>> >and remove the #error.
> >>>
> >>> The attached patch adds a new _GLIBCXX_NO_SLEEP configure macro which
> >>> should get defined for your hosted AVR build. That should mean that
> >>> std::this_thread::sleep_for is not defined, and src/c++11/thread.cc
> >>> will no longer insist on some way to sleep being supported.
> >>>
> >>> I've only tested this on powerpc64le-linux, so please let me know if
> >>> it works for you.
> >>>
> >>> Pushed to master.
> >>>
> >>>
> >>>
>
> >From fbb2144b56625adf594f8812189b983fa66c910a Mon Sep 17 00:00:00 2001
> >From: Vladimir Vishnevsky <vv.os....@gmail.com>
> >Date: Tue, 8 Dec 2020 21:45:26 +0100
> >Subject: [PATCH] Disabling AC_LIBTOOL_DLOPEN check if building with
> avr-libc
> >
> >The AC_LIBTOOL_DLOPEN checks were previously disabled for newlib targets.
> >The patch applies similar logic to avr-libc based builds.
> >
> >2020-12-08 Vladimir Vishnevsky <vv.os....@gmail.com>
> >
> >libstdc++-v3/ChangeLog:
> > Disabling AC_LIBTOOL_DLOPEN check if building with avr-libc.
> > * configure.ac: Skip AC_LIBTOOL_DLOPEN check if avr-libc is used.
> > * configure: Regenerate.
> >---
> > libstdc++-v3/configure.ac | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
> >index cbfdf4c6bad..771814110a1 100644
> >--- a/libstdc++-v3/configure.ac
> >+++ b/libstdc++-v3/configure.ac
> >@@ -90,7 +90,7 @@ AC_SYS_LARGEFILE
> > 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
> >--
> >2.17.1
> >
>
>
