This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4] Add and use new glibc-internal futex API.


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]