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 69765386F02D for ; Sun, 7 Feb 2021 13:56:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 69765386F02D Received: by mail-ej1-x635.google.com with SMTP id l25so3199301eja.9 for ; Sun, 07 Feb 2021 05:56:04 -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=L2Bf6XpIdHT4bnTvnBgcZMBbdKD1qDdLenFskhFM+gE=; b=Sy1dwDPz0mqSIVXxybVoleE7gqzzaUbnEKT6hITHUOc4sMWygJi9jFYz32j4Ypmk7C Bh0qWRVQEC9zwjcZUuIytkD8q5SQodAqj/Xb+frs7xRGrIoM3PyUKvhGfPwP+B3zazGf Fwc/bpkY8NOPZctL61kKBBYKM7ke5E3EqadURexHr2wQSWKGj+6Gf0ExDpt+RKEBLClx NJiiSXdzDoNk9i8dVaidG1CINP1k+yOE7aE/No6ec0s9dmEQ9j42WUwio+ibG0ZNI2O8 6CeYMuIZryNxaU2ewJ5NtuQ/UQUww8kCk8nqPSO1tkezqK0MTcw5XxNU7FdYOSL+nPNs U94g== X-Gm-Message-State: AOAM5312ZXMX/B/Gj9YER8Q6kPrutKs0wPlX/XVPho6UYU2ARtxZkVRT mQgTq3gPvY0rvaIn03iarH8DBaGX/C9DvenKGGg= X-Google-Smtp-Source: ABdhPJzt31EBWx4oaZWC88+d2l/BoQxk0WJnEbtUnJBPLoGbH+Lb4gEmNFnxCpgqAG0L2e2Z1oEZC8Hi9BKtmSwEiHc= X-Received: by 2002:a17:906:b253:: with SMTP id ce19mr5278197ejb.117.1612706163462; Sun, 07 Feb 2021 05:56:03 -0800 (PST) MIME-Version: 1.0 References: <20201207203033.GI2309743@redhat.com> <87sg8h8i2e.fsf@keithp.com> <20201207210659.GK2309743@redhat.com> <20210108182111.GE9471@redhat.com> In-Reply-To: From: Vladimir V Date: Sun, 7 Feb 2021 14:55:52 +0100 Message-ID: Subject: Re: Problem building libstdc++ for the avr target To: Jonathan Wakely Cc: Keith Packard , libstdc++@gcc.gnu.org Content-Type: multipart/mixed; boundary="000000000000002de405babf6a63" X-Spam-Status: No, score=-8.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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 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: Sun, 07 Feb 2021 13:56:06 -0000 --000000000000002de405babf6a63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I finally managed to test building for AVR with Keith's patch and unistd.h removed (to enforce usage of stabs in filesystem). I identified a couple of minor build issues that are obvious from the attached patch, Could you please have a look? They work with AVR target and doesn't seem to cause regressions for x64 build. Thank you. =D0=BF=D1=82, 22 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3. =D0=B2 15:46, Vladimir V = : > Thank you for the detailed clarification. > > My primary idea was to reduce the build dependencies between hosted > libstdc++ > and target libc if some components can not be supported or never will be > used. > Also my general vision is that if something doesn't work it shouldn't be > available > in the environment. But I perfectly understand the rationale you explaine= d > and requirements applied by standard. > > So I think not much can be done here at this point and further work shoul= d > be on the avr-libc side. > > Thank you. > > =D0=BF=D1=82, 8 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3. =D0=B2 19:21, Jonathan W= akely : > >> On 04/01/21 12:28 +0100, Vladimir V wrote: >> >Hello and Happy New Year! >> > >> >Getting back to the discussion we had about scalable libstdc++. >> >For sure it will be very helpful for embedded targets. There are huge >> >components with >> >well defined boundaries that are unlikely to be often used in minimalis= t >> >settings but require missing platform support. >> >One particular example I'm looking at right now is 'filesystem'. Althou= gh >> >it resorts to some >> >default stubs if corresponding API is not present, I think it would be >> >correct to remove it from the library >> >completely if it can not/should not be used on the target. >> >In case of avr-libc it is worse as the unistd is partially present but >> not >> >sufficient to satisfy all filesystem >> >dependencies. >> > >> >It looks like that after the filesystem support was implemented for c++= 17 >> >standard there is no option to remove >> >it from the build (unlike for the filesystem-ts). Please correct me if = I >> am >> >wrong but If it is like that I would like to make this configurable. >> >> You're right. >> >> My thinking was that the C++ standard requires the header >> to be present for a hosted implementation. It doesn't necessarily >> require the contents to *do* much, so it's conforming for them to >> exist but always report errors. >> >> >Would it be acceptable? >> >> I'm unsure. >> >> Currently we support "hosted" and "freestanding", but not really >> anything more fine-grained. The point of the configure switch >> --disable-libstdcxx-filesystem-ts was not really to allow people to >> build without it, but more to enable it for targets where it wasn't on >> by default because it hadn't been tested yet. >> >> I've recently been trying to move away from having missing features, >> and make things available unconditionally, but to use useless stubs or >> return errors for targets that can't support it. For example, GCC 11 >> always defines the std::thread type, even if the target can't actually >> use it to create new threads. The idea is to always provide a complete >> implementation, not have the feature set vary by target (I see a lot >> of confusion on places like StackOverflow, where the answer is "yeah >> sorry, that header is empty on your OS"). >> >> What you're suggesting would lead to a more modular libstdc++ where >> you can enable/disable components, similar to what newlib does. If we >> did that for more than just the std::filesystem library things would >> get complicated (it increases the maintenance and testing burden, and >> we need to be careful not to create dependencies on anything from a >> conditionally-present feature). >> >> Would your suggestion actually result in smaller/faster binaries for >> AVR? Or just remove features that aren't fully functional if you >> attempt to use them? If having those features in the library doesn't >> actually cause bigger/slower binaries, then I don't really see a >> problem with them being present. >> >> Tangentially, the direction the C++ standard seems to be going is to >> grow the feature set of freestanding. That would allow more things to >> be used in freestanding environments, rather than the very limited set >> of features currently guaranteed to be available. That doesn't really >> help you though, as you want a hosted env with things like basic I/O, >> but not the full set of features usually present for hosted. >> >> >> >> --000000000000002de405babf6a63 Content-Type: text/plain; charset="US-ASCII"; name="libstdc-Fix-build-failure-for-targets-without-unistd.txt" Content-Disposition: attachment; filename="libstdc-Fix-build-failure-for-targets-without-unistd.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kkv7gotj0 RnJvbSBhYzk3MGU2YTM3NmRlZjQzYzUxMGY5MDkxZDM0MmEwMTRmMjNmZThmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBWbGFkaW1pciBWaXNobmV2c2t5IDx2di5vcy5zd2VAZ21haWwu Y29tPgpEYXRlOiBTYXQsIDYgRmViIDIwMjEgMTI6MjU6MjQgKzAxMDAKU3ViamVjdDogW1BBVENI XSBsaWJzdGRjKys6IEZpeCBidWlsZCBmYWlsdXJlIGZvciB0YXJnZXRzIHdpdGhvdXQgdW5pc3Rk LmgKClRoZSBwYXRjaCBmaXhlcyBidWlsZCBpc3N1ZXMgb2NjdXJpbmcgaWYgYnVpbGQgcGFyYW1l dGVyCiItLWVuYWJsZS1jc3RkaW89c3RkaW9fcHVyZSIgaXMgc3BlY2lmaWVkIGFuZCBubyB1bmlz dGQuaCBpcwpwcmVzZW50IGluIHRoZSBlbnZpcm9ubWVudC4KCjIwMjEtMDItMDcgVmxhZGltaXIg VmlzaG5ldnNreSA8dnYub3Muc3dlQGdtYWlsLmNvbT4KCmxpYnN0ZGMrKy12My9DaGFuZ2VMb2c6 CiAgICAgICAgRml4IGJ1aWxkIGZhaWx1cmUgZm9yIHRhcmdldHMgd2l0aG91dCB1bmlzdGQuaC4K ICAgICAgICAqIGluY2x1ZGUvZXh0L3N0ZGlvX3N5bmNfZmlsZWJ1Zi5oOiBVbnVzZWQgPHVuaXN0 ZC5oPiBpbmNsdWRlIHJlbW92ZWQuCiAgICAgICAgKiBzcmMvYysrMTcvZnNfb3BzLmNjOiBQcm9w ZXIgbmFtZXNwYWNlIHNwZWNpZmllZCBmb3IgbG9jYWxseSBkZWZpbmVkCiAgICAgICAgbW9kZV90 LgotLS0KIGxpYnN0ZGMrKy12My9pbmNsdWRlL2V4dC9zdGRpb19zeW5jX2ZpbGVidWYuaCB8IDEg LQogbGlic3RkYysrLXYzL3NyYy9jKysxNy9mc19vcHMuY2MgICAgICAgICAgICAgIHwgMiArLQog MiBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1n aXQgYS9saWJzdGRjKystdjMvaW5jbHVkZS9leHQvc3RkaW9fc3luY19maWxlYnVmLmggYi9saWJz dGRjKystdjMvaW5jbHVkZS9leHQvc3RkaW9fc3luY19maWxlYnVmLmgKaW5kZXggMTc4YjQ3MTk1 N2EuLjkwNzY1ZTU1ODMxIDEwMDY0NAotLS0gYS9saWJzdGRjKystdjMvaW5jbHVkZS9leHQvc3Rk aW9fc3luY19maWxlYnVmLmgKKysrIGIvbGlic3RkYysrLXYzL2luY2x1ZGUvZXh0L3N0ZGlvX3N5 bmNfZmlsZWJ1Zi5oCkBAIC0zMiw3ICszMiw2IEBACiAjcHJhZ21hIEdDQyBzeXN0ZW1faGVhZGVy CiAKICNpbmNsdWRlIDxzdHJlYW1idWY+Ci0jaW5jbHVkZSA8dW5pc3RkLmg+CiAjaW5jbHVkZSA8 Y3N0ZGlvPgogI2luY2x1ZGUgPGJpdHMvYysraW8uaD4gIC8vIEZvciBfX2NfZmlsZQogI2luY2x1 ZGUgPGJpdHMvbW92ZS5oPiAgIC8vIEZvciBfX2V4Y2hhbmdlCmRpZmYgLS1naXQgYS9saWJzdGRj KystdjMvc3JjL2MrKzE3L2ZzX29wcy5jYyBiL2xpYnN0ZGMrKy12My9zcmMvYysrMTcvZnNfb3Bz LmNjCmluZGV4IDcyNzU1Yzk4YTVhLi4wNGE1NTlhYjFkNiAxMDA2NDQKLS0tIGEvbGlic3RkYysr LXYzL3NyYy9jKysxNy9mc19vcHMuY2MKKysrIGIvbGlic3RkYysrLXYzL3NyYy9jKysxNy9mc19v cHMuY2MKQEAgLTExMzAsNyArMTEzMCw3IEBAIGZzOjpwZXJtaXNzaW9ucyhjb25zdCBwYXRoJiBw LCBwZXJtcyBwcm1zLCBwZXJtX29wdGlvbnMgb3B0cywKICNlbHNlCiAgIGlmIChub2ZvbGxvdyAm JiBpc19zeW1saW5rKHN0KSkKICAgICBlYyA9IHN0ZDo6bWFrZV9lcnJvcl9jb2RlKHN0ZDo6ZXJy Yzo6bm90X3N1cHBvcnRlZCk7Ci0gIGVsc2UgaWYgKHBvc2l4OjpjaG1vZChwLmNfc3RyKCksIHN0 YXRpY19jYXN0PG1vZGVfdD4ocHJtcykpKQorICBlbHNlIGlmIChwb3NpeDo6Y2htb2QocC5jX3N0 cigpLCBzdGF0aWNfY2FzdDxwb3NpeDo6bW9kZV90Pihwcm1zKSkpCiAgICAgZXJyID0gZXJybm87 CiAjZW5kaWYKIAotLSAKMi4xNy4xCgo= --000000000000002de405babf6a63--