build failure: No rule to make target '/usr/include/linux/limits.h'
Szabolcs Nagy
szabolcs.nagy@arm.com
Wed Sep 6 10:44:00 GMT 2017
On 05/09/17 21:56, Joseph Myers wrote:
> On Tue, 5 Sep 2017, Szabolcs Nagy wrote:
>
>> somehow glibc managed to include stuff from outside of
>> the source or build tree.. i don't immediately see why.
>
> Are there any .d files containing references to files from D/include?
> (Depending on whether you're using --with-headers to point to an external
> set of kernel headers, references to kernel headers in /usr/include may be
> expected.)
>
i didn't use --with-headers and there is no D/include
or D/build/../include in .d or .dt files.
>> anyway it would be nice if glibc *never* tried to overwrite
>> headers in /usr/include/* while i'm running make.
>
> Dependencies for such files are how "make install" works. There are lots
yes, but i only used 'make', not 'make install',
so i don't expect anything to be installed.
> of such rules, both in the checked-in sources and in sysd-rules, but I
> don't know why one would involve a dependency on
> D/build/../include/linux/limits.h.
>
stracing make it seems make fstats about 400 different
paths ending in /linux before it finds
D/build/../include/linux/limits.h
then it prints
make[2]: Entering directory 'D/glibc/iconv'
/usr/bin/install -c -m 644 D/build/../include/linux/limits.h /usr/include/linux/limits.h
among others it tries paths
D/build/../sysdeps/*/linux
D/build/../include/linux
/usr/include/linux/limits.h appears in D/build/iconv/*.d
files as dependency so i guess there is some broken rule
to remake such headers.
More information about the Libc-alpha
mailing list