Here is a list of the more common errors you might see generated by
make, and some information about what they mean and how to fix
make errors are not fatal, especially in the presence
- prefix on a recipe line, or the
-k command line
option. Errors that are fatal are prefixed with the string
Error messages are all either prefixed with the name of the program (usually ‘make’), or, if the error is found in a makefile, the name of the file and line number containing the problem.
In the table below, these common prefixes are left off.
These errors are not really
make errors at all. They mean that a
make invoked as part of a recipe returned a
non-0 error code (‘Error NN’), which
as failure, or it exited in some other abnormal fashion (with a
signal of some type). See Errors in Recipes.
*** is attached to the message, then the sub-process failed
but the rule in the makefile was prefixed with the
make ignored the error.
This means that
make could not understand much of anything
about the makefile line it just read. GNU
make looks for
various separators (
=, recipe prefix characters,
etc.) to indicate what kind of line it’s parsing. This message means
it couldn’t find a valid one.
One of the most common reasons for this message is that you (or
perhaps your oh-so-helpful editor, as is the case with many MS-Windows
editors) have attempted to indent your recipe lines with spaces
instead of a tab character. In this case,
make will use the
second form of the error above. Remember that every line in the
recipe must begin with a tab character (unless you set
.RECIPEPREFIX; see Other Special Variables). Eight spaces do not
count. See Rule Syntax.
This means the first thing in the makefile seems to be part of a
recipe: it begins with a recipe prefix character and doesn’t appear to
be a legal
make directive (such as a variable assignment).
Recipes must always be associated with a target.
The second form is generated if the line has a semicolon as the first
make interprets this to mean you left
out the "target: prerequisite" section of a rule. See Rule Syntax.
This means that
make decided it needed to build a target, but
then couldn’t find any instructions in the makefile on how to do that,
either explicit or implicit (including in the default rules database).
If you want that file to be built, you will need to add a rule to your makefile describing how that target can be built. Other possible sources of this problem are typos in the makefile (if that file name is wrong) or a corrupted source tree (if that file is not supposed to be built, but rather only a prerequisite).
The former means that you didn’t provide any targets to be built on the
command line, and
make couldn’t find any makefiles to read in.
The latter means that some makefile was found, but it didn’t contain any
default goal and none was given on the command line. GNU
has nothing to do in these situations.
See Arguments to Specify the Makefile.
A makefile specified on the command line (first form) or included (second form) was not found.
make allows only one recipe to be specified per target
(except for double-colon rules). If you give a recipe for a target
which already has been defined to have one, this warning is issued and
the second recipe will overwrite the first. See Multiple Rules for One Target.
This means that
make detected a loop in the dependency graph:
after tracing the prerequisite yyy of target xxx, and its
prerequisites, etc., one of them depended on xxx again.
This means you’ve defined a normal (recursive)
xxx that, when it’s expanded, will refer to itself (xxx).
This is not allowed; either use simply-expanded variables (‘:=’
or ‘::=’) or use the append operator (‘+=’). See How to Use Variables.
This means you forgot to provide the proper closing parenthesis or brace in your variable or function reference.
This means you haven’t provided the requisite number of arguments for this function. See the documentation of the function for a description of its arguments. See Functions for Transforming Text.
These errors are generated for malformed static pattern rules
(see Syntax of Static Pattern Rules). The first
means the target-pattern part of the rule is empty; the second means
there are multiple pattern characters (
%) in the target-pattern
part; the third means there are no pattern characters in the
target-pattern part; and the fourth means that all three parts of the
static pattern rule contain pattern characters (
part should not contain pattern characters.
If you see these errors and you aren’t trying to create a static pattern rule, check the value of any variables in your target and prerequisite lists to be sure they do not contain colons.
This warning and the next are generated if
make detects error
conditions related to parallel processing on systems where
makes can communicate (see Communicating Options to a Sub-
make). This warning is
generated if a recursive invocation of a
make process is forced
to have ‘-jN’ in its argument list (where N is greater
than one). This could happen, for example, if you set the
environment variable to ‘make -j2’. In this case, the
make doesn’t communicate with other
make processes and
will simply pretend it has two jobs of its own.
In order for
make processes to communicate, the parent will pass
information to the child. Since this could result in problems if the
child process isn’t actually a
make, the parent will only do this
if it thinks the child is a
make. The parent uses the normal
algorithms to determine this (see How the
Variable Works). If the makefile is constructed such that the parent
doesn’t know the child is a
make process, then the child will
receive only part of the information necessary. In this case, the child
will generate this warning message and proceed with its build in a
According to POSIX, a suffix rule cannot contain prerequisites. If a rule
that could be a suffix rule has prerequisites it is interpreted as a simple
explicit rule, with an odd target name. This requirement is obeyed when
POSIX-conforming mode is enabled (the
.POSIX target is defined). In
versions of GNU
make prior to 4.3, no warning was emitted and a
suffix rule was created, however all prerequisites were ignored and were not
part of the suffix rule. Starting with GNU
make 4.3 the behavior is
the same, and in addition this warning is generated. In a future version
the POSIX-conforming behavior will be the only behavior: no rule with a
prerequisite can be suffix rule and this warning will be removed.