This question already has an answer here:

I tried uninstalling PCL 1.7.2 which I had installed manually (without sudo apt-get) but when I tried to remove them using the apt-get remove command, terminal showed me those files cannot be uninstalled because they were not installed in the first place.

  1. How can I check if the files were installed correctly if I installed files using cmake

  2. How can I uninstall a file that I manually installed using cmake?

  3. How are the files installed using apt-get vs cmake different?

Note - similar question but using apt-get remove: How can you completely remove a package?

marked as duplicate by dobey, Pilot6, muru, Jacob Vlijm, Eric Carvalho Jan 20 '17 at 12:54

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


Executive Summary / TL;DR

Run make uninstall (or sudo make uninstall, if you had to run sudo make install) from the build directory where you ran make and make install. In builds configured with CMake, the build directory is usually not the top-level source directory. But besides that, uninstalling a program or library whose build was configured with CMake is no different from uninstalling other programs or libraries you have built from source code.

Some software supports make install but not make uninstall, in which case you may have to investigate what steps are taken when make install is run, or consult the software's documentation to see if it specifies what files it puts where. However, PCL does appear to support uninstallation via make uninstall.

Installation and Uninstallation with cmake and make

CMake is a system for configuring a build. Once configured, the build must usually be carried out using some build system. On Unix-like operating systems such as Ubuntu, builds configured with CMake almost always use the Make build system.

Most software that uses CMake requires that you create a separate build directory, usually called build, and run the cmake command from that directory. The build directory is populated with files necessary to perform the build. Then you run make in that directory. You should create the build directory wherever the instructions for the software you're building advise to put it. Usually it will be a subdirectory of the source tree's top-level directory (the highest level directory created when you unpacked the source tarball or invoked a version control system like git or bzr to download the code).

When you run make, it finds and reads a makefile -- usually called Makefile -- that contains a list of targets, instructions for building the targets, and how the targets depend on one another. Usually the default target, which you do not have to specify, builds the software, and the install target, which you do have to specify, installs it.

Many makefiles contain additional targets. The most common are:

  • A check or test target that tests the software that has been built. make check or make test may be run before make install, and it is usually advisable to do so.
  • An uninstall target that uninstalls the software by removing the files created by running make install. (Occasionally make uninstall has other behavior as well, to undo actions of make install other than copying files, but usually it's just a matter of deleting files.) Not all software has an uninstall target, but these days most does.
  • A clean target to delete files from the source or build directory that were created during the build. Nearly all makefiles have this.

There are a few other relatively common targets like distclean and realclean that are less relevant to CMake. However, it's useful to know that if you're configured a build by running a configure script (./configure) rather than CMake, then the configuration can usually be erased by running make distclean.

A developer using CMake must write code to generate an uninstall target -- CMake does not do this automatically. However, like many developers, the developers of PCL have done this and make uninstall should work. See the next section ("A Step-By-Step Example") for details.

To uninstall software whose makefile supports an uninstall target:

  • The directory from which you ran make install (or sudo make install) is the directory you must return to, to run make uninstall (or sudo make uninstall). For software that does not use CMake, this is usually the top-level directory of the source tree. But for software that does use CMake, it usually is not -- instead, it is usually a separate build directory.
  • When installing software manually from source, it is best to keep the source code and all files created during the build, so you can uninstall the software easily. Therefore, once you have run make install, it's best not to run make clean (nor to manually delete any files).
  • However, if you did run make clean or delete the software's source code or build directory, it is still usually possible to uninstall successfully. Simply follow the same build steps, with the exact same version of the software, configured and built with the same options (or none if you didn't customize it), to get to the point where you can run make uninstall (or sudo make uninstall). For some software you may actually even have to run make install again first, which will usually overwrite the files from the previous build. Then run make uninstall (or sudo make uninstall) as usual.

When there is no uninstall target and you need to uninstall the software, you'll have to examine what files it creates. You can run make -n install to show you what actions are taken by make install. You do not need to run make -n install with sudo (assuming the initial make didn't require sudo). When make is passed the -n flag, it performs a dry run, which typically should not change anything, and therefore shouldn't need to do anything requiring elevated privileges.

A Step-By-Step Example: PCL 1.7.2

It's useful to give an example, and I might as well use the software you're actually trying to uninstall as that example. PCL 1.7.2 does appear to use cmake to generate an uninstall target in its makefile, and therefore should support make uninstall.

In addition to examining uninstall_target.cmake.in, I have verified that the generated Makefile contains an uninstall target on a 64-bit Ubuntu 16.04 test system. However, I haven't finished building PCL so I can install it and then test sudo make uninstall. (My test machine is very slow, and PCL is big.) I plan to update this with additional information when I get the chance to do so, sometime after the build has finished.

When you installed PCL 1.7.2, you probably did something like this:

cd /usr/local/src
wget https://github.com/PointCloudLibrary/pcl/archive/pcl-1.7.2.tar.gz
tar xf pcl-1.7.2.tar.gz
cd pcl-pcl-1.7.2
mkdir build
cd build
cmake ..
make -j2
sudo make -j2 install

