URL: <https://savannah.gnu.org/bugs/?58556>
Summary: Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this Project: make Submitted by: log65536 Submitted on: Sun 14 Jun 2020 01:39:34 AM JST Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: None Operating System: None Fixed Release: None Triage Status: None _______________________________________________________ Details: In an empty directory: $ make .o cc -o .o cc: fatal error: no input files compilation terminated. make: *** [<builtin>: .o] Error 1 This was unexpected, because no prerequisites exist in the directory. Looking into the relevant parts from "make -dp .o": Considering target file '.o'. File '.o' does not exist. Finished prerequisites of target file '.o'. Must remake target '.o'. ... .o: $(LINK.o) $^ $(LOADLIBS) -o $@ It doesn't mention trying implicit rules, so it seems to be matching the builtin as an explicit rule. Is this intentional? Even if this is by design, there should be a way to turn it off from the makefile. I tried: $ printf 'MAKEFLAGS=r \n .SUFFIXES:' | make - .o cc -o .o cc: fatal error: no input files compilation terminated. make: *** [<builtin>: .o] Error 1 This is strange, because now "make -p" doesn't mention any rules involving ".o" at all, yet it still manages to call the linker. I should note that "make -r" from the command line does work properly, and "MAKEFLAGS=r" does disable the bulitins for targets not named like a default suffix. I also note that I found this while trying to fix a buggy makefile. Being able to actually work with a target named ".o" is not important here, it is just that a more correct error message might have helped while debugging the makefile. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?58556> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/