From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90328 invoked by alias); 26 Jul 2018 15:16:15 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 90316 invoked by uid 89); 26 Jul 2018 15:16:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=our, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Subject: Re: [PATCH] Add the statx function To: Szabolcs Nagy , Andreas Schwab Cc: nd@arm.com, Carlos O'Donell , Paul Eggert , libc-alpha@sourceware.org References: <20180630224103.4501543994575@oldenburg.str.redhat.com> <4934579e-a05c-3dcc-0b26-5ec09e03fbb3@cs.ucla.edu> <39950c72-09e7-4557-d62f-4b3a65ec5353@redhat.com> <9378e999-9c2b-0925-89e0-d9c39101b1bf@redhat.com> <85b41fe2-05f1-094d-c9c2-f3149e4dce83@redhat.com> <9f8fcf2b-a075-a390-90a5-d8f5cd38f65c@arm.com> From: Florian Weimer Message-ID: Date: Thu, 26 Jul 2018 15:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <9f8fcf2b-a075-a390-90a5-d8f5cd38f65c@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-07/txt/msg00907.txt.bz2 On 07/11/2018 12:01 PM, Szabolcs Nagy wrote: > On 11/07/18 07:55, Florian Weimer wrote: >> On 07/11/2018 08:53 AM, Andreas Schwab wrote: >>> /usr/include/sys/stat.h:446:11: fatal error: bits/statx.h: No such >>> file or directory >>>   # include >>>             ^~~~~~~~~~~~~~ >> >> Okay, so this file should be an installed header.  I will commit a fix >> after testing. >> >> Any idea why our header tests do not catch this? >> > > because the glibc source tree does have bits/statx.h > and all tests (incorrectly) run with internal headers > in the include path (not just the installed ones). I had hoped that the check-installed-headers-* tests would catch this, but clearly that's not the case. > build-many-glibcs.py catches it though when building gcc > (i've just run into this). Only if GCC uses the header, right? So it's only limited coverage because GCC aims to be portable and won't use obscure stuff. Thanks, Florian