The bottom line is that this command in the form of “make install” or “sudo make install” cannot be used in modern distributions.

But the authors of the programs in the installation manuals write that you need to use this command, you might say. Yes, they write. But this only means that they don’t know what distribution you have, or whether it’s a distribution at all, maybe you joined a sect and smoked reading LFS and now decided to compile their creation for your chthonic system. And make install is a universal, although often incorrect, way to do this.

Lyrical digression

As you know, for normal operation, most software must not only be compiled, but also correctly installed on the system. Programs expect to find the files they need in certain places, and these places on most *nix systems are hard-coded into the code at compile time. In addition to this aspect, the main difference between the installation process in linux/freebsd/whatever and that in Windows and MacOS is that the program does not just put a bunch of files in a separate directory in Program Files or /Applications, but “spreads” itself throughout file system. Libraries go to lib, executable files to bin, configs to etc, various kinds of data to var, and so on. If you suddenly need to update it, then all this must first be cleaned somehow, because... using new version Remnants of files from the old one can lead to completely unpredictable consequences, often not good. The probability of this event is not so high, but do you need it on a production server?

So what?

So, if you did the installation directly via make install, then it’s normal to remove or update the software, you most likely you can't. Moreover, installing a new version over the old one will most likely will overwrite your changes in configs. make install does exactly what it is told to do - it installs files in the right places, ignoring the fact that something is already there. After this process, it is absolutely impossible to obtain any information about what was placed where and in a digestible form. Sometimes, of course, the Makefile supports the uninstall action, but this is not so common, and it is not a fact that it works correctly. In addition, storing the unpacked source tree and build rules for uninstallation is somehow strange.

How to fight?

Since packages in distributions tend to be updated sometimes, to solve this problem they came up with such a thing as package manager. When using it, the installation goes something like this:

1. an archive formed in a certain way is taken
2. information is extracted from it about what it is, what version it is, what it depends on, what it conflicts with, whether it is necessary to run any scripts to install/uninstall/configure, etc.
3. Direct installation steps in progress
4. All data about where and what was delivered is added to the package manager database.

In this case, when updating, you can painlessly remove unnecessary things, and at the same time see if the files marked as configuration have changed in the system and ask what to do if their contents are different in the new version. In addition, the package manager will not allow you to overwrite the files of one package when installing another. In general, it can do a lot of useful things.

If you, out of ignorance/laziness, copied and pasted make install from the instructions, then files appear on the system that the package manager does not know about. With all that it implies, if what was listed earlier is not enough for you.

What to do?

You can, of course, configure the source tree so that everything is installed somewhere in /opt/mycoolapp/, and then, if necessary, delete it manually, but a lot of unpleasant things can come out here, starting with the fact that the program expects that it can load your libraries, and the loader knows nothing about the directory where they are located, ending with the fact that the program author can expect that, for example, if he puts a file, say, in $prefix/share/xsessions/, then the display manager will pick it up. Not to mention the paths for pkgconfig and so on.

So you need to collect the package.

I don’t have time to fuck with this, I’d better do make install again, everything is simple and clear!

Calm down, calm down. He's tied to our legs. Everything is not as scary and complicated as it seems at first glance.

checkinstall

This wonderful utility, when launched instead of make install, will ask several questions, after which it will build and install the package. That’s it, when updating you won’t have any problems with cleaning out old junk.

Building the deb package manually

If you are not inclined to trust such automation (which sometimes still messes up) or you want to make a couple of changes, but are still too lazy to deal with the normal process of building packages, then you can assemble the package manually. I give a way to build it for systems on Debian database, because I am best familiar with them. It is not ideologically correct, but the output is a completely correct package without the use of additional entities. This is done as follows.
First, we assemble the software with the --prefix=/usr and --exec-prefix=/usr parameters pre-specified for configure or autogen.sh.
Next, we install it in a temporary directory. We write:

