* build failure: No rule to make target '/usr/include/linux/limits.h'
@ 2017-09-05 18:24 Szabolcs Nagy
2017-09-05 20:56 ` Joseph Myers
0 siblings, 1 reply; 9+ messages in thread
From: Szabolcs Nagy @ 2017-09-05 18:24 UTC (permalink / raw)
To: GNU C Library; +Cc: nd
suppose i have directory structure
D/glibc - source repo
D/build - from where i run the configure script and then make
D/include - old libc headers lying around which should not affect anything
then when i run make i get
....
make subdir=iconv -C iconv ..=../ subdir_lib
make[2]: Entering directory 'D/glibc/iconv'
/usr/bin/install -c -m 644 D/build/../include/linux/limits.h /usr/include/linux/limits.h
/usr/bin/install: cannot remove '/usr/include/linux/limits.h': Permission denied
/usr/bin/install -c -m 644 D/build/../include/linux/limits.h /usr/include/linux/limits.h
/usr/bin/install: cannot remove '/usr/include/linux/limits.h': Permission denied
make[2]: *** No rule to make target '/usr/include/linux/limits.h', needed by 'D/build/iconv/iconv_open.o'. Stop.
make[2]: Leaving directory 'D/glibc/iconv'
Makefile:215: recipe for target 'iconv/subdir_lib' failed
make[1]: *** [iconv/subdir_lib] Error 2
make[1]: Leaving directory 'D/glibc'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2
the exact failure depends on the contents of D/include,
if i remove that directory then the build succeeds.
somehow glibc managed to include stuff from outside of
the source or build tree.. i don't immediately see why.
anyway it would be nice if glibc *never* tried to overwrite
headers in /usr/include/* while i'm running make.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: build failure: No rule to make target '/usr/include/linux/limits.h'
2017-09-05 18:24 build failure: No rule to make target '/usr/include/linux/limits.h' Szabolcs Nagy
@ 2017-09-05 20:56 ` Joseph Myers
2017-09-06 10:44 ` Szabolcs Nagy
0 siblings, 1 reply; 9+ messages in thread
From: Joseph Myers @ 2017-09-05 20:56 UTC (permalink / raw)
To: Szabolcs Nagy; +Cc: GNU C Library, nd
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.)
> 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
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.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: build failure: No rule to make target '/usr/include/linux/limits.h'
2017-09-05 20:56 ` Joseph Myers
@ 2017-09-06 10:44 ` Szabolcs Nagy
2017-09-06 10:58 ` Andreas Schwab
0 siblings, 1 reply; 9+ messages in thread
From: Szabolcs Nagy @ 2017-09-06 10:44 UTC (permalink / raw)
To: Joseph Myers; +Cc: nd, GNU C Library
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: build failure: No rule to make target '/usr/include/linux/limits.h'
2017-09-06 10:44 ` Szabolcs Nagy
@ 2017-09-06 10:58 ` Andreas Schwab
2017-09-06 11:05 ` Szabolcs Nagy
0 siblings, 1 reply; 9+ messages in thread
From: Andreas Schwab @ 2017-09-06 10:58 UTC (permalink / raw)
To: Szabolcs Nagy; +Cc: Joseph Myers, nd, GNU C Library
On Sep 06 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> stracing make it seems make fstats about 400 different
> paths ending in /linux before it finds
>
> D/build/../include/linux/limits.h
Where does that file come from?
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: build failure: No rule to make target '/usr/include/linux/limits.h'
2017-09-06 10:58 ` Andreas Schwab
@ 2017-09-06 11:05 ` Szabolcs Nagy
2017-09-06 11:57 ` Andreas Schwab
2017-09-06 14:47 ` Joseph Myers
0 siblings, 2 replies; 9+ messages in thread
From: Szabolcs Nagy @ 2017-09-06 11:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: nd, Joseph Myers, GNU C Library
On 06/09/17 11:58, Andreas Schwab wrote:
> On Sep 06 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
>> stracing make it seems make fstats about 400 different
>> paths ending in /linux before it finds
>>
>> D/build/../include/linux/limits.h
>
> Where does that file come from?
>
there must be a broken
$(prefix)/include/%.h: ../include/%.h
install ...
rule somewhere that is invoked from D/build.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: build failure: No rule to make target '/usr/include/linux/limits.h'
2017-09-06 11:05 ` Szabolcs Nagy
@ 2017-09-06 11:57 ` Andreas Schwab
2017-09-06 12:05 ` Szabolcs Nagy
2017-09-06 14:47 ` Joseph Myers
1 sibling, 1 reply; 9+ messages in thread
From: Andreas Schwab @ 2017-09-06 11:57 UTC (permalink / raw)
To: Szabolcs Nagy; +Cc: nd, Joseph Myers, GNU C Library
On Sep 06 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 06/09/17 11:58, Andreas Schwab wrote:
>> On Sep 06 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>
>>> stracing make it seems make fstats about 400 different
>>> paths ending in /linux before it finds
>>>
>>> D/build/../include/linux/limits.h
>>
>> Where does that file come from?
>>
>
> there must be a broken
>
> $(prefix)/include/%.h: ../include/%.h
> install ...
>
> rule somewhere that is invoked from D/build.
No, that rule does not create that file.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: build failure: No rule to make target '/usr/include/linux/limits.h'
2017-09-06 11:57 ` Andreas Schwab
@ 2017-09-06 12:05 ` Szabolcs Nagy
0 siblings, 0 replies; 9+ messages in thread
From: Szabolcs Nagy @ 2017-09-06 12:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: nd, Joseph Myers, GNU C Library
On 06/09/17 12:57, Andreas Schwab wrote:
> On Sep 06 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
>> On 06/09/17 11:58, Andreas Schwab wrote:
>>> On Sep 06 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>>
>>>> stracing make it seems make fstats about 400 different
>>>> paths ending in /linux before it finds
>>>>
>>>> D/build/../include/linux/limits.h
>>>
>>> Where does that file come from?
>>>
>>
>> there must be a broken
>>
>> $(prefix)/include/%.h: ../include/%.h
>> install ...
>>
>> rule somewhere that is invoked from D/build.
>
> No, that rule does not create that file.
>
D/build/../include/linux/limits.h already exists
(it's a file outside of the build dir hence it
should not affect anything)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: build failure: No rule to make target '/usr/include/linux/limits.h'
2017-09-06 11:05 ` Szabolcs Nagy
2017-09-06 11:57 ` Andreas Schwab
@ 2017-09-06 14:47 ` Joseph Myers
2017-09-06 14:57 ` Andreas Schwab
1 sibling, 1 reply; 9+ messages in thread
From: Joseph Myers @ 2017-09-06 14:47 UTC (permalink / raw)
To: Szabolcs Nagy; +Cc: Andreas Schwab, nd, GNU C Library
On Wed, 6 Sep 2017, Szabolcs Nagy wrote:
> On 06/09/17 11:58, Andreas Schwab wrote:
> > On Sep 06 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> >
> >> stracing make it seems make fstats about 400 different
> >> paths ending in /linux before it finds
> >>
> >> D/build/../include/linux/limits.h
> >
> > Where does that file come from?
> >
>
> there must be a broken
>
> $(prefix)/include/%.h: ../include/%.h
> install ...
>
> rule somewhere that is invoked from D/build.
make generally gets run with a working directory in the source tree, not
the build tree (and uses the $(..) variable which ought to be empty at top
level, ../ in a subdirectory). So getting build/../ is particularly odd
(srcdir/../ would require fewer things to be wrong, though of course it
shouldn't appear either).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: build failure: No rule to make target '/usr/include/linux/limits.h'
2017-09-06 14:47 ` Joseph Myers
@ 2017-09-06 14:57 ` Andreas Schwab
0 siblings, 0 replies; 9+ messages in thread
From: Andreas Schwab @ 2017-09-06 14:57 UTC (permalink / raw)
To: Joseph Myers; +Cc: Szabolcs Nagy, nd, GNU C Library
On Sep 06 2017, Joseph Myers <joseph@codesourcery.com> wrote:
> On Wed, 6 Sep 2017, Szabolcs Nagy wrote:
>
>> On 06/09/17 11:58, Andreas Schwab wrote:
>> > On Sep 06 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>> >
>> >> stracing make it seems make fstats about 400 different
>> >> paths ending in /linux before it finds
>> >>
>> >> D/build/../include/linux/limits.h
>> >
>> > Where does that file come from?
>> >
>>
>> there must be a broken
>>
>> $(prefix)/include/%.h: ../include/%.h
>> install ...
>>
>> rule somewhere that is invoked from D/build.
>
> make generally gets run with a working directory in the source tree, not
> the build tree (and uses the $(..) variable which ought to be empty at top
> level, ../ in a subdirectory). So getting build/../ is particularly odd
> (srcdir/../ would require fewer things to be wrong, though of course it
> shouldn't appear either).
I'd guess it's coming from vpath $(common-objpfx).
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-09-06 14:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-05 18:24 build failure: No rule to make target '/usr/include/linux/limits.h' Szabolcs Nagy
2017-09-05 20:56 ` Joseph Myers
2017-09-06 10:44 ` Szabolcs Nagy
2017-09-06 10:58 ` Andreas Schwab
2017-09-06 11:05 ` Szabolcs Nagy
2017-09-06 11:57 ` Andreas Schwab
2017-09-06 12:05 ` Szabolcs Nagy
2017-09-06 14:47 ` Joseph Myers
2017-09-06 14:57 ` Andreas Schwab
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).