[Lintula home] -> [Instructions] -> [Installation of software in Lintula]

Lintula

Installation of software in Lintula

This page contains instuctions about installing software on Lintula computers without administrative privileges.

Unfortunately the Lintula administration does not have the resources to install and take responsibility for every piece of software that someone might find useful or necessary. Sometimes you might want to use or perhaps just test some software, but find yourself unable to follow the included installation instructions due to lack of privileges to write to system directories.

Despite the abundance of such instructions, most software does not need to be installed into system directories, and elevated privileges are rarely needed to compile, install or use software of your own. This document aims to provide a short introduction to concepts that will help you with this.

The system directories

You will not be able to write into system directories such as /usr or /usr/local. However, the only special thing about these paths is that they are by default on the search part of those system components that are interested in their contents. Slight changes to your environment will make it entirely possible to look for commands or libraries wherever you want. You can install software into any directory you have permissions to write to.

A certain hierarchy of directories is expected by most software. This means for example that compiled binaries go into a directory called bin, libraries into a directory called lib, and so on. The path where these directories themselves reside is called the prefix. The established convention of what goes to what prefix is roughly:

As to where exactly you might want to prefix your software, there are a few options. You could create a directory under your home directory, but quota may be a limiting factor. Personnel with workstations might create a directory under their /usr/oma directory, but make note that it is not backed up or visible to other computers. Students in classrooms could use a directory under /worktmp with the same note. University projects can get dedicated disk space on a network disk. More information about disk space on Lintula computers. The rest of this document will use /my/directory to reference your chosen location. This is not a real path, nor should you try to use it.

Notice that binaries compiled on Linux will not work on Solaris computers or vice versa. Perl and Python code may work across platforms.

Do not look for an .rpm package

All the software in an operating system distribution typically comes managed. This means that the operating system vendor has packaged them into neat bundles along with the necessary metadata and how they depend on each other, making it easy to install and remove them. This is very useful, as long as all the software comes from a single vendor and has been designed to work together.

A lot of software that is not provided by a given vendor has still been rolled into such packages by third parties for easy installation in those systems. These packages spell trouble. They may be aimed at the novice administrator running one computer, and can therefore make brave but false assumptions like being able to create user groups. There is also no guarantee that they will play nice with the other system software, having third party packages installed has been known to have occasionally prevented important system upgrades due to dependency conflicts or other errors.

Most importantly for the purposes of this document, third-party packages are rather useless without administrator privileges, and Lintula administration will generally not install them due to reasons stated above. Do not look for packages, build from source.

Unpacking the sources

The distribution format of choise for UNIX-like systems is the tarball. These can be identified by the suffixes .tar.bz2 or .tar.gz (or .tgz for short). The dual suffixes are because of a UNIX tradition of favoring several interchangeable tools that do their one function well instead of few tools that perform many functions badly. TAR stands for tape archive and is the component that gathers and stores many files along with their various metadata (owner, group, permissions) into one file. This has then been compressed to save disk space with a generic compressor, almost always either gzip or bzip2.

To unpack such a file, the data must first be decompressed with gunzip or bunzip2 and then the files extracted with tar. The GNU implementation of tar, installed on all Linux systems, includes extra switches to make this straight-forward. On these systems you can unpack a tarball with a single command in this manner:

tar xvzf package-version.tar.gz , or
tar xvjf package-version.tar.bz2

The default tar on the Solaris systems does not recognize the flags that pipe the compressed data through the decompressors. On these systems in Lintula you can find the GNU implementation installed as gtar, use that instead.

By convention these tarballs include a top-level directory, meaning that after unpacking your current directory will have one new directory instead of many new files. Enter this directory to continue. By convention the name of the directory is the same as the tarball without the suffixes.

cd package-version

Notice, however, that sometimes conventions are broken. It's entirely possible that a tarball will litter files all over your current directory, or that the directory it contains is named something completely different. You can have a look at the contents of a tarball beforehand without extracting it by substituting the x switch in the commands above with a t switch.

Sometimes uncompressed sources and the process of compiling them takes a lot of disk space. It is often a good idea to unpack them to a directory that resides on a local disk, instead of using a slow networked disk with quota limitations. If you run into space limitations, you could consider using a directory under /worktmp or your /usr/oma directory, if you have one. Failing this, there is usually space at /share/tmp, though it is a network disk and not so fast. When using shared disks. please clean up after yourself when you no longer need the files so that others can use the disk space.

Compiling and installing software that uses the GNU build system

Many free software packages are written to make use of the GNU build system, and you can usually tell these by the presence of a configure script. This script will discover compile-time parameters about the environment and test that necessary components are available. In rare cases the script itself is not included with the distribution, but a configure.in or configure.ac is still available. You can then generate the configure script by running

autoconf

To ease the local administration, the default prefix is usually /usr/local, but you can easily override this prefix by providing your own. Oftentimes, compiling and installing software is as easy as:

./configure --prefix=/my/directory
make
make install

Running your installed software

Since you cannot install the software on the default search path, you will have to either specify the path to it every time you run it, like

