This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4] Add and use new glibc-internal futex API.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Wed, 01 Jul 2015 18:38:54 +0200
- Subject: Re: [PATCH v4] Add and use new glibc-internal futex API.
- Authentication-results: sourceware.org; auth=none
- References: <1434987160 dot 25759 dot 26 dot camel at localhost dot localdomain> <20150624232258 dot 9A74C2C3B00 at topped-with-meat dot com> <1435749621 dot 4216 dot 64 dot camel at localhost dot localdomain> <1435759803 dot 4216 dot 65 dot camel at localhost dot localdomain> <mvmegksrm5a dot fsf at hawking dot suse dot de>
On Wed, 2015-07-01 at 16:24 +0200, Andreas Schwab wrote:
> Torvald Riegel <triegel@redhat.com> writes:
>
> > On Wed, 2015-07-01 at 13:20 +0200, Torvald Riegel wrote:
> >> Tested on x86_64-linux. No regressions except that I am getting a
> >> check-local-headers failure:
> >> *** $(common-objpfx)stdio-common/scanf15.o:
> >> uses /usr/include/bits/syscall.h
> >> *** /usr/include/bits/syscall.h: uses /usr/include/bits/syscall.h:
> >> *** $(common-objpfx)stdio-common/scanf17.o:
> >> uses /usr/include/bits/syscall.h
> >> *** /usr/include/bits/syscall.h: uses /usr/include/bits/syscall.h:
> >> Any advice on how to fix that?
> >
> > And that regression goes away with a fresh build, not an incremental
> > build. Sigh.
>
> The only reason you don't get the failure with a fresh build is that
> check-local-headers runs when the *.dt files of all the test programs
> are not yet converted into *.d files.
OK, I see that now. Is that intentional? Or does check-local-headers
simply not work with fresh builds (which would be surprising..)?
Any further feedback on whether the actual failure reported on a
non-fresh-build makes sense, and how to fix it?