Installing Software, Part 3: Command Line

Installing Software Part 3

Kevin B. O'Brien
Washtenaw Linux Users Group
http://www.lugwash.org

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

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

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

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


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


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


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

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

*.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

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

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!


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>

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


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


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

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


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


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


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

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


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)


Firefox Source Code
● You can go to the Firefox site
https://developer.mozilla.org/en/download_moz
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

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

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

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

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

Three-Step Dance
● Compiling and installing software involves a
Three-Step Dance
– Configure
– Make
– Make Install


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

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.

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

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


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

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

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


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

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

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

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

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.


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

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

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

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


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

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

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


Installing Software, Part 3: Command Line

Recommended

More Related Content

What's hot (20)

Similar to Installing Software, Part 3: Command Line (20)

More from Kevin OBrien (19)

Recently uploaded (20)

Installing Software, Part 3: Command Line