503

I'm trying to use GCC (linux) with a makefile to compile my project.

I get the following error which is can't seem to decipher in this context:

"No rule to make target 'vertex.cpp', needed by 'vertex.o'. Stop."

This is the makefile:

a.out: vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o g++ vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o main.o: main.cpp main.h g++ -c main.cpp vertex.o: vertex.cpp vertex.h g++ -c vertex.cpp edge.o: edge.cpp edge.h g++ -c num.cpp vlist.o: vlist.cpp vlist.h g++ -c vlist.cpp elist.o: elist.cpp elist.h g++ -c elist.cpp vnode.o: vnode.cpp vnode.h g++ -c vnode.cpp enode.o: enode.cpp enode.h g++ -c node.cpp
Improve this question
1
  • 5
    A typical example you 'make' the source file 'not exist' is by resetting VPATH or SRC variable by mistake when you have to add to it. I mean usnig VPATH= instead of VPATH+=. This makes Makefile file can't see the files when the file actually is there. Commented May 12, 2017 at 0:05

23 Answers 23

Reset to default
573

That's usually because you don't have a file called vertex.cpp available to make. Check that:

  • that file exists.
  • you're in the right directory when you make.

Other than that, I've not much else to suggest. Perhaps you could give us a directory listing of that directory.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Yes, Some of my classes don't have .cpp files, so they weren't there- causing the error. Thanks.
you can also get such an error if there are some header files that you removed but are still in your Makefile
Also, make sure you save your Makefile after editing it... That is what got me. I did all my edits then forgot to press CTRL+S
No rule to make target 'X' when X is simply missing. What a bad wording that will survive the centuries because everybody gets used to it.
yeah but what does that mean?
106

In my experience, this error is frequently caused by a spelling error.

I got this error today.

make[1]: *** No rule to make target maintenaceDialog.cpp', needed bymaintenaceDialog.o'. Stop.

In my case the error was simply a spelling error. The word MAINTENANCE was missing it's third N.

Also check the spelling on your filenames.

Improve this answer

2 Comments

The meta why, in this case is because of explicitly listing the object/source/header relationships. If newer tools like SubCons or CMake are not to taste, gcc -MT and gnu make patterns can solve this. See also.
In my case the path was wrong like ../../src/file.c but actually it was ../../src/folder/file.c
36

The more common reason for this message to be printed is because you forgot to include the directory in which the source file resides. As a result, gcc "thinks" this file does not exist.

You can add the directory using the -I argument to gcc.

Improve this answer

1 Comment

The -I directive is for include files and has nothing to do with where files like vertex.cpp can be found by make.
20

In my case it was due to I crated file like MakeFile instead it should be Makefile.

Improve this answer

Comments

18

In my case I had bone-headedly used commas as separators. To use your example I did this:

a.out: vertex.o, edge.o, elist.o, main.o, vlist.o, enode.o, vnode.o g++ vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o

Changing it to the equivalent of

a.out: vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o g++ vertex.o edge.o elist.o main.o vlist.o enode.o vnode.o

fixed it.

Improve this answer

Comments

15

One of frequent mistakes might be typo in another file name.

You example is quite straightforward but what may sometimes confuse are messages of make itself. Lets consider an example.

My folder contents is:

$ ls -1 another_file index.md makefile

Whereas my makefile looks like

all: index.html %.html: %.md wrong_path_to_another_file @echo $@ $<

Although I do have index.md where it should be and there is no mistake in the name of it, the message from make will be

make: *** No rule to make target `index.html', needed by `all'. Stop.

To be honest the message is confusing. It just says, that there is no rule. In fact, it means that the rule is wrong, but due to wildcard (pattern) rules make cannot determine what exactly caused the issue.

Lets alter makefile a little, which is to say replace patterns with explicit rules:

index.html: index.md wrong_path_to_another_file

And now the message we get will be:

make: *** No rule to make target `wrong_path_to_another_file', needed by `index.html'. Stop.

Miracle! The following might be concluded:

  • Messages of make depends on rules and does not always point to the root of problems

  • There might be other problems in your makefile different from specified by this message

Now we've come up with the idea of checking other dependencies in a rule as well:

all: index.html %.html: %.md another_file @echo $@ $<

Only this will provide us with the desired result:

$ make index.html index.md
Improve this answer

2 Comments

Is there a way to write the makefile with pattern rules - short of listing every target - so that it correctly complains about the file that it's actually missing? In this case wrong_path_to_another_file
@creanion, I havent check whether wildcard works differently, you may try somthing like objects := $(patsubst %.c,%.o,$(wildcard *.c)) foo : $(objects) cc -o foo $(objects)
14

Is that it exactly? Remember that Makefile syntax is whitespace aware and requires tabs to indent commands under actions.

Improve this answer

Comments

9

The problem I found was even sillier than what other folks have mentioned.

Our makefiles get passed lists of things to build. Someone added TheOtherLibrary to one of the lists, as shown below.

LIBRARYDIRS = src/Library LIBRARYDIRS = src/TheOtherLibrary

They should have done this:

LIBRARYDIRS = src/Library LIBRARYDIRS += src/TheOtherLibrary

Had they done it the second way, they would not have wiped out the Library build. The plus in += is very important.

Improve this answer

Comments

7

In my case it was due to a multi-line rule error in the Makefile. I had something like:

