Previous Page
Next Page

5.6. Installing From Source

Although there are thousands of packages available in RPM format ready to be installed on a Fedora system, there is a lot of open source software (http://opensource.org) that hasn't been packaged into RPMs. This software can be compiled and installed directly from the source files.

5.6.1. How Do I Do That?

Most open source software follows a certain set of conventionsone that the community has adopted as a de facto standard:

  • The software is packaged in compressed tar format (.tar.gz or .tgz).

  • A configure script is provided, which analyzes the system (by trying to compile many tiny programs and attempting to locate certain programs and files). After this analysis, a Makefile is produced.

  • The Makefile contains the logic to build and to install the package.

  • Basic documentation, including pointers and licensing information, is contained in files with uppercase names such as README, INSTALL, TODO, and LICENSE.

To install software distributed this way:

  1. Obtain the compressed tar file (or tarball) containing the source. You can use a browser to find and download open source software from sites such as http://sourceforge.net.

  2. Unpack the tarball:

  3. $ tar xvzf xmorph_20040717.tar.gz
xmorph-current/
xmorph-current/Makefile.in
xmorph-current/gtkmorph/
xmorph-current/gtkmorph/ChangeLog
xmorph-current/gtkmorph/Makefile.in
xmorph-current/gtkmorph/README
xmorph-current/gtkmorph/Makefile.am
...(Lines snipped)...

  4. If the file is compressed with bzip2 (usually indicated by a filename that ends in .tar.bz, .tar.bz2, .tbz, .tb2, or .tbz2), use the j option instead of z to decompress:

  5. $ tar xvjf xmorph_20040717.tar.bz2

Most tarballs will unpack into their own directory, but some badly packaged ones may not, and unpacking them will leave dozens of files in your current directory. Use tar's t option instead of the x to see the table of contents before unpacking:

$
                      tar tvzf xmorph_20040717.tar.gz


  1. Change to the new directory:

  2. $ cd xmorph-current

  3. Review the notes that are provided with the software (such as the README and INSTALL files).

  4. If there is a script named ./configure, run it:

  5. $ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
...(Lines snipped)...
The Makefile will build morph.
The Makefile will build xmorph.
The Makefile will build gtkmorph.
configure: creating ./config.status
config.status: creating m4/Makefile
config.status: creating po/Makefile.in
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating libmorph/Makefile
config.status: creating morph/Makefile
config.status: creating xmorph/Makefile
config.status: creating gtkmorph/Makefile
config.status: creating glade1/Makefile
config.status: creating glade2/Makefile
config.status: creating tkmorph/Makefile
config.status: creating plyview/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing default-1 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile

  6. Use make to build the software using the Makefile:

  7. $ make
make  all-recursive
make[1]: Entering directory \Q/tmp/xmorph-current'
Making all in m4
...(Lines snipped)...
if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. \
  -g -O2 -Wall  -DREAL=double -DRGBA_MESH_WARP -g -O2 -Wall -MT \
  my_malloc.lo -MD -MP -MF ".deps/my_malloc.Tpo" \
  -c -o my_malloc.lo \Qtest -f 'my_malloc.c' || echo './'\Qmy_malloc.c; \
then mv -f ".deps/my_malloc.Tpo" ".deps/my_malloc.Plo"; \
else rm -f ".deps/my_malloc.Tpo"; exit 1; \
fi
...(Lines snipped)...
make[2]: Leaving directory \Q/tmp/xmorph-current'
make[1]: Leaving directory \Q/tmp/xmorph-current'

If you have a multiprocessor or multicore system, use make -j3, assuming it's not also a multiuser machine and you don't mind two cores/CPUs being utilized at 100 percent.


  1. If make was successful, use make install to install the software:

  2. # make install
Making install in m4
make[1]: Entering directory \Q/tmp/xmorph-current/m4'
make[2]: Entering directory \Q/tmp/xmorph-current/m4'
...(Lines snipped)...
mkdir -p -- /usr/local/share/xmorph/pixmaps
cd example; for i in * ;\
        do /usr/bin/install -c -d /usr/local/share/xmorph/example/$i ;\
        for j in $i/* ;\
        do  /usr/bin/install -c -m 644 $j \
          /usr/local/share/xmorph/example/$i; done;\
done
make[2]: Leaving directory \Q/tmp/xmorph-current'
make[1]: Leaving directory \Q/tmp/xmorph-current'

At this point, the software should be ready to use.

5.6.2. How Does It Work?

A tarball is an archive of files created by tar (the tape archiving program) and usually compressed using gzip. By convention, source code tarballs are named <package-version>.tgz and all of the files extract into a directory named <package-version>; for example, fen-10.4.tgz would extract into the directory ./fen-10.4/.

Since the 1980s, source packages have often contained a script named configure; most recent open source projects use versions of this script generated by a tool called GNU autoconf. The configure script adapts the compilation process for various systems; for example, some Unix systems have multiple C compilers installed, or different versions of libraries such as malloc, so configure determines what is available and the compiler options that will be needed to compile the software on the current system.

The output of configure usually includes one or more Makefiles and sometimes a C header file. The Makefiles contain the commands necessary to build the software, as well as dependency information; make uses this file to perform the least amount of work necessary to build the required output files. Another section of the Makefile contains the commands necessary to install the softwareperforming operations such as copying files and creating directoriesand this section is used when the make install command is executed.

The disadvantage of installing software from source is that you lose the benefits of the RPM database. It can be hard to uninstall the software, and you have no record of which version was installed, when it was installed, what dependencies it requires or satisfies, and which files are associated with it. Any updates must be performed manually, and any conflicts that other updates may cause will not be known in advance.

5.6.3. What About...

5.6.3.1. ...packages that are not written in a compiled language?

These packages may still need processing. For example, the manpages may be in a raw format that needs preprocessing, and scripts may need to be adjusted according to where the language interpreter is installed. In most cases, these packages will have a Makefile, just like a compiled package.

5.6.3.2. ...packages that don't have a configure script?

The Makefile may be sufficiently simple or generic that it will work on a wide range of systems, or you may need to adjust it manually. Look for a file named INSTALL or README for information on the steps you need to perform to compile and install the software.

5.6.4. Where Can I Learn More?

  • The manpages and info pages for autoconf and make


Previous Page
Next Page