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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id A7E4B386185F for ; Mon, 8 Feb 2021 17:38:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A7E4B386185F 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-523-oTY6vY72PQio74Kcs2J2tA-1; Mon, 08 Feb 2021 12:38:15 -0500 X-MC-Unique: oTY6vY72PQio74Kcs2J2tA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6DA708799ED; Mon, 8 Feb 2021 17:38:14 +0000 (UTC) Received: from localhost (unknown [10.33.36.155]) by smtp.corp.redhat.com (Postfix) with ESMTP id 059B460938; Mon, 8 Feb 2021 17:38:13 +0000 (UTC) Date: Mon, 8 Feb 2021 17:38:13 +0000 From: Jonathan Wakely To: Keith Packard Cc: Vladimir V , libstdc++@gcc.gnu.org Subject: Re: Problem building libstdc++ for the avr target Message-ID: <20210208173813.GM3008@redhat.com> References: <20201207203033.GI2309743@redhat.com> <87sg8h8i2e.fsf@keithp.com> <20201207210659.GK2309743@redhat.com> <20210108182111.GE9471@redhat.com> <87eehrbuuv.fsf@keithp.com> MIME-Version: 1.0 In-Reply-To: <87eehrbuuv.fsf@keithp.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, 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: Mon, 08 Feb 2021 17:38:21 -0000 On 07/02/21 10:23 -0800, Keith Packard wrote: >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. I'll take a look ASAP, thanks. >Hrm. Removing unistd.h from an installed file might affect applications >using that file, so that doesn't seem ideal. We routinely remove such transitive includes. Any code assuming that defines the contents of is wrong and should be fixed. For example: https://gcc.gnu.org/gcc-11/porting_to.html#header-dep-changes https://gcc.gnu.org/gcc-10/porting_to.html#header-dep-changes https://gcc.gnu.org/gcc-7/porting_to.html#header-dep-changes https://gcc.gnu.org/gcc-6/porting_to.html#header-dep-changes >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 = 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 = 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. The libstdc++-v3/src/filesystem/ops-common.h header declares a few POSIX-y things in namespace __gnu_posix (which is then aliased as just "posix"). Then when the C++ standard says filesystem operations behave "as if by POSIX rename" or "as if by POSIX lstat" the code can be written in terms of posix::rename or POSIX::lstat. In this instance, we declare something as posix::mode_t and so should refer to it using that name too. I'll look at the rest of the patch ASAP.