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 616943857C48 for ; Tue, 9 Feb 2021 10:48:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 616943857C48 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-330-o6XmD9pzNye24wJ26IKHqQ-1; Tue, 09 Feb 2021 05:47:58 -0500 X-MC-Unique: o6XmD9pzNye24wJ26IKHqQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 570BE1934104; Tue, 9 Feb 2021 10:47:57 +0000 (UTC) Received: from localhost (unknown [10.33.36.155]) by smtp.corp.redhat.com (Postfix) with ESMTP id D427F19C66; Tue, 9 Feb 2021 10:47:56 +0000 (UTC) Date: Tue, 9 Feb 2021 10:47:56 +0000 From: Jonathan Wakely To: Vladimir V Cc: Keith Packard , libstdc++@gcc.gnu.org Subject: Re: Problem building libstdc++ for the avr target Message-ID: <20210209104756.GW3008@redhat.com> References: <20201207203033.GI2309743@redhat.com> <87sg8h8i2e.fsf@keithp.com> <20201207210659.GK2309743@redhat.com> <20210108182111.GE9471@redhat.com> <20210208174539.GN3008@redhat.com> <20210208174707.GO3008@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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, RCVD_IN_DNSWL_LOW, 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, 09 Feb 2021 10:48:01 -0000 On 08/02/21 23:25 +0100, Vladimir V wrote: >Thank you for the reply. > >>> I don't see why this file includes , it doesn't *seem* to >>> need it. Even if it's needed, the correct way to include it is: > >So it was there since the initial commit but during my quick walk through >the history >I didn't find what API from was used. My best guess is that it is there because that file previously used lstat and the linux lstat(2) man page (IMHO incorrectly) says that is needed. >So, in the patch I just deleted the include but as Keith suggested it can >affect the client code. >If the policy is: > >>> We routinely remove such transitive includes. Any code assuming that >>> defines the contents of is wrong and should be >>> fixed. > >then I would keep it like that. >Or would it be better to update the patch to move it inside the guard? I will commit your patch unchanged. In practice it is unlikely to affect anybody, because that header is only used when compiling libstdc++ itself. I don't see any code in the Debian archives using it except for GCC itself and one testcase in the Clang repo.