Compiling from Source

Why do this ?

Linux distributions come with binaries of lots of software, however there are some reasons why we sometimes want to install from source :

• The software needed is not included in the distribution
• The software needed is not available in the Slackbuilds repository
• We want to fit the software compile-options to the exact needs of our site
• A newer bug-fixing or security-fixing version of the software needs to be applied promptly
• The software is not installed in the standard /usr file structure where some other software would expect it to be

Compiling software from source is often simple, however when the software is complex or has many options, can require some additional knowledge to choose the right options. The usual steps are :

• Locate the source package (google…) and download it
• Uncompress the tarball (compressed file) under /usr/local
• Set up correct ownership and access rights on the file structure
• Go to the software directory and read the README and INSTALL files
• Check the options using ./configure --help | less
• Configure the package to your system specific needs running the ./configure script, that automatically checks your system to produce all the required Makefiles. This is the step that sometimes might have many options
• make and make install using the right login and permissions
• ldconfig to make sure any library included is taken into account
• Set up configuration files
• Use the software
• make clean and remove the sources (or not)

What you usually need to type on your keyboard is something like that :

# tar -tvf software-x.y.z.tgz
# tar -C /usr/local -xvf software-x.y.z.tgz
# cd /usr/local
# chown -R root:root software-x.y.z
# chmod -R o-w software-x.y.z
# cd software-x.y.z
# vi README
…
# vi INSTALL
…
# ./configure -help | less
# ./configure --libdir=/usr/local/lib64 -option1 -option2 …
# make
# make install
# make clean
# ldconfig
# cd ..
# rm -R software-x.y.z
# cd /etc/software
# vi xxx
…
# cd /etc/rc.d
# vi rc.software
# ./rc.software restart

64-bits

64-bits versions of Slackware store libraries in /lib64 & /usr/lib64 while 32-bits versions of Slackware store them in /lib and /usr/lib.

Using 64-bits versions of Slackware, unless you install multilib (which seems to break the ability to compile the Kernel BTW), it is not very important where you store local libraries and /usr/local/lib - which is the default for most gnu software - could be OK. However, to stay in line with the 64-bits Slackware standard, we will generally store the local software libraries in /usr/local/lib64 using the -libdir option of .configure.

Access rights

Software not working after installation is usually a permission issue. Keep the initial setting of 022 for umask in /etc/profile to make sure files are created with read access for other when installing. For software to be ran under a user other than root (cyrus imap under cyrus, spamAssassin-clamav-mimedefang under milter), su under this user after installation to make sure the software works and launch the software from the console to detect permission issues messages. The /var/log directory is another place to check for errors.

Libraries

Another major cause of software failing to work properly is missing libraries because they are searched in the wrong place - for example /usr/lib64 instead of /usr/local/lib - or because they have the wrong name - for example library imap2007/c-client.a actually needs to be linked as imap2007/libc-client.a.

Headers

Yet another type of failures - at compile time - is evolution of the underlying libraries and changes made to the .h header files. Downgrading libraries in a distribution is strongly disadvised, so your best approach will be to wait for a new compatible version of your software, to find a working version on slackbuilds.org, to google a solution, or to contact and work with the authors of the software.

Compiling the Kernel

Main Page

Compiling Xen