OBJS-$(CONFIG_OBJ1) += file1.o file2.o \ file3.o file4.o \ OBJS-$(CONFIG_OBJ2) += file5.o OBJS-$(CONFIG_OBJ3) += file6.o ...

The backslash at the end of file list in CONFIG_OBJ1's rule caused this error. It should be like:

OBJS-$(CONFIG_OBJ1) += file1.o file2.o \ file3.o file4.o OBJS-$(CONFIG_OBJ2) += file5.o ...
Improve this answer

Comments

5

If you are trying to build John the Ripper "bleeding-jumbo" and get an error like "make: *** No rule to make target 'linux-x86-64'". Try running this command instead: ./configure && make

Improve this answer

Comments

5

In my case, the reason for this error was that a folder name had a space, renaming the folder solved the problem

Example:

~/foo bar/mymoduledir

renaming the folder foo bar to foo_bar:

~/foo_bar/mymoduledir

fixes the problem

Improve this answer

1 Comment

Same here. A folder several levels up had a space in it. I believe it's when the Makefile has a $PWD entry - it injects the true value, but doesn't escape the spaces.
4

In my case, the error message referred to an old filename, which did no longer exist because it was renamed. It turned out that the outdated information did not come from the Makefile, but from files in .deps directories.

I ran into this error after copying files from one machine to another. In that process, I assume the timestamps got in an inconsistent state, which confused "make" when running multiple jobs in parallel (similar to this bug report).

Sequential builds with make -j 1 were not affected, but it took me a while to realize because I was using an alias (make -j 8).

To clean up the state, I removed all .deps files and regenerated the Makefile. These are the commands that I used:

find | grep '.deps' | xargs rm find | grep '.deps' | xargs rmdir autoreconf --install # (optional, but my project is using autotools) ./configure

After that, building worked again.

Improve this answer

Comments

4

In my case the path is not set in VPATH, after added the error gone.

Improve this answer

Comments

4

My case was a missing $:

Instead of:

(LINK_TARGET): $(OBJS)

Should be:

$(LINK_TARGET): $(OBJS)

Edit:

I had this same problem, but now due to another reason, it was due to an echo command inside my .bashrc file.

Improve this answer

Comments

3

Another example of a weird problem and its solution:

This:

target_link_libraries( ${PROJECT_NAME} ${Poco_LIBRARIES} ${Poco_Foundation_LIBRARY} ${Poco_Net_LIBRARY} ${Poco_Util_LIBRARY} )

gives: make[3]: *** No rule to make target '/usr/lib/libPocoFoundationd.so', needed by '../hello_poco/bin/mac/HelloPoco'. Stop.

But if I remove Poco_LIBRARIES it works:

target_link_libraries( ${PROJECT_NAME} ${Poco_Foundation_LIBRARY} ${Poco_Net_LIBRARY} ${Poco_Util_LIBRARY} )

I'm using clang8 on Mac and clang 3.9 on Linux The problem only occurs on Linux but works on Mac!

I forgot to mention: Poco_LIBRARIES was wrong - it was not set by cmake/find_package!

Improve this answer

Comments

3

There are multiple reasons for this error.

One of the reason where i encountered this error is while building for linux and windows.

I have a filename with caps BaseClass.h SubClass.h Unix maintains has case-sensitive filenaming convention and windows is case-insensitive.

C++ why people don't use uppercase in name of header files?

Try compiling clean build using gmake clean if you are using gmake

Some text editors has default settings to ignore case-sensitive filenames. This could also lead to the same error.

how to add a c++ file in Qt Creator whose name starts with capital letters ? It automatically makes it small letter

Improve this answer

Comments

3

This message can mean many things clearly.

In my case it was compiling using multiple threads. One thread needed a dependency that another thread hadn't finished making, causing an error.

Not all builds are threadsafe, so consider a slow build with one thread if your build passes other tests such as the ones listed above.

Improve this answer

2 Comments

how to do a slow build ?
@GuidoG Set your threadcount to 1 (add -j1 to the build flags).
2

In my case, the source and/or old object file(s) were locked (read-only) by a semi-crashed IDE or from a backup cloud service that stopped working properly. Restarting all programs and services that were associated with the folder structure solved the problem.

Improve this answer

Comments

2

This error occurred for me inside Travis when I forgot to add new files to my git repository. Silly mistake, but I can see it being quite common.

Improve this answer

Comments

1

In my case the issue popped out after removing some of the header files and .c files and the project didn't compile.

Running clean and then build compiled the project

Improve this answer

Comments

1

This error clearly indicates that in your cmake is missing the target to install. Encountered this when wrote a Cmake as below:

cmake_minimum_required(VERSION 3.10.2) project(project_name) include_directories( ${CMAKE_HOME_DIRECTORY}/xxxx ) //called some subfolders with their cmake and worked fine add_subdirectory(ABC) //this had executable target and intall location etc //if commented above there was no target to install (there are no source files/no executable/library to create??

Reference taken from: https://cmake.org/cmake/help/book/mastering-cmake/

Improve this answer

Comments

-1

In my case, it was due to me calling the Makefile: MAKEFILE (all caps)

Improve this answer

Comments

-1

i have write mistake the file name like MakeFile i also get the make: *** No rule to make target `gen'. Stop. i find i mistake the file name i rename to Makefile and then i get okay.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.