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 ( 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

  2. Unpack the tarball:

  3. $ tar xvzf xmorph_20040717.tar.gz
    ...(Lines snipped)...

  4. If the file is compressed with bzip2 (usually indicated by a filename that ends in, .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/
    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; \
    ...(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;\
    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... ...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. ...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