/my/directory/bin/myprogram arg1 arg2

or you can let the system know where to look for it through the PATH variable. PATH contains a colon-separated list of directories which are searched in order when you issue a command without specifying an explicit path to it. The system will pre-set this variable, and it is important that you only add new directories into it instead of completely overriding it. In bash (the default shell) you can add a new search path by issuing a command like

export PATH=$PATH:/my/directory/bin


Setting a variable this way will only affect the current session. To make it more permanent, add the line to your ~/.bash_profile file.

Using your own libraries

Sometimes a piece of software will require a dynamic library that is not available. You will then need to build and install the library first, and tell the build system about it when configuring the software. It is assumed here that the library also uses the GNU build system, and can be installed like above. There are several ways of telling the build system about it, listed here in order of preference.

Sometimes the software's own configure script is written to take into account that the library may be installed in a non-standard place and provides a neat way of telling about it. You can see all the switches supported by the script by running

./configure --help

If you see something looking like --with-mylibrary=PATH, where mylibrary is the name of the library, its quite likely that this option will help you to specify the prefix where the library is installed. Like this:

./configure --prefix=/my/directory --with-mylibrary=/my/directory

Unfortunately this sort of convenience is not very common. The next thing you should check is whether the library installed a file under a directory named pkgconfig:

ls /my/directory/lib/pkgconfig

These files are named with the extension of .pc and contain setup information for development using the library. If such a file seems to be installed, set the variable PKG_CONFIG_PATH to point there before running the configure script:

export PKG_CONFIG_PATH=/my/directory/lib/pkgconfig
./configure --prefix=/my/directory

In the unfortunate case that this is not an option either, you will need to tell the configure script to add the necessary flags to calls of the compiler and the linker for them to find the headers and libraries. This is again done with certain environment variables, for example:

export CPPFLAGS="-I/my/directory/include"
export LDFLAGS="-L/my/directory/lib -R/my/directory/lib"
./configure --prefix=/my/directory

Building and using Python modules

Installing Python modules works pretty much as above, but they don't use the same kind of a configure script. First obtain and unpack the sources like above, and enter the source directory. Then run:

python setup.py install --prefix=/my/directory

Then when running Python software, tell Python to look for modules under your own path by use of the PYTHONPATH variable:

export PYTHONPATH=/my/directory/lib/python2.4/site-packages

In some cases you might not have access to the environment variables. This is the case for example when you are writing CGI scripts for a web server to run. In these cases, you must tell Python of the extra modules within your own code. The syntax is this:

sys.path.append('/my/directory/lib/python2.4/site-packages')

Building and using Perl modules

Perl modules can also be installed by their own methods. Obtain and unpack the sources like above, and enter the source directory. Then run:

perl Makefile.PL PREFIX=/my/directory
make install

Then when running Perl software, tell Perl to look for modules under your own path by use of the PERL5LIB variable:

export PERL5LIB=/my/directory/lib/perl5/site_perl

In some cases you might not have access to the environment variables. This is the case for example when you are writing CGI scripts for a web server to run. In these cases, you must tell Perl of the extra modules within your own code. The syntax is this:

use lib '/my/directory/lib/perl5/site_perl';

Using the CPAN module

If you are installing a lot of Perl modules or if they have complicated dependencies, you may find the CPAN module useful. It is installed on Lintula Linux computers as cpan. On the first run you will need to answer a lot of questions, but most have sensible defaults. The important one to focus on is Parameters for the 'perl Makefile.PL' command, where you should specify the prefix like it was specified above.

Your choice: [] PREFIX=/my/directory

Once CPAN is configured, installing modules should be as easy as:

cpan> install NameOf::Module

You will still need to tell Perl where to look for those modules, just like above. For more information on the CPAN module, refer to

What to do with other software that does not use the GNU build system

It is hard to give instructions for software not using the GNU build system, because there is no telling how they have been set up. You should see if there is an included README file and see if it gives you any ideas.

Any such instructions are probably aimed at system administrators, so you will have to keep in mind the spirit of the instructions on this page when reading them. The most important thing to do is to change the installation directory to somewhere that you can write to. Usually that is enough, you will just have to adjust your PATH variable at runtime, just like above.

If the software needs special libraries, make sure that the compiler gets called with the correct flags. See the variables CPPFLAGS and LDFLAGS above under Using your own libraries, but note that these are meant for the configure scripts. For software not using the GNU build system you may have to add the same flags manually, probably by editing the Makefile.

Summary of environment variables you may want to set

The examples above make use of several environment variables. Several of them can be very handy to set more permanently, if you compile and use software yourself. These were:

export PATH=$PATH:/my/directory/bin
export PKG_CONFIG_PATH=/my/directory/lib/pkgconfig
export PYTHONPATH=/my/directory/lib/python2.4/site-packages
export PERL5LIB=/my/directory/lib/perl5/site_perl

PATH, PYTHONPATH and PERL5LIB are useful at runtime. PKG_CONFIG_PATH can come in handy when you compile more software against libraries you have installed.