Fakeroot make install DESTDIR=`pwd`/tempinstall
After which we get the entire set of files in the newly created directory. By the way, we are now in a fakeroot environment, i.e. you can change the owner and access rights of files without any restrictions, but physically you will remain the owner of the system. The software inside the fakeroot session will receive changed information, which will allow files with the correct rights to be archived.
Next, create a DEBIAN directory in the “package root” and add a list of all files that should go into /etc into DEBIAN/conffiles:

Cd tempinstall mkdir DEBIAN find etc | sed "s/^/\//" > DEBIAN/conffiles
Then we create a DEBIAN/control file with the following content:

If necessary, you can also create preinst, postinst, prerm and postrm scripts there.

That's it, we do dpkg -b tempinstall and the output is tempinstall.deb, which you can use dpkg -i to install, update or remove correctly.

The “correct” process of preliminary creation of a source code package is beyond the scope of this note, and therefore will not be described, but for your purposes it is usually not necessary.

Conclusion

As you can see, there is absolutely nothing complicated here, but following these steps will save you from a huge number of problems in the future.

And also other systems have to be installed additional programs. In operating rooms Windows systems everything is very simple, as a rule, there is an installer setup.exe that helps install the software. But in Linux things are a little different. How to install programs on Linux? Now let's look at this question.

Linux has several types of installation packages and each distribution has its own package format. Fedora, Mandriva, Red Hat and Suse distributions use the standard Linux RPM installation developed by Red Hat. The RPM package file is typically named program_name-version.rpm.

Another very popular format is DEB. Used in Debian, Ubuntu, Knoppix and Mepis. Has a name program_name-version.deb.

And we approached the archives. Usually these are .tar , .tar.gz , .tgz extensions. They should be unpacked and then installed/compiled.

You need to perform the program installation procedure as a superuser.

Quick navigation

Installing programs on Debian, Ubuntu

There are many tools for working with DEB packages, but the most commonly used is apt-get, which is included in the standard set of tools. To install the application, enter the command:

apt-get install package_name

For removing:

apt-get remove package_name

APT stores a local database of all packages available for installation and links to where to get them. This database needs to be updated from time to time with the command:

apt-get update

To update outdated packages (programs) on the computer, enter the following commands:

apt-get update ; apt-get upgrade

Installing programs on Fedora, Red Hat

A utility similar to APT is yum. To download and install the package from the configured repository, write the command:

yum install package_name

yum remove package_name

The local yum database is not saved, so there is no need to update. To install updates, use the command:

yum update

Select something specific to update:

yum update package_name

Installing programs in Mandriva

Mandriva has its own set of tools for working with packages, called urpmi. For installation:

urpmi package_name

To delete:

urpme package_name

Update the local database with the list of packages:

urpmi. update -a

To install updates:

urpmi --auto-select

Installing programs from archives (tarballs)

For archives compressed using GZIP (gz, gz2, etc.) we do this:

tar -xvz f filename

For archives compressed using BZIP (bz, bz2, etc.) it’s a little different:

tar -xvjf filename

Tar commands:

• x – extract files from the archive;
• v – detailed display of information on the screen;
• f – Required option. If not specified, Tar will try to use tape instead of file;
• z – process archive compressed using gzip;
• j – process an archive compressed using bzip.

After executing the command, a folder will be created with a name similar to the name of the package. Then you need to open this created folder with the command:

cd folder_name

Next, in the unpacked archive, read the instructions in the README file, if any. In any case, if the program is compiled in the form executable file, then the package will contain a .sh file, usually called install.sh

Hi all!

This is a short note for Linux beginners about what these three wonderful commands mean and what they are needed for. Let's start, as they say, from the beginning. Most programs must be compiled before use, that is, converted from text that a person can understand into a set of ones and zeros that a computer can understand. The process is divided into three stages: configuration, assembly and installation. Details under the cut :)

./configure

This command searches for libraries and header files necessary for compilation (this is for programs partially or completely written in C/C++ and similar languages), as well as setting special parameters or connecting special libraries, if ./configure will find everything he needs, he will create Makefiles- file required to build the program

You can configure the configurator parameters using the keys and arguments of these same keys, for example:

./configure --prefix=/opt/my_program

