Bug 219892
Summary: | make 3.81 problem with implicit rules | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Philippe Rigault <prigault> | ||||||
Component: | make | Assignee: | Petr Machata <pmachata> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 6 | CC: | mnewsome | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2007-02-16 13:28:18 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Philippe Rigault
2006-12-16 00:10:48 UTC
Created attachment 143836 [details]
the makefile in question
Note: the tar file is not compressed despite its .gz extension. By any chance, do you know if the Makefile uses paralel builds in some way? And doesn't the problem go away when you simply reexec toplevel make? There is another bug for make, bug 212111, that has somewhat similar symptom. >By any chance, do you know if the Makefile uses paralel builds in some way? No, it does not. If I explicitly add the "-j1" option, I get the same results. >doesn't the problem go away when you simply reexec toplevel make? I assume you mean reexec in a "clean" state, not just after make has failed (in which case the rule is found). No, it does not go away if you reexec make just after 'make clean'. In other words, this always happens: - make clean - make [make_options] -> FAIL (no rule found) - make [make_options] -> SUCCESS (rule found) Created attachment 148139 [details]
reproducer
The problem boils down to this reproducer.
What I think happens is that make doesn't take into account the files that are
created during the course of make execution itself. During the second
execution, the files are already here, and hence make finds the implicit chain.
Furthermore this only holds for implicit rules, be they old-style (.b.o) or
new-style (%.o: %.b). When the rule is made explicit, it works.
Session snapshot:
$ make clean
rm -f *.[bo]
$ make
touch a1.b
make: *** No rule to make target `a1.o', needed by `all'. Stop.
$ make
touch a1.b
cp a1.b a1.o
Thanks for the nice testcase. Yes, this is exactly what I observed too (affects files created by make, and only implicit rules). Explicit rules are unpractical in my case (many targets), so my current workaround is to use several consecutive calls to make in my rpmbuild setup. Shouldn't this bug be filed upstream ? ( i.e http://savannah.gnu.org/bugs/?group=make ) I grepped through upstream bug tracker, and found this: http://savannah.gnu.org/bugs/?func=detailitem&item_id=15583 """ You are seeing this problem because you are hiding information from make. You have a rule, "copies", that creates three different .c files. However, only one .c file lists "copies" as a prerequisite. Even if all of them listed it, make doesn't know that invoking the rule "copies" once creates all three source files. Because make caches directory information internally, it doesn't realize that files were created as a side-effect of invoking the "copies" target. """ This is pretty much what we see. The workaround is to mark the dependencies explicitly: all: a1.o .b.o:; cp $*.b $*.o a1.b:; touch a1.b clean:; rm -f *.[bo] .PHONY: clean all .SUFFIXES: .b The reason lies in the fact that make doesn't update the contents of directories. There was a bug reported on this: https://savannah.gnu.org/bugs/?443 Also in that bug, the reason that is stated is that make doesn't know about the files you are about to create. I don't know what's required by posix, or whether this issue is covered at all. Chances are, what GNU make does is allowed. I'm closing this bug as wontfix anyway... directory caching is reportedly too great a performance boost to lose for several obscure makefiles. |