Compiling in GNU/Linux

All threads related to any flava of Linux or BSD.

Compiling in GNU/Linux

Postby NoUse » Sun May 01, 2005 9:00 pm

Motz wrote this awhile ago. I think it would be a good addition to the stickies.
Written by: Motz
http://www.hackerthreads.org

Abstract:
Installing software it is one of the most notoriously hard things to accomplish
on a GNU/Linux system, especially when compiling it from sourcecode. This guide
will hopefully help you to become proficient at it and adapt the knowledge you
gain for compiling on any system using GNU AutoConf and Make.

(BIG NOTE: This tutorial does not cover md5 verification of archives. There's
enough here as it is and I'll try and put it in a revision since it is
important, but it shouldn't be a problem if downloading from trusted sources)

Look Before you Leap
The biggest headaches for a neophyte installing free software or libraries from
source code tend to come because he or she didn't look at the software's
requirements or "dependancies". Downloading an application from an online
repository is very similar to purchasing it from a real world store (of course
without the money if it's GPL'd . You need to look at what depedancies a
program has. These are normally found on the page where you downloaded the
software from (if indeed it was a webpage and not an FTP site). You must find
and install the libraries and packages that your software depends upon before
progressing any further or your install is likely to fail. Good places to look
for this software are Google, the site that you downloaded the software from or
your distribution's package repository. So anyway, now that we've looked, lets
take the first leap.

Unpacking your New Toy
Given that software is an inherently huge thing, most GNU/Linux software comes
in archives called "tarballs". These are files compressed using two methods -
one to handle the directory structure (so that the archive doesn't break) and
one to just squash it as small as it can go. This directory friendly compression
tends to be "tar", which gives the archive the extension "<filename>.tar". When
this archive is compressed with either "gzip" or "bzip2" (the common squashing
archive types), it gains the extension ".gz" or ".bz2" respectively. This leaves
you with "<filename>.tar.gz" or "<filename>.tar.bz2". Now to the actual
unpacking.
Unpacking and other installing activities are done on the command line so that
we can see what we are doing. Firstly, you should open an XTerm/Gnome
Terminal/Konsole (whichever you prefer). Next, use the 'cd' command to change to
the directory where the package is located (but yeh, you probably knew that
anyway .
To unpack a gzipped tarball, you use (most commonly):

$ gzip -d <filename>.tar.gz

For a bzipped tarball, you use:

$ bzip2 -d <filename>.tar.bz2

Both of these should leave you with the file "<filename>.tar".

(Note: gzip and bzip2 take many more command line "switches". Type "gzip --help"
or "bzip2 --help" respectively for information on these. If the output scrolls
off the screen, try "gzip --help | more" or "bzip2 --help | more" for greater
readability)

Next, to unpack the tar, you use:

$ tar -xvf <filename>.tar

(The same applies as above about command line switches)

This should cause a list of the files contained in the archive to scroll down
the screen. It did? Good. These files were probably preceded by a directory name
like so:

<directoryname>/<filename>

Use 'cd' to navigate to the directory (<directoryname>) - now we can start
compiling

'Make'ing choices
All good software allows for some level of customization. On GNU/Linux, this
starts at binary level. In <directoryname> you should find a shell script called
'configure' (if not then this paper won't help much, but it's pretty much a
defacto standard so it's more than likely to contain one). This guesses system
specific settings such as language and operating system (GNU/Linux, what else?
and also allows you to choose some of your own. Personalised settings are
passed as switches like those discussed for unpacking the archives. The most
common switch for 'configure' is '--prefix=<directory>' which defines the
directory into which the program is going to be installed.
Note that this is not like Microsoft Windows's concept of program directories.
The GNU/Linux filesystem structure differs here slightly. Many programs are
installed in one directory with sub-directories as follows:

*bin - Contains binary files
*lib - Contains library files
*doc - Contains documentation
*man - Contains manual files

(Note: Those are only are sample, but they are the most common)
The main directory into which you want the software to be installed can be
supplied as the 'prefix' using the described switch. Usually, system components
like the Desktop Environment and other vital software (which would take the
C:\Windows\System path on a Windows system) is installed with the prefix '/usr'
whereas user installed software (which would be installed in C:\Program Files on
a Windows system) is installed with the prefix '/usr/local'. Of course, if you
are at any time unsure of the prefix that a piece of software should be
installed with, you can omit the prefix switch and use the default (which is
probably correct, given that it was set by the author of the software).
So now, time to configure:

$ ./configure [[--prefix=/usr/local] --other-flags]

(Note: Again, as with all GNU compliant scripts and software, you can find more
information about switches using './configure --help')

This should present you with output such as the following:

checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for object suffix... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for unistd.h... (cached) yes
checking for size_t... yes
checking whether byte ordering is bigendian... no

This is obviously not a complete output or entirely accurate (As a matter of
Gnome supporting interest, I used AbiWord's configure script to get this sample
:p ) but I chose the lines to give you a good sample of the range of things it
might throw at you. Don't worry if you get a big list of "checking for x... no"
when checking for obscure things like whether you're using the GNU Fortran
compiler (you probably aren't as provided you've sorted out you dependancies
correctly, the script probably has something to fall back upon.
That brings me to the point of failed dependancies. If you've not done as I've
said in 'Look before you Leap' (Or indeed if you have done and the author hasn't
listed a dependancy) then you will be hit with messages like this:

checking for GLIB - version >= 2.4.0... no
*** Could not run GLIB test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GLIB is incorrectly installed.
configure: error: maybe you want the gtk-gnome-1-2 branch?

(That example being from a PyGTK install that I rigged to fail If you run
into problems like this, you should search the places I listed earlier (Google,
etc) for the correct packages. These in turn may have dependancies that you must
fulfil, so when installing something obscure like
libPy-Kitchen.5ink-devel.rc1.i386, be prepared for a baptism of fire in the
fabled GNU/Linux 'dependancy hell' (Don't let that put you off though, such
things aren't as commonplace as some would have you believe).

So did you get all that? If so, we're ready to 'make' the arduous journey to a
compiled binary. Compared to the above, that's pretty simple. Provided the
configuration went ok, you should just be able to type:

$ make

This will give you lots of long convoluted stuff about 'entering directory' and
'gcc --obscureflag random.c libVerboseJavaStyleName.o'. Well, stuff like that
anyway If you see the following, you probably didn't configure it right and
may need to check something:

make: *** No targets specified and no makefile found. Stop.

Also something like 'make[1]: error' obviously doesn't bode well for you. You
will need to search google for that because at over 1300 words already, I do not
have time to discuss every possible error when compiling libAwkward-unstable.
Your best bet for help is the software site's FAQ, Google or newsgroups various.

So that went well...(he says, tempting fate ? Good. If you want to install in
a directory that you don't have the correct permissions for, then you need to
change user to root (assuming that it is your box - if not, ask permission from
your 'friendly' local sysadmin :p ) and 'make install'. In case you needed
prompting:

$ su
Password: <rootpass>
# make install

You should now see a lot of output similar to that of 'make' except with more
'installing' and less silly gcc flags All being well and good, you should now
have the program installed. So...

# exit #Don't want to run it as root
exit
$ /<prefix>/<software>

Appendix A : In Summary
$ bzip2 [/gz] -d <archive>.tar.bz2 [/gz]
$ tar -xvf <archive>.tar
$ cd <directory>
$ ./configure
$ make
$ su
# make install
# exit
$ /<prefix>/<software>
And I will strike down upon thee with great vengeance and furious anger
those who would attempt to poison and destroy my brothers.
And you will know my name is the Lord
when I lay my vengeance upon thee.
User avatar
NoUse
time traveller
 
Posts: 2624
Joined: Thu Aug 28, 2003 10:46 pm
Location: /pr0n/fat

Return to ā€œ%sā€ *Nix

Who is online

Users browsing this forum: No registered users and 0 guests

cron