From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id E12E5384B00F for ; Tue, 15 Dec 2020 11:48:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E12E5384B00F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-462-H6Yb64bUMKe5dU-PSMD4IQ-1; Tue, 15 Dec 2020 06:48:33 -0500 X-MC-Unique: H6Yb64bUMKe5dU-PSMD4IQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 68A6C59; Tue, 15 Dec 2020 11:48:31 +0000 (UTC) Received: from localhost (unknown [10.33.36.115]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1769172161; Tue, 15 Dec 2020 11:48:30 +0000 (UTC) Date: Tue, 15 Dec 2020 11:48:30 +0000 From: Jonathan Wakely To: Vladimir V Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Problem building libstdc++ for the avr target Message-ID: <20201215114830.GJ2309743@redhat.com> References: <20201207203033.GI2309743@redhat.com> <20201207203201.GJ2309743@redhat.com> <20201209124933.GU2309743@redhat.com> <20201209170125.GW2309743@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 11:48:50 -0000 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 : > >> Thank you for the quick response. >> The patch solves the problem. >> >> ср, 9 дек. 2020 г. в 18:01, Jonathan Wakely : >> >>> 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 >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 > >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 >