* Re: Problem building libstdc++ for the avr target [not found] ` <20201209124933.GU2309743@redhat.com> @ 2020-12-09 17:01 ` Jonathan Wakely 2020-12-09 23:00 ` Vladimir V 0 siblings, 1 reply; 5+ messages in thread From: Jonathan Wakely @ 2020-12-09 17:01 UTC (permalink / raw) To: Vladimir V; +Cc: libstdc++, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1736 bytes --] 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. [-- Attachment #2: patch.txt --] [-- Type: text/x-patch, Size: 4048 bytes --] commit 0aa1786d34b891c8e1e219fb11255af5358013c4 Author: Jonathan Wakely <jwakely@redhat.com> Date: Wed Dec 9 16:53:18 2020 libstdc++: Fix build failure for target with no way to sleep In previous releases the std::this_thread::sleep_for function was only declared if the target supports multiple threads. I changed that recently in r11-2649-g5bbb1f3000c57fd4d95969b30fa0e35be6d54ffb so that sleep_for could be used single-threaded. But that means that targets using --disable-threads are now required to provide some way to sleep. This breaks the build for (at least) AVR when trying to build a hosted library. This patch adds a new autoconf macro that is defined when no way to sleep is available, and uses that to suppress the sleeping functions in std::this_thread. The #error in src/c++11/thread.cc is retained for the case where there is no sleep function available but multiple threads are supported. This is consistent with previous releases, but that #error could probably be removed without any consequences. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Define NO_SLEEP if none of nanosleep, sleep and Sleep is available. * config.h.in: Regenerate. * configure: Regenerate. * include/std/thread [_GLIBCXX_NO_SLEEP] (__sleep_for): Do not declare. [_GLIBCXX_NO_SLEEP] (sleep_for, sleep_until): Do not define. * src/c++11/thread.cc [_GLIBCXX_NO_SLEEP] (__sleep_for): Do not define. diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index fcd9ea3d23a..61191812c92 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -1626,16 +1626,22 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [ fi if test x"$ac_has_nanosleep$ac_has_sleep" = x"nono"; then + ac_no_sleep=yes AC_MSG_CHECKING([for Sleep]) AC_TRY_COMPILE([#include <windows.h>], [Sleep(1)], [ac_has_win32_sleep=yes],[ac_has_win32_sleep=no]) if test x"$ac_has_win32_sleep" = x"yes"; then AC_DEFINE(HAVE_WIN32_SLEEP,1, [Defined if Sleep exists.]) + ac_no_sleep=no fi AC_MSG_RESULT($ac_has_win32_sleep) fi + if test x"$ac_no_sleep" = x"yes"; then + AC_DEFINE(NO_SLEEP,1, [Defined if no way to sleep is available.]) + fi + AC_SUBST(GLIBCXX_LIBS) CXXFLAGS="$ac_save_CXXFLAGS" diff --git a/libstdc++-v3/include/std/thread b/libstdc++-v3/include/std/thread index 6ea8a51c0cf..8d0ede2b6c2 100644 --- a/libstdc++-v3/include/std/thread +++ b/libstdc++-v3/include/std/thread @@ -122,8 +122,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION */ namespace this_thread { +#ifndef _GLIBCXX_NO_SLEEP + +#ifndef _GLIBCXX_USE_NANOSLEEP void __sleep_for(chrono::seconds, chrono::nanoseconds); +#endif /// this_thread::sleep_for template<typename _Rep, typename _Period> @@ -168,7 +172,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION __now = _Clock::now(); } } - } + } // namespace this_thread +#endif // ! NO_SLEEP #ifdef __cpp_lib_jthread diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc index a9c92804959..62f6ddcd802 100644 --- a/libstdc++-v3/src/c++11/thread.cc +++ b/libstdc++-v3/src/c++11/thread.cc @@ -35,7 +35,8 @@ # include <unistd.h> # elif defined(_GLIBCXX_HAVE_WIN32_SLEEP) # include <windows.h> -# else +# elif defined _GLIBCXX_NO_SLEEP && defined _GLIBCXX_HAS_GTHREADS +// We expect to be able to sleep for targets that support multiple threads: # error "No sleep function known for this target" # endif #endif @@ -196,6 +197,7 @@ _GLIBCXX_END_NAMESPACE_VERSION #endif // _GLIBCXX_HAS_GTHREADS +#ifndef _GLIBCXX_NO_SLEEP namespace std _GLIBCXX_VISIBILITY(default) { _GLIBCXX_BEGIN_NAMESPACE_VERSION @@ -252,3 +254,4 @@ namespace this_thread } _GLIBCXX_END_NAMESPACE_VERSION } // namespace std +#endif // ! NO_SLEEP ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem building libstdc++ for the avr target 2020-12-09 17:01 ` Problem building libstdc++ for the avr target Jonathan Wakely @ 2020-12-09 23:00 ` Vladimir V [not found] ` <CA+=iAiqk3Sj4JU-2ZPSuoFZ0EBFkBm8Fa_NyBCxMxvrnGzOd7A@mail.gmail.com> 0 siblings, 1 reply; 5+ messages in thread From: Vladimir V @ 2020-12-09 23:00 UTC (permalink / raw) To: Jonathan Wakely; +Cc: libstdc++, gcc-patches Thank you for the quick response. The patch solves the problem. ср, 9 дек. 2020 г. в 18:01, Jonathan Wakely <jwakely@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. > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CA+=iAiqk3Sj4JU-2ZPSuoFZ0EBFkBm8Fa_NyBCxMxvrnGzOd7A@mail.gmail.com>]
* Re: Problem building libstdc++ for the avr target [not found] ` <CA+=iAiqk3Sj4JU-2ZPSuoFZ0EBFkBm8Fa_NyBCxMxvrnGzOd7A@mail.gmail.com> @ 2020-12-15 11:48 ` Jonathan Wakely 2020-12-16 7:33 ` Vladimir V 0 siblings, 1 reply; 5+ messages in thread From: Jonathan Wakely @ 2020-12-15 11:48 UTC (permalink / raw) To: Vladimir V; +Cc: libstdc++, gcc-patches 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.swe@gmail.com>: > >> Thank you for the quick response. >> The patch solves the problem. >> >> ср, 9 дек. 2020 г. в 18:01, Jonathan Wakely <jwakely@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.swe@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.swe@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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem building libstdc++ for the avr target 2020-12-15 11:48 ` Jonathan Wakely @ 2020-12-16 7:33 ` Vladimir V 0 siblings, 0 replies; 5+ messages in thread From: Vladimir V @ 2020-12-16 7:33 UTC (permalink / raw) To: Jonathan Wakely; +Cc: libstdc++, gcc-patches Thank you very much. вт, 15 дек. 2020 г. в 12:48, Jonathan Wakely <jwakely@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.swe@gmail.com>: > > > >> Thank you for the quick response. > >> The patch solves the problem. > >> > >> ср, 9 дек. 2020 г. в 18:01, Jonathan Wakely <jwakely@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.swe@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.swe@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 > > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20210108182111.GE9471@redhat.com>]
[parent not found: <CA+=iAipOrymYgGeJw3geD7cULLbfOU=t-rgymdoE9Ai-L303pQ@mail.gmail.com>]
[parent not found: <CA+=iAirEbHa95-QTJtqBFA4m8ZsmYYMHpHhwtox7Hp3Avv7fAg@mail.gmail.com>]
[parent not found: <20210208174539.GN3008@redhat.com>]
[parent not found: <20210208174707.GO3008@redhat.com>]
[parent not found: <CA+=iAirNQKf4UBtXAbCLHomuaoQyBL=p4jrHiO7v2wzWCCGJaA@mail.gmail.com>]
[parent not found: <20210209104756.GW3008@redhat.com>]
[parent not found: <CA+=iAipEgzncQ5zPUQOT4m_JSGHhTdrnMCWySQVCog0HG7aBaA@mail.gmail.com>]
[parent not found: <CA+=iAipaM6VQWBH3gWsrAjy=hB8ss_ZpRyWjPge2SJ7bxmEEOQ@mail.gmail.com>]
[parent not found: <20210325123603.GN3008@redhat.com>]
* Re: Problem building libstdc++ for the avr target [not found] ` <20210325123603.GN3008@redhat.com> @ 2021-03-25 18:27 ` Jonathan Wakely 0 siblings, 0 replies; 5+ messages in thread From: Jonathan Wakely @ 2021-03-25 18:27 UTC (permalink / raw) To: Vladimir V; +Cc: libstdc++, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1970 bytes --] On 25/03/21 12:36 +0000, Jonathan Wakely wrote: >On 25/03/21 10:27 +0100, Vladimir V wrote: >>Hello. >> >>Recently I tried the 'freestanding' build of the libstdc++ for the avr to >>verify that my fixes were sufficient for it as well. >>Unfortunately, I encountered the following error: >>../../../../libstdc++-v3/libsupc++/new_opa.cc: In function 'void* >>__gnu_cxx::aligned_alloc(std::size_t, std::size_t)': >>../../../../libstdc++-v3/libsupc++/new_opa.cc:97:28: error: 'malloc' was >>not declared in this scope >> 97 | void* const malloc_ptr = malloc(sz + al); >> >>My investigation showed that in the chain of includes the stdlib.h of the >>avr-libc is not present. >>It looks like includes are resolved in the following way (here are the >>original paths as they are linked from out folders during build): >>new_opa.cc -> libstdc++-v3/include/c_compatibility/stdlib.h -> >>libstdc++-v3/include/c_global/cstdlib >>In cstdlib, for non-hosted builds stdlib.h is not included. >> >>This problem is not present if the non-hosted build is done with >>'with-newlib' flag instead of 'with-avrlibc' (common workaround as the >>avrlibc build was fixed only recently). >>Might it be that some include order depends on the target libc? Or maybe >>some implicit conditions are involved? >> >>Could you please support me with this issue? > >I think this is needed: > >--- a/libstdc++-v3/libsupc++/new_opa.cc >+++ b/libstdc++-v3/libsupc++/new_opa.cc >@@ -54,6 +54,10 @@ extern "C" > void *posix_memalign(void **, size_t alignment, size_t size); > # elif _GLIBCXX_HAVE_MEMALIGN > void *memalign(size_t alignment, size_t size); >+#else >+ // A freestanding C runtime may not provide "malloc" -- but there is no >+ // other reasonable way to implement "operator new". >+ void *malloc (std::size_t); with GCC 7.5 Oops, there was a stray "with GCC 7.5" that got into my clipboard there! I've pushed the attached patch, please test and confirm if it fixes your problem. [-- Attachment #2: patch.txt --] [-- Type: text/x-patch, Size: 1093 bytes --] commit 15d649f79d6b6dc336f6a32eec242b652a262a82 Author: Jonathan Wakely <jwakely@redhat.com> Date: Thu Mar 25 18:24:37 2021 libstdc++: Declare malloc for freestanding For a target with none of aligned_alloc, memalign etc. we defined our own aligned_alloc using malloc, so we need a declaration of malloc. As in libsupc++/new_op.cc we need to declare it ourselves for freestanding environments. libstdc++-v3/ChangeLog: * libsupc++/new_opa.cc [!_GLIBCXX_HOSTED]: Declare malloc. diff --git a/libstdc++-v3/libsupc++/new_opa.cc b/libstdc++-v3/libsupc++/new_opa.cc index 59296226e83..6b78729dc24 100644 --- a/libstdc++-v3/libsupc++/new_opa.cc +++ b/libstdc++-v3/libsupc++/new_opa.cc @@ -54,6 +54,10 @@ extern "C" void *posix_memalign(void **, size_t alignment, size_t size); # elif _GLIBCXX_HAVE_MEMALIGN void *memalign(size_t alignment, size_t size); +# else + // A freestanding C runtime may not provide "malloc" -- but there is no + // other reasonable way to implement "operator new". + void *malloc(size_t); # endif } #endif ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-25 18:27 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CA+=iAirn_xc2EhxBdwwjr_Ak2bmS4eVHpxoMVR5xKCXghQOH9A@mail.gmail.com> [not found] ` <20201207203033.GI2309743@redhat.com> [not found] ` <20201207203201.GJ2309743@redhat.com> [not found] ` <CA+=iAiqh1c9hUO45XUMuffNgZWhWuZOz+1cDhLGbPrXPVMPw0A@mail.gmail.com> [not found] ` <CA+=iAip_JN164_kZhDsd-+ET12Atve7F3aJcnmKCikFteVdDDg@mail.gmail.com> [not found] ` <20201209124933.GU2309743@redhat.com> 2020-12-09 17:01 ` Problem building libstdc++ for the avr target Jonathan Wakely 2020-12-09 23:00 ` Vladimir V [not found] ` <CA+=iAiqk3Sj4JU-2ZPSuoFZ0EBFkBm8Fa_NyBCxMxvrnGzOd7A@mail.gmail.com> 2020-12-15 11:48 ` Jonathan Wakely 2020-12-16 7:33 ` Vladimir V [not found] <20210108182111.GE9471@redhat.com> [not found] ` <CA+=iAipOrymYgGeJw3geD7cULLbfOU=t-rgymdoE9Ai-L303pQ@mail.gmail.com> [not found] ` <CA+=iAirEbHa95-QTJtqBFA4m8ZsmYYMHpHhwtox7Hp3Avv7fAg@mail.gmail.com> [not found] ` <20210208174539.GN3008@redhat.com> [not found] ` <20210208174707.GO3008@redhat.com> [not found] ` <CA+=iAirNQKf4UBtXAbCLHomuaoQyBL=p4jrHiO7v2wzWCCGJaA@mail.gmail.com> [not found] ` <20210209104756.GW3008@redhat.com> [not found] ` <CA+=iAipEgzncQ5zPUQOT4m_JSGHhTdrnMCWySQVCog0HG7aBaA@mail.gmail.com> [not found] ` <CA+=iAipaM6VQWBH3gWsrAjy=hB8ss_ZpRyWjPge2SJ7bxmEEOQ@mail.gmail.com> [not found] ` <20210325123603.GN3008@redhat.com> 2021-03-25 18:27 ` Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).