With a key --prefix= You can specify a directory that will later act as a prefix for your program (that is, the root directory). This is due to the fact that in the world of Linux and not only, there is a special Hierarchy of the File System (HFS) according to which any program must be compiled and installed in order to work without errors.

There are three main file system prefixes against which most programs are configured, namely:

• / - root directory of the operating system, so-called ROOT
• /usr - directory where user environment applications are located
• /usr/local - an additional directory for user programs compiled manually, specifically for operating system didn't turn into a dump

If you open any of these directories, you can see a very similar structure, at least there will be folders: bin, etc, include, libs, sbin.

If you run ./configure without keys, then the default prefix (directory in which the compiled program will be installed) will be /usr/local, remember this, if you can’t run your program, you may not have the path to PATH.

Except the key --prefix In the configurator, as a rule, there are many other keys, you can see them all if you run:

./configure --help

make

The most important and simple command/program launches the application compilation procedure from source code. For your work this program uses special files Makefiles, which describe in detail the process of building the application with all the parameters that we specified to the configurator. The result of a successful make command will be a compiled program in the current directory.

make install

This command directly installs the application into the directory specified at the configuration stage; after executing the make install command, you can run the newly installed program.

Afterword

In order not to write three commands in turn, you can write them in one line:

./configure && make && make install

&& - this is the AND operator, which came from the C/C++ language, however, from the shell’s point of view, it means that the next command needs to be executed only if the previous command has completed successfully, this is very convenient if one of the stages ends with an error.

In fact, make install can also perform a build, because the install task depends on the all task (that is, directly building the application), this means that the make step can be skipped and only two commands can be executed if you write them on one line:

./configure && make install

Good luck to you! And thanks for reading!

There are situations when you need the latest version of a program, but it is not in the repository of your distribution. Or this program is not added there at all for some reason. There are several options to get this program, one of them is to build the program from source code, directly for your distribution. Of course, we are talking about open source programs. source code:)

Assembly (compilation) of a program is the transformation of its source code, written in some compiled programming language (for example, C++), which is understandable to the programmer, into binary code (a sequence of zeros and ones), which is understandable central processor computer. Not all programming languages ​​are compiled. For example, code in Python can be run immediately, without translating it into binary code (although this is also possible). To build a program, it is advisable to have a fairly powerful, and preferably multi-core, processor. Never compile programs on laptops! This will have an extremely negative impact on their life expectancy (they are not designed for such loads, unless of course you have gaming laptop).

There is nothing complicated about building a program from source code. The main thing to remember is one rule: in a package distribution, you should never use the method make install. Otherwise, you will get a big pile of problems in the future. When you realize that you wanted to remove the program (installed in this way), but the package manager does not know about it. And the program itself consists of several hundred files scattered across different directories. Scary? Therefore, in packaged distributions, the program must be assembled into, in fact, a package. Then it can be removed without problems, if something happens. I wrote this because many of the guides I've come across on how to compile programs on Linux describe exactly make install. You can remove a program installed this way only in two cases:

• if you still have an archive with its code (then you can run make uninstall);
• if the program's source code supports it.

Don't use make install!

I note that not every program can be assembled in the same way. Therefore, you should always read the assembly instructions, which are in the archive with the source code. It happens that the developer put a script there, which when launched does everything itself (compiles and installs, but we remember about make install), or it may not be suitable for assembly make, but you need a different assembly system. Also, to build a program, you will need to install the assembly dependencies necessary for it (these are packages with the prefix -dev). In order to quickly assemble a program into a package in order to be able to install or uninstall it without problems, there is a utility called checkinstall. It will allow you to create a package native to the system ( deb or rpm), which will allow you to use the standard package manager to install/uninstall it

To build programs in GNU/Linux, you use (mostly) the program make, which runs instructions from Makefile, but since there are many GNU/Linux distributions, and they are all different, in order to compile the program, for each distribution you need to separately specify the paths where the libraries and header files are located. Programmers cannot study each distribution and create Makefiles for each separately. Therefore, they came up with configurators that “study” the system and create a Makefile in accordance with the knowledge gained. To build we need compilers: they are specified in the package dependencies build-essential, so it's enough to install it with all the dependencies. Still needed autoconf And automake. If the program is written in Qt, then usually it is assembled either by a team qmake(of course it must be installed), or by opening the project file in some IDE(usually Qt Creator) and assemblies in it.

First you need to prepare the system. To do this, let's set necessary set tools:

S udo apt install build-essential gcc devscripts git fakeroot automake autoconf

You can get the source code different ways. Download from the Internet (for example, from the developer’s website), clone a repository with source code, and so on. In the first case, in general, everything is clear. In the second: suppose that the program is in the git repository (on GitHub, For example). We can go to this repository and download the archive with the code from there

So copy the entire repository to yourself (as developers do). For example, let's take the program mgba. This is an emulator game console Nintendo GameBoy. Repository address. Let's copy it for ourselves:

git clone https://github.com/mgba-emu/mgba.git

In your home directory you will have a directory with its source code. On the same page of the program, there are assembly instructions.

We read carefully. Open a terminal and go to the directory with the source code:

cd ~/mgba

And we assemble the program:

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..
make
sudo checkinstall -D

You will be asked for some information (package name, version, etc. It is advisable to fill out all fields). After assembly, in the directory above (that is, in mgba), a deb package with the program will appear. Now you can simply install it by double clicking or using the command sudo dpkg -i packagename.deb. If during assembly you start to receive error messages, read them carefully. There may be some assembly dependencies missing.

Let's take a slightly different example, which uses a configurator. In this case, in the directory with the source code, the scripts are located: autogen.sh, configure and the like. Autogen.sh generates a script configure, with which you can already configure the program before assembly (yes, yes, the configurator of the configurator). As always, do not forget to read the instructions for assembling a particular program. Let's assume that the archive contains the autogen.sh script. Let's execute it:

./autogen.sh

Once executed, the configure file should appear. To see what parameters you can build the program with, enter:

./configure --help

Review all available options. Typically, this can be support for various plugins, assembly with an alternative interface, even assembly for a different processor architecture. Let's say a program uses an interface written in GTK+ 2, but has an alternative on GTK+ 3. Then the program configuration will look like this:

./configure --with-gtk3

./configure --enable-gtk3

Everything will be described in detail in the instructions. There is a certain set of standard options (after entering ./configure --help, they are written first), such as specifying the installation path:

Prefix=/usr

After running configure and successfully configuring the code, you can run the build:

sudo checkinstall

That's all. As you can see, there is nothing complicated here. Although, I will not hide, it happens that the developer did not bother with high-quality assembly instructions. But this rarely happens. I would also like to draw your attention to the following: resort to building a program from source code only as a last resort. If you are using Ubuntu LTS, then look (using Google) to see if the program you need (or a newer version) is available in a more recent release of Ubuntu. Or perhaps there is

terminal and commands

Have you often encountered the fact that the required version of an application for your architecture is simply not available in the Ubuntu distribution, but this program is available on the developers’ website in the form of source code in the .tar.gz archive. I think many people know it this situation, but not everyone continued to look for ways to solve this issue and simply looked for another analogue of the application or a slightly older version and continued to work.

I would immediately like to add a few words for newcomers to Linux; before doing anything from this article, thoroughly study the terminal and the commands that are used to work with it, read mana or materials on the net.

• For application builds we will, of course, need developer tools, in our case this is a compiler and other accompanying programs, main job Of course, we will be executed by the make utility, and command line(the terminal) will be like our kitchen where we will be prepare/assemble/install our application from source. IN Linux terminal available by default, for your convenience you can of course install any other more functional one that you are used to, for example I use Guake, there are a lot of possibilities compared to the standard one, where it is easy to configure both copying and pasting commands or any text using CTRL +C,CTRL+V and much more, which makes working with the console more comfortable.
• 1. Where to start when building applications from source is, of course, download the application in the tar.gz or tar.bz2 archive, in my case this is, for example, the Gimp 2.9.2 application, although in our case the archive is not in tar.gz format, and tar.bz2, it doesn’t make any difference, download it, then right-click on the archive - Extract here.

This is probably the first stage, what do we do next? And then we launch the terminal and go to our unpacked folder with files:

Cd /home/linux/Downloads/gimp-2.9.2/ ls

• 2. Before starting to prepare the sources for assembly, I would advise you to first open and familiarize yourself with the INSTALL file, you will find a lot useful information, V this file describes how to install the application, what commands need to be executed and much more interesting things. Now I advise you to install additional package called auto-apt, it does a lot of routine work for you.

sudo apt-get install auto-apt

What does it mean to do a lot of routine work for me, you ask, if run application source configuration with the prefix of this package, for example in the form:

Auto-apt -y run ./configure

Of course, you can perform the configuration without the help of this package and simply run the command:

./configure

If you perform the configuration with the prefix - auto-apt -y run, then preparing sources for assembly will take place in automatic mode, that is, this command can automatically download and install all the necessary files and libraries for you and satisfy everything dependencies which will be required.

• 3. When real work not everything is so smooth, maybe in one case everything will go well and stage of preparing source code for assembly It will pass without errors, but in other cases, and these are probably the majority, you will encounter errors of various kinds, for example, there is not enough of one or another package for further preparation of the source code. In most cases, the name of the package that is missing is written.

We try to install the missing package with the command:

Sudo apt-get install package_name

In the event that a package is not detected when executing the command above, the following combination very often helps me out; we look for packages that we are missing in the cache:

Apt-cache search pakage_name

• After executing this command, you may find a suitable package, it often happens that you do not find a suitable package, but you can find an exact copy of the package but with dev prefix that is, a package like package_name-dev and you can use it to satisfy dependencies.
• 4. After successfully completing the configuration of the sources for the build, it is advisable to install the package checkinstall which makes it easier to assemble an application package for your distribution.

sudo apt-get install checkinstall

Install the package, then you can run the command:

Checkinstall -D

• Attribute -D will create a deb package, attribute -R will create an rpm package that is used in the distributions of Fedora, RHEL, ASP Linux, ALT Linux, Mandriva, openSUSE, there is also an additional attribute -S which will create a package used in Slackware.

In my case I am running on Ubuntu and ran the command with attribute -D, next we will assemble the application into a ready-made Deb format package, we will need some clarifying data, for example, such as adding a description to the package, since you are assembling it and, accordingly, the description is completely clean and is required of you brief information What is this application for? In my case, as I checked, the following fields are also automatically filled in:

1 - Summary: [ EOF ] 2 - Name: [ gimp ] 3 - Version: [ 2.9.2 ] 4 - Release: [ 1 ] 5 - License: [ GPL ] 6 - Group: [ checkinstall ] 7 - Architecture: [ i386 ] 8 - Source location: [ gimp-2.9.2 ] 9 - Alternate source location: 10 - Requires: 11 - Provides: [ gimp ] 12 - Conflicts: 13 - Replacements:

• As you can see, before the build there is a check to see if the configuration was completed successfully, if there are any unsatisfied dependencies or other conflicts; if everything is fine, then the package will be built without problems.

I previously installed it without building the package, running the commands:

Make make install

If you want to delete installed application, you should run the command:

Make uninstall

the command above will automatically delete those related to the application that you installed and will not affect anything third-party, it is advisable not to run through directories and execute it from the same application directory in which you worked, that is, prepared the configuration, etc.

Although everything went without errors, the whole process lasted a very long time, about 20 minutes until I installed Gimp from the source code, I managed to go make coffee and also watch the installation process, everything happens for a long time due to the fact that there are a lot of different folders scatter the application source files, each file has its own purpose and must be located in a specific directory, so after executing make install, the process of installing thousands of source files in the required directories occurs.

This is how installation of an application from source happens, yes, not everything is so simple at first glance, I didn’t say that it would be easy, but if you try, it very well develops your thinking and ways of finding solutions in a given situation, which It's even very good.

That's probably all, if you have questions about the material above, or you tried to install and encountered errors, ask in the comments to the material, we will look for a solution together.