The enchanting magic of configure, make and make install. Installing programs in Linux (.tar, .gz, .bz, RPM and DEB) Downloading kernel sources

And also other systems have to be installed additional programs. In operating rooms Windows systems everything is very simple, as a rule there is a setup.exe installer that helps to install the software. But in Linux, things are a little different. How to install programs in Linux? Now let's consider 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 usually named program_name-version.rpm.

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

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

You need to run the program installation procedure on behalf of the 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 toolset. To install the application, enter the command:

apt-get install packagename

For removing:

apt-get remove packagename

APT keeps 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 obsolete packages (programs) on the computer, type the following commands:

apt-get update ; apt-get upgrade

Installing software on Fedora, Red Hat

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

yum install packagename

yum remove packagename

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

yum update

Choose something specific to update:

yum update packagename

Installing programs in Mandriva

Mandriva has its own set of package management tools called urpmi. For installation:

urpmi packagename

To delete:

urpme packagename

Update local database with package list:

urpmi. update -a

To install updates:

urpmi --auto-select

Installing programs from archives (tarballs)

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

tar -xvz f filename

For archives compressed with BZIP (bz, bz2, etc.) a little differently:

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 the tape instead of the file;
• z - process archive compressed with gzip;
• j - process archive compressed with bzip.

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

cd foldername

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

There are situations when you need the latest version of a program, but it is not in your distribution's repository. 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 assemble the program from source code, directly under your distribution. Of course, we are talking about open source programs :)

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 to the computer's central processor. Not all programming languages ​​are compilable. For example, Python code can be run immediately without converting it to binary code (although this is also possible). To assemble the program, it is desirable to have a sufficiently powerful, and preferably a 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 difficult in building a program from source code. The main thing to remember is one rule: in a package distribution, in no case should you use the method make install. Otherwise, in the future you will get such a big pile of problems. When you realize that you wanted to remove the program (delivered in this way), but the package manager does not know about it. And the program itself consists of several hundred files scattered in different directories. Scary? Therefore, in packaged distributions, the program must be compiled into, in fact, a package. Then it can be easily removed, in which case. I wrote this because many manuals on compiling programs on Linux that I came across describe exactly make install. You can uninstall a program installed in this way only in two cases:

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

Don't use make install!

I note that not every program can be built in the same way. Therefore, you should always read the assembly instructions that are in the archive with the source code. It happens that the developer put a script there, which does everything on its own when it starts (collects and installs, but we remember about make install), or it may not be suitable for assembly make, but you need a different build system. Also, to build the program, you will need to install the necessary assembly dependencies 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 remove it without problems, there is a utility called checkinstall. It will allow you to create a native package for the system ( deb or rpm), which will allow you to use a regular package manager to install / remove it

To build programs in GNU/Linux, one uses (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, you need to separately write the paths for each distribution, where libraries and header files lie. Programmers cannot study each distribution and create a Makefile for each one separately. Therefore, we came up with configurators that “study” the system and, in accordance with the knowledge gained, create a Makefile. To build, we need compilers: they are written in the dependencies of the package build-essential, so it's enough to install it with all dependencies. Still needed autoconf and automake. If the program is written in Qt, then it is usually assembled either by the 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, install the necessary set of 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 site), clone the source code repository, and so on. In the first case, in general, everything is clear. In the second: suppose that the program is in a 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, take the program mgba. This is a game console emulator. Nintendo GameBoy. repository address. We copy it to 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 is an assembly instruction.

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

cd ~/mgba

And we collect the program:

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

Some data will be requested (package name, version, and so on. It is advisable to fill in 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 with a double click or with the command sudo dpkg -i packagename.deb. If during the build you start to receive error messages, read them carefully. There may be some build dependencies missing.

Let's take a slightly different example that uses a configurator. In this case, in the directory with the source code, there are scripts: autogen.sh, configure and the like. autogen.sh generates a script configure, with which you can already configure the program before building (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 script autogen.sh . Let's execute it:

./autogen.sh

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

./configure --help

View all available options. Usually, these can be support for various plug-ins, an assembly with an alternative interface, even an assembly for a different processor architecture. Suppose 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 are some standard options (after typing ./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, it happens that the developer did not bother with high-quality assembly instructions. But this rarely happens. I also want to draw your attention to the following: resort to building a program from source only as a last resort. If you are using Ubuntu LTS, then look (with the help of Google) if the program you need (or the latest version) is not in a more recent release of Ubuntu. Or maybe there is

There was a desire to get acquainted with the development for android. Downloaded Android Studio, unpacked and deleted. I decided to look for other installation options. In the process of searching, I came across Ubuntu Make (aka Ubuntu Developer Tools Center in the past), and in this short note I want to tell you about it.

The Ubuntu Developer Tools Center was in the news with Ubuntu 14.10 (Utopic Unicorn), but didn't seem to get much public attention. Not much later, the project was renamed Ubuntu Make, as it is called to this day, grown to version 0.4. Developed by Didier Roche, Software Engineer, Canonical. Also noteworthy is the fact that Ubuntu Make is written in Python 3.4.

The main goal of the project is to quickly and easily install the general needs of a developer in Ubuntu. And although “general needs” is still far away (the list of packages available for installation is still small), everything is fine with “quick and easy”.

On the this moment using Ubuntu Make you can install:

• android studio
• Eclipse
• IntelliJ Idea Community Edition
• PyCharm Community Edition
• go-lang Google compiler
• Stencyl game developer IDE

Installation

In ubuntu 15.04 ubuntu-make is available out of the box, users of versions 14.04 and 14.10 are encouraged to install from ppa:

sudo add-apt-repository ppa:ubuntu-desktop/ubuntu-make sudo apt-get update sudo apt-get install ubuntu-make

Usage

Installing with ubuntu-make is easy as hell. For Android installations Studio is enough to execute in the terminal:

Umake android
A bit of waiting and here is the result:

Icon in dash and openjdk (if Java was not in the system) included. After the launch, the "studio" pulled up the sdk and updated to version 1.0.2. "Hello world" was launched on the phone and the health check was completed.

Golang is installed similarly:

For PyCharm, Eclipse, Idea one more argument will be added:

Umake ide pycharm

To remove a package, just add the "-r" argument to the same line:

Umake ide pycharm -r

Opinion

Someone will say: - “Is there a lot of business. Download archive, unpack, dash icon and check it out. Is ubuntu make necessary? I agree, there may not be much to do, but I found the package useful for myself. He saved me time and got rid of the routine. I hope it will be useful to you too.

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

But after all, 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 do not know what distribution kit you have, and whether it is a distribution kit at all, maybe you joined a sect and smoked reading LFS and now decided to compile their creation under your chthonic system. And make install is a universal, if often wrong, way to do it.

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 in most *nix systems are hardcoded 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 “smeares” itself all over file system. Libraries go to lib, executable files in bin, configs in etc, all sorts of data in 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 bad. The probability of this event is not so great, but do you need it on a combat 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 is likely to will overwrite your changes in configs. make install does exactly what it's told - it installs the files in the right places, ignoring the fact that something is already there. After this process, it is impossible to obtain absolutely no information about what was put and where in a digestible form. Sometimes, of course, the Makefile supports the uninstall action, but this is not so common, and it's not a fact that it works correctly. In addition, storing the unpacked tree of sources and assembly 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 a package manager. When using it, the installation goes something like this:

1. a specially formed archive 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 some scripts to install / remove / configure, etc
3. Performing direct installation steps
4. All data about where and what was delivered is added to the database of the package manager.

In this case, when updating, you can painlessly remove the excess, and at the same time see if the files marked as configuration files 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 overwrite the files of one package when installing another. In general, he can do a lot of useful things.

If you unknowingly / lazily copied make install from the instructions, then files appear in the system that the package manager does not know about. With all the consequences, if what was listed earlier is not enough for you.

What to do?

You can, of course, configure the source tree so that the installation of everything and everything goes somewhere in /opt/mycoolapp/, and then, if necessary, manually delete it, 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, ending with the fact that the author of the program 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 stuff.

So you need to collect the package.

I don't have time to *** deal with this, I'd better make install again, everything is simple and clear!

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

checkinstall

This wonderful utility, when run instead of make install, will ask a few questions, after which it will build and install the package itself. Everything, when updating, you will not have any problems with cleaning out old trash.

Building a deb package manually

If you are not inclined to trust such automation (which sometimes still messes up) or if you want to make a couple of changes, but it’s still lazy to deal with the normal process of building packages, then you can build the package manually. I'm giving a way to build it for Debian-based systems, as I'm most familiar with them. It is not ideologically correct, but the output is a completely correct package without involving additional entities. This is done in the following way.
To begin with, we build the software with the --prefix=/usr and --exec-prefix=/usr parameters previously specified for configure or autogen.sh.
Next, we install in a temporary directory. We write:

Fakeroot make install DESTDIR=`pwd`/tempinstall
After that, 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 freely change the owner and access rights of files, but physically you yourself will remain the owner in the system. The software inside the fakeroot session will receive the changed information, which will allow to pack files with the correct rights into the archive.
Next, create the DEBIAN directory in the "package root" and put in DEBIAN/conffiles a list of all files that should get into /etc:

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 we get tempinstall.deb at the output, on which you can set dpkg -i and which will be correctly installed, updated or deleted.

The "correct" process of prepackaging the source code is out of 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 a huge number of problems in the future.

Hi all!

This is a small note for Linux beginners about what these three great commands mean and what they are for. Let's start, as they say, from the beginning. Most programs must be compiled before use, that is, converted from human-readable text into a set of ones and zeros that a computer can understand. The process is conditionally divided into three stages: configuration (configure), assembly (make) and installation (make install). 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- the file needed 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 prefixes in the file system that most programs are configured against, namely:

• / - the root directory of the operating system, the so-called ROOT
• /usr - directory where user environment applications are located
• /usr/local - an additional directory for manually compiled user programs, specifically for operating system did not 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 run ./configure without keys, then the default prefix (the directory where the compiled program will be installed) will be /usr/local, remember this if you cannot run your program, you may not have a path in 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 that starts the application compilation procedure from the 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 successful execution of the make command will be the compiled program in the current directory.

make install

This command performs a direct installation of the application to 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

&& is an AND operator that came from the C/C++ language, however, from the shell point of view, it means that the next command should be executed only if the previous command was successful, which is very convenient if one of the stages ends with an error.

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

./configure && make install

Good luck to you! And thanks for reading!