From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id BE352388A430 for ; Sun, 7 Feb 2021 22:33:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BE352388A430 Received: by mail-ej1-x62c.google.com with SMTP id w1so21675322ejf.11 for ; Sun, 07 Feb 2021 14:33:44 -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=Je/EiOheuYLqLPNtRzxhT3gUYixyiSK3k2PRR++1fiI=; b=MZrlzDARFuWXyyNs2TM7Y/45C/HFwlE57TmYB5Y4bd4bWAFOjZlzgQRzHapwbIMY81 7PHkJmgK8qoR832qrEcvsAJYRoxCyCG0+/VnCrW+pcMWrmZliImoCIE733/3lU2R0hlD gIKPuNXwg0EBQHSGaN0hoIE3UmVnQBl/lbzvThAYTk4anQAHzUa0l+dX0e9/DT1JNEvj tsEYT5bBXBPlxfBYTulzvLiEIvR9KoTSbTYOdGHPJvyEDu+Xb/o6iSBH4Jtzk5Iv3yvW NpKflTzRphSssx93PIKcT5PCgY2Cs8GKVXgCMs0M04q+Temvwdu+DjO9SH7z6BiyEJMy C9Nw== X-Gm-Message-State: AOAM532BdbLDWQhT403tgdbNkYK87awQrkVpfC+AfSa74xo3baA/7wgm Deu43AlcjLs2Q7A5gmzDqZpvSqGnULyYHrVJDaw= X-Google-Smtp-Source: ABdhPJx9zb+4GMqOF+zkOqPItT2pnXS5NJlXZAOYu59hXi5KKLOXIaRc1zE7MaH21vgUHi/qUsYIFZ5rSStdAaGLzcM= X-Received: by 2002:a17:906:7d9:: with SMTP id m25mr14015416ejc.473.1612737223917; Sun, 07 Feb 2021 14:33:43 -0800 (PST) MIME-Version: 1.0 References: <20201207203033.GI2309743@redhat.com> <87sg8h8i2e.fsf@keithp.com> <20201207210659.GK2309743@redhat.com> <20210108182111.GE9471@redhat.com> <87eehrbuuv.fsf@keithp.com> In-Reply-To: <87eehrbuuv.fsf@keithp.com> From: Vladimir V Date: Sun, 7 Feb 2021 23:33:32 +0100 Message-ID: Subject: Re: Problem building libstdc++ for the avr target To: Keith Packard Cc: Jonathan Wakely , libstdc++@gcc.gnu.org X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, BODY_8BITS, 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: Sun, 07 Feb 2021 22:33:47 -0000 Thank you for the feedback. >> Picolibc has a unistd.h to define the relevant interfaces, even though >> it doesn't require them. Perhaps avrlibc could do the same? Or even an >> empty file that would satisfy this requirement? The avr-libc has unistd.h with some declarations required by streams and it should be further extended to support requirements. My findings are the result of the experiment where I wanted to identify dependencies on for AVR build. As for non-posix targets unistd.h might be absent, I decided to bring it to attention. >> Hrm. Removing unistd.h from an installed file might affect applications >>using that file, so that doesn't seem ideal. Thanks for pointing that out. It indeed looks like potentially breaking change. Although the declarations from does not seem to be used in the file itself, some client code could rely on implicit include. But If the GNU C++ standard library extensions where stdio_sync_filebuf belongs supports non-posix targets then maybe include should be moved inside _GLIBCXX_HAVE_UNISTD_H guard? This should provide backward compatibility. >> I'm afraid I don't understand what this piece does without studying the >> underlying code a bunch. But, if it's just namespace stuff in an >> internal implementation file, that seems fine to me. It is really just the namespace missing in the conditionally-compiled part. Thank you. =D0=B2=D1=81, 7 =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3. =D0=B2 19:23, Keith = Packard : > Vladimir V writes: > > > 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. > > Hrm. Removing unistd.h from an installed file might affect applications > using that file, so that doesn't seem ideal. > > Picolibc has a unistd.h to define the relevant interfaces, even though > it doesn't require them. Perhaps avrlibc could do the same? Or even an > empty file that would satisfy this requirement? > > > --- a/libstdc++-v3/src/c++17/fs_ops.cc > > +++ b/libstdc++-v3/src/c++17/fs_ops.cc > > @@ -1130,7 +1130,7 @@ fs::permissions(const path& p, perms prms, > perm_options opts, > > #else > > if (nofollow && is_symlink(st)) > > ec =3D std::make_error_code(std::errc::not_supported); > > - else if (posix::chmod(p.c_str(), static_cast(prms))) > > + else if (posix::chmod(p.c_str(), static_cast(prms))) > > err =3D errno; > > #endif > > I'm afraid I don't understand what this piece does without studying the > underlying code a bunch. But, if it's just namespace stuff in an > internal implementation file, that seems fine to me. > > -- > -keith >