That is based (loosely) on the official instructions, but of course may not be exactly what you did. In particular, I downloaded and unpacked pcl-1.7.2.tar.gz in /usr/local/src. If you put it somewhere else then you'll have to replace /usr/local/src with wherever you did put it.

Changing /usr/local/src if necessary, you should be able to uninstall the software by running:

cd /usr/local/src/pcl-pcl-1.7.2/build
sudo make uninstall

Even if you ran make -j2 install to allow multiple operations to take place simultaneously, there should be no need for you to pass the -j2 flag when you run make uninstall.


In looking at the install instructions, it uses cmake and make. To uninstall, you should be able to:

In terminal...

  • cd folder_of_original_source_code # folder where you did the cmake
  • sudo make uninstall # to uninstall

When you installed PCL, you actually performed two steps:

  • You compiled the software, which any user can do in his or her own home directory
  • You installed the software system-wide, which only root can do

The installation itself (the sudo make -j 2 install commend in your case) is a script written by the authors of PCL. There is no telling what this script has done to your system, apart from reading the script source code. There is no standardization here, the script can do whatever it wants to your machine, including erasing important files, or modifying configuration in ways standard Ubuntu software does not expect.

Since there is no telling what the install script has done to your system, there is no way another program (such as APT) can undo the changes after they have been done. Your best bet in such a case is either to save the output of the install script (to read it later and undo the changes by hand), or to restore a system backup.

A deb package is different. The author of the package has performed the compilation stage on his or her own machine, examined the files produced and put them all in order, as they should be on a proper Ubuntu system. He or she has then put them in a zip file of sorts, which is the deb package. The author also has written installation and uninstallation scripts, in case the software needs some other modifications done at the time it is installed. The author also has written all the necessary metadata, notably which other packages (such as shared libraries) this one depends on in order to run.

When APT installs a package, it keeps tracks of which files were extracted, and so is able to remove them later.

Now, to answer your questions:

Q1. Unless you saved the output of the PCL install script (supposing this output included a complete and truthful detail of all that was being done), or you compare the contents of your hard drive with a backup you performed before you installed PCL, there is no way to know if the files were installed correctly. The best you can do is run the software and see if it runs fine.

Q2. There is a possibility that the creators of PCL have written an uninstall scripts, maybe running sudo make uninstall will do something useful. You would have to consult the documentation of PCL for that. Otherwise, you have to remove the files individually, by hand.

Q3. The installed files themselves are not different. What is different is the program used to copy them in the system directories. apt-get keeps track of what was installed from deb files and can remove it. cmake does it its own way, unknown to APT.


Brief overview of apt-get

apt-get installs programs that have been specifically packaged. The apt configuration had detailed information about where all the components of the package will be installed. It also stores information on the system exactly which files and been added to the system. The information includes the removal steps for the files.

When you decide to use apt-get to remove the files, it'll use this information to safely remove the files that has been added to the computer.


Cmake is a utility to compile and install programs. An individual, including you, can create an application as simple as "Hello World" and use Cmake to compile and place the program wherever you decide to put it.

The apt-get utility will not be aware of all the programs you decide to place anywhere on your computer. If the author wanted the program to be installed via apt-get they would configure it for it and provide a .deb package for the installer.

Removing programs not installed using apt-get

To remove manually installed programs, you would have to follow the authors provision for the removal. The cmake command as well as the make command has configuration files that allow you to specify things such as build, install, install with special conditions, and uninstall. Those features are up to the developer of the program.

Many programs comes with steps (a readme.txt file) for installing and uninstalling. You'll have to look at the package content to see what the author has provided. If there hasn't been provided uninstall steps, you'll have to manually remove it by looking for the actual files that has been added to your computer by the program.

Check if the developer as provided an uninstall target with:

$ cmake uninstall

Finding the files from the program:

Look for an install_manifest.txt file that may be created after performing the install. This should show you where the files are.

Another way to find the files from the program is to study the CMakeList.txt file. Look for the directories that refers to output. It'll usually specify where the binaries and the libraries will be placed.

You can also find out what files were added to your system with find. Specify a window during the time when you performed the install, and you'll get a list of files. There are some variations of this command.

You can use these steps to find files that was creating in a window between Jan 18 at midnight and Jan 19 at midnight. Instead of using zero's you could specify a specific hour and minute.

Create a timestamp file for the start of time frame:

 $ touch -t 201701180000 starttime

Create a timestamp file for the end of the time frame:

 $ touch -t 201701190000 starttime

That is in the format of: YYYYMMDDHHMM

Then run:

$ find ~/ -mount -newer starttime ! -newer endtime > find.out

Now examine the find.out text file and you will see all the files that was created in that window of time. You can automatically eliminate many files like the ones in your home directory. This will leave you to look mainly at the binary files.

  • and how can we look for the actual files that have been added since I don't have a screenshot of the system before installation of that package – PallavBakshi Jan 19 '17 at 22:29
  • @PallavBakshi Give me about 15 minutes to provide formatted steps to my answer. I'll nudge you with a comment when the answer has been updated. – L. D. James Jan 19 '17 at 22:32
  • @PallavBakshi I updated my answer. If you still have problems finding the files, there are other resolutions, but as I mention originally, look for a provided Readme.txt file which might already have the provided steps. – L. D. James Jan 19 '17 at 23:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.