Installing Software, Part 3: Command Line


Published on

This last part in the series looks at command line tools for installing Linux software, such as installing from source code.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Installing Software, Part 3: Command Line

  1. 1. Installing Software Part 3 Kevin B. O'Brien Washtenaw Linux Users Group
  2. 2. Previous Presentations ● In the first presentation we focused on GUI package managers, which are mostly just front- ends for mid-level package managers ● This also included a detailed look at repositories ● In the second presentation we looked at command-line package management tools ● These included tools for working with repositories and Washtenaw Linux Users Groupisolated packages for installing 2
  3. 3. This Presentation ● For this presentation we will look at installing software when you don't have a package ● This will all be command line techniques ● As before, anything to do with installing software is an Administrative task, so you need to either be logged in as root, or prefix your commands with “sudo” Washtenaw Linux Users Group 3
  4. 4. Why Install These Ways? ● The main reason for looking at these methods of installing is that the repositories do not contain the software you are looking to install ● It may be a small, specialized program that never got into anyone's repository ● It may be a newer version that is not in the repositories yet – e.g. Firefox 3.5 is not yet (as of August 2009) in the Ubuntu repositories, and probably won't be until the next release in Linux Users Group Washtenaw October 2009 4
  5. 5. Binaries vs. Source ● All software starts out as Source Code ● This is code that is written in a programming language, like C, C++, Java, etc. ● While arcane, it is human-readable if you have developed the skill ● It is not machine-readable, though Washtenaw Linux Users Group 5
  6. 6. Source to Binary ● Machines (computers) can only read code that is in zeros and ones ● This is called Binary code ● It is not human-readable ● A software program called a Compiler takes the source code and turns it into Binary code that a computer can read and execute Washtenaw Linux Users Group 6
  7. 7. Compilers ● Even before Linux existed, one of the first programs written for the Free Software world was a compiler ● Richard M. Stallman, the founder of the GNU project, created what is called the GNU Compiler Collection, or gcc ● This continues to be developed and improved Washtenaw Linux Users Group 7
  8. 8. Compiling programs ● Compiling transforms source code into binary code ● The source code can be in many possible programming languages, so you need to have compilers for each programming language ● Computers can have many possible architectures (i386, 64-bit, RISC, ARM, etc.) ● Covering all of these possibilities is why we call gcc a collection of compilers, not just a single compiler Washtenaw Linux Users Group 8
  9. 9. Pre-compiled binaries ● When a compiler has turned source code into binary code, the resulting file is called a binary ● Packages contain binary files, along with some text files for configuration ● But when there is no package, sometimes you can find a binary that has already been compiled for you ● These most commonly have a file extension of *.bin Washtenaw Linux Users Group 9
  10. 10. *.bin Files ● The first thing to understand is that Linux does not let any file be executed without specific permission to do so ● Unlike Windows, you cannot just download any old file off the Internet and run it ● You must first, either as root or using sudo, make the file executable ● This is done with the command chmod +x <filename> Group Washtenaw Linux Users 10
  11. 11. chmod ● This is short for Change MODe ● The mode, in this case, includes the permissions for what a file is allowed to do ● The “+x” specifies that you are letting it be executable ● So this command lets you take a binary file that you have downloaded, and set it to be executable Washtenaw Linux Users Group 11
  12. 12. Installing ● Once the file is executed, you install the file with this command ./<filename> ● That is just a period, a slash, and then the name of the file, and Bob's your uncle! Washtenaw Linux Users Group 12
  13. 13. Installing From Shell Scripts ● Sometimes you will have a program distributed as a shell script ● These are files with an extension of *.sh ● But in all respects the installation is the same as with *.bin files ● First, make the script executable using chmod +x <filename> ● Then execute it using ./<filename> Washtenaw Linux Users Group 13
  14. 14. Is it really this easy? ● Most of the time it is ● But if you have a problem you may need to check a user forum or web site to get additional help Washtenaw Linux Users Group 14
  15. 15. Compiling Programs ● The term “Open Source” comes from the requirement in GPL and similar licenses that the source code of a program must be available in a reasonable way to end users ● Some of those users may be programmers who will modify the code in some way to fit their needs ● But most of us don't know which end of C++ is used to drive screws, and which to pound nails Washtenaw Linux Users Group 15
  16. 16. But many of us do it ● Still, compiling is something many of us do more often than we may know ● For example, kernel modules have to be re-compiled whenever the kernel changes, which happens about once a month these days ● Example: VirtualBox ● VirtualBox has a program the recompiles the kernel module, and after a kernel update you will get an error message telling you to run this program when you try to run VirtualBox Users Group Washtenaw Linux 16
  17. 17. Isn't it hard? ● Actually, not really ● By definition, any Open source program must make the source code available ● You can download the source code yourself and compile it yourself ● It may even work better for you than a pre-compiled binary Washtenaw Linux Users Group 17
  18. 18. Benefits of compiling ● Possibly a minor one for many people, but compiling your software can teach you a lot about how your computer works ● The biggest benefit is that the compiled program is tuned for your system, your CPU, your version of Linux, etc. ● You can even (this is optional) go into the source code and really tune it up before compiling Washtenaw Linux Users Group 18
  19. 19. Reasons not to compile ● You must do all of the things a package manager would do for you otherwise – You need to resolve all of the dependencies – You need to look for and install any bug fixes, updates, etc. as needed – If you change your mind, you need to manually uninstall Washtenaw Linux Users Group 19
  20. 20. Pre-requisites ● Before you start, make sure you have everything you need ● This can vary by distribution in terms of what is installed by default, and what needs to be added by you ● For example, in Ubuntu and its derivatives (Kubuntu, Xubuntu) you need to install a package called build-essential to have all of the software neededWashtenaw Linux Users Group install to compile and 20
  21. 21. Pre-requisites 2 ● In general here are some things you need to have installed if your distro does not have a neat package like Ubuntu does – Headers for the Linux Kernel – Gcc – make Washtenaw Linux Users Group 21
  22. 22. Get the Source Code ● The first step to compiling and installing a program is to get the source code ● Remember, if it is an Open Source program they must make it available ● You may have two options: – A Source Archive – good for home users – A CVS system of some kind – intended for developers (e.g. SVN, GIT) Washtenaw Linux Users Group 22
  23. 23. Firefox Source Code ● You can go to the Firefox site illa_source_code and see how they do it ● For developers, they use a CVS called Mercurial ● For the rest of us, they provide “tarballs”, which is the format we will cover shortly ● These are provided on an ftp server Washtenaw Linux Users Group 23
  24. 24. Temporary working directory ● You can use a temporary working directory for these activities ● For example you can use the ~/tmp directory ● This is the equivalent of /home/username/tmp ● However, there is a good reason to keep your build directory after the install ● So I would suggest using something other than the ~/tmp directory. Maybe something like ~/builds that you create in your home directory Washtenaw Linux Users Group 24
  25. 25. Source Archives (tarballs) ● Source code is always contained in text files ● But it is not usually a single file ● Most of the time it is a collection of files ● These are put into what are called Archives, which have an extension *.tar (Tape ARchive), a name which comes from the days of tape backup systems ● These files are then compressed to save on bandwidth Washtenaw Linux Users Group 25
  26. 26. Compression of Archives ● These files are usually compressed with either gzip or bzip2 ● The extensions then become *.tar.gz, or *.tar.bz2 ● Uncompressing is then a simple matter of using cd to go to the directory the file is in (e.g. ~/builds), and then – tar -zxpf appname.tar.gz – tar -jzpf appname.tar.bz2 Washtenaw Linux Users Group 26
  27. 27. Dependencies ● This is a potential problem with compiling from tarballs ● Sometimes the developer will tell you up front what the dependencies are ● Otherwise, you will get errors when you try to compile ● This is often the hardest part of the process, but not at all impossible to do Washtenaw Linux Users Group 27
  28. 28. Three-Step Dance ● Compiling and installing software involves a Three-Step Dance – Configure – Make – Make Install Washtenaw Linux Users Group 28
  29. 29. Configure 1 ● This is where the dependencies will come up ● This is also where you can select some settings you want to use ● When you run this, you are running a script called “configure” that is part of the collection you downloaded in the tarball ● In this script, the programmer(s) will do several things Washtenaw Linux Users Group 29
  30. 30. Configure 2 ● First, they will check for the required “helper” programs (dependencies) they need to have to run this program ● If they do not find them, they will give an error ● If this is because the program is not on your system, you need to install it ● Sometimes it is on your system, but not where the script expects it to be. You should be able to tell it the path to find the program in that case. Washtenaw Linux Users Group 30
  31. 31. Configure 3 ● This script will also have options of various kinds ● For instance, certain features of the program may require a dependency. In this case, if you do not need this feature(s), you can ignore it ● You may be able to specify a non-standard install location ● You may have the option to disable features you don't need that might make the program run more slowly Washtenaw Linux Users Group 31
  32. 32. Options ● The point about options is that they are optional ● You can safely ignore options ● A good rule of thumb is that if you are not sure what the option is asking you, leave it alone ● Remember, if the program really needs something, it won't let you get any further until you take care of it Washtenaw Linux Users Group 32
  33. 33. More on Options ● Optional features will generally be presented in a format like --disable-<feature> --enable-<feature> ● Optional packages will generally be presented in a format like --with-<packagename><other options> – Often these package option lines will have (default:test) at the end of the line. This tells the script Linux check and see if you 33 Washtenaw to Users Group have this package installed
  34. 34. Install Location ● The option that tells the script where to install is the --prefix option ● Normally compiled software will go in the /usr/local directory tree – Executables go in /usr/local/bin – Libraries go in /usr/local/lib ● Some applications (e.g. kde apps) need to be installed in a different location Washtenaw Linux Users Group 34
  35. 35. Example 1 ● cd into the directory ~/builds/<programname> and run ./configure --prefix=/usr –disable- <option> ● This will run the configure script for this program, set the install directory to /usr (instead of /usr/local), and disable the option selected Washtenaw Linux Users Group 35
  36. 36. Example 2 ● You should get output that looks something like $ checking build system type... i686-pc-linux-gnu $ checking host system type...i686- pc-linux-gnu $ checking whether build environment is sane... yes and so on ● If you are missing aLinux Users Group dependency you will Washtenaw 36 get a warning that says that the program requires some other program or library
  37. 37. More on Dependencies ● Often what is needed here is something called a development package ● You may already have the base package installed, but what is needed is the associated development package ● For example, Ubuntu uses the Gnome desktop by default, and so gtk is certainly installed. But you may not have libgtk2.0-dev installed, and that is what Washtenaw Linux Users Group needs your program 37
  38. 38. Step One: configure ● So, once you have understood about dependencies, and you have the necessary compilers nad utilities installed, you are ready to do step one: configure ● I will assume you are in a directory like ~/builds/<packagename>, in which you have the source code you downloaded (and unzipped/extracted) ● In this directory Washtenaw Linux Users Group type ./configure 38
  39. 39. Configure 2 ● If you get errors, such as unsatisfied dependencies, you will need to first install those dependencies ● Then try it again ● Wash, rinse, repeat, until you no longer get any errors ● That should mean you have now successfully done your configure Washtenaw Linux Users Group 39
  40. 40. The Makefile ● The output of a successful configure is a makefile ● This file contains all of the instructions for successfully compiling a binary ● Once you have a makefile, the hard part of compiling from source is over. You should now have resolved any dependency issues. Washtenaw Linux Users Group 40
  41. 41. Step Two: make ● At this point, you are ready for the second step of the three-step dance ● In the same directory that you were in to create your makefile, run the make command make ● The most common problem at this point would be an error that says it cannot find a makefile ● This means the firstLinux Users Group Washtenaw step, configure, did not 41 successfully complete, so go back to step one
  42. 42. Make 2 ● You can watch the output of the make command, but it is not necessary ● It will generate output as each source code file is processed ● This can take seconds, minutes, or longer, depending on the amount of source code being processed ● I'd just get a cup of coffee Washtenaw Linux Users Group 42
  43. 43. Checking your make ● Some open source projects have their own test suite ● You can try this to see if your make is correct make check ● This step is optional, but it is a good idea ● If you discover that a feature of the program did not make correctly, but it is one you never want to use, you can ignore the error Washtenaw Linux Users Group 43
  44. 44. Step Three: make install ● Once the make command has finished, you are ready to take step three: make install ● You absolutely must be root or use sudo here ● Example: sudo make install ● This will install the compiled binary in the location you specified in the configure step Washtenaw Linux Users Group 44
  45. 45. Uninstall ● If you change your mind, or for any reason you need to remove the program, go back into your build directory (e.g. ~/builds/<programname>) and run (as root, or using sudo) sudo make uninstall ● This is why I recommended a separate builds directory, instead of the ~/tmp directory often seen in how-tos ● I nevere put things I want to keep in a temporary directory Linux Users Group Washtenaw 45
  46. 46. Running the program ● Usually you can run the program you just installed by typing the name of the program and pressing enter ● If you get an error that no such file or program could be found, that may mean you installed it into a non-standard location ● In that case, you need to add the location to your path Washtenaw Linux Users Group 46
  47. 47. Path ● The PATH is defined for each user in the /etc/profile file ● Edit this with a text editor and add the location of your program Washtenaw Linux Users Group 47