From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id C311E3850418; Wed, 9 Dec 2020 23:00:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C311E3850418 Received: by mail-ej1-x635.google.com with SMTP id m19so4551925ejj.11; Wed, 09 Dec 2020 15:00:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wL95AedYSqM+8nyLGzyuS0s22p3ymIaqrc3eimifIeI=; b=Lci8izkGFdYQerxjWl8uGEnFdhcoLcKmyfAMnOQyH6esYLh3zj4pKu7IBbe6OVErHu 1ZSUEPuHsNQxjrwPW0Tt5PdtdsnV3yEYPTdA8czP7rYkJ/9Pi7ATaSur1E6zJKPN7cxm wdsKhQxVlhYekLjT6iNSp008liPniGq0g12IJXXSheBWmDgpHQYG54uxNkpmcwgjZrEV kIoZaiojgXrEzILG3ZTQFXUcVhvPEf6FodrGSlNRKoQfa/Z9QYQy1YNxHdCZ+9e0Ei1s oy7ltglT+knzOBfJgxmqTJr+GAm5CkD3SlVUA8kYMFkgQzCAQSC2xusbUCRKQ2ixTD+7 H+Fg== X-Gm-Message-State: AOAM531rEacLBZ/MT+DzcZhjbxPFyIzxQsg7WRk+K1uJjfckDOuc3D+s qyA8TtU+X0mv8SuTkaMH8n6aT0KX/g87EljXYsA= X-Google-Smtp-Source: ABdhPJz+9FNKxyTAifbU7KTF6R0eP90Bv8nFLj4ZHkOIqwstRYA6v2WQ5Sepyxl8g5eefEvdzq93vVKwwBHeqpug/o0= X-Received: by 2002:a17:906:6d47:: with SMTP id a7mr4093342ejt.340.1607554823758; Wed, 09 Dec 2020 15:00:23 -0800 (PST) MIME-Version: 1.0 References: <20201207203033.GI2309743@redhat.com> <20201207203201.GJ2309743@redhat.com> <20201209124933.GU2309743@redhat.com> <20201209170125.GW2309743@redhat.com> In-Reply-To: <20201209170125.GW2309743@redhat.com> From: Vladimir V Date: Thu, 10 Dec 2020 00:00:12 +0100 Message-ID: Subject: Re: Problem building libstdc++ for the avr target To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 09 Dec 2020 23:00:26 -0000 Thank you for the quick response. The patch solves the problem. =D1=81=D1=80, 9 =D0=B4=D0=B5=D0=BA. 2020 =D0=B3. =D0=B2 18:01, Jonathan Wak= ely : > 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. > > >