To download a copy of this document, please select one of the following:
ucko@vax1.rockhurst.edu
``Red Hat Tips'' are documentation meant to help Red Hat users with specific tasks. Some of these documents are for new users, some are for advanced users. Hopefully each document will also be of help for both new and advanced users. If you have contributions to make, please send them to tech-sup@redhat.com. If you have changes that need to be made to individual Tips, send them to the author of that document.
This document explains how to compile software written in C, C++, or Objective C. It also deals with related issues such as applying patches and creating new RPMs.
The following packages are absolutely required to compile anything:
gcc: the compilerbinutils: supporting utilitieskernel-source: it contains some important headerslibc-include: it contains most other headerslibc-devel: the remaining miscellaneaIn addition, you'll almost certainly want to have make, which allows
you to use Makefiles.
Other possibly necessary packages include
bin86: real-mode binutils
(used to build the kernel and dosemu)bison: the GNU version of yacc, a parser generator
(used for *.y)byacc: the BSD version of yacc
(a few programs prefer this to bison)flex: the GNU version of lex, a lexical scanner generator
(used for *.l)gcc-c++: the C++ compiler
(used for *.cc, *.C, *.cxx, and *.c++)libg++: the standard and GNU c++ libraries
(needed for almost all C++ programs)gcc-objc: the Objective-C compiler
(used for *.m)patch: a patch applierdiffutils: a patch makerpmake: a BSD version of make
(BSD Makefiles have a slightly different syntax)XFree86-devel: XFree86 libraries
(needed to build X programs)ImageMagick-devel: ImageMagick libraries
(rarely needed)e2fsprogs-devel: ext2fs libraries
(needed to build low-level filesystem programs)libgr-devel: various graphics libraries
(needed by many graphics programs)ncurses-devel: a full-featured curses library
(needed by many interactive textual programs)slang-devel: the SLang library
(used by some programs)svgalib-devel: a console graphics library
(used by quite a few programs)
Contrary to popular belief, this is not all that difficult. Once you
have patched (see the section on patching) and/or edited it to suit your
system, just configure and build it. For more details, see the Kernel
HOWTO, which is available in usr/doc/HOWTO/Kernel-HOWTO.gz if you
have installed the package howto. (You can view it without
decompressing it by using zmore. If the package is not installed and
your Red Hat CDROM is mounted on /mnt/cdrom, type ``rpm -ivh
/mnt/cdrom/RedHat/RPMS/howto-[1-9]*.rpm'')
A few notes: In recent kernels, you can type ``make xconfig'' or
``make menuconfig'' to run X11 and curses configuration programs
respectively. Both of these provide optional help for their questions, as
do newer versions of the regular configuration script. Other documentation,
which may be newer and/or more complete than that in HOWTOs, can be found in
/usr/src/linux/Documentation.
Always check files called README, INSTALL, or something
equally prominent for program-specific instructions. In general, however,
the presence of an Imakefile indicates that you should probably run
xmkmf -a
make all
and the presence of a Makefile.in indicates that you should try
./configure --prefix=/usr
make all
If there is just a Makefile, try executing ``make all'',
``make'', and ``make progname'' in that order. Otherwise,
you'll have to invoke gcc manually: if the source is in foo.c, try
gcc -c foo.c -o foo.o
gcc foo.o -o foo
to produce an executable called foo.
If the patch is compressed, decompress it. Don't worry about stripping
any leading text (e-mail headers, etc.); patch will do that itself. The
patch itself should start with a path name and a timestamp and then another
line with a different path name and timestamp. See how many directories you
need to drop from the second path name in order to get a name relative to
the source directory of the program you want to patch. (See patch's
manpage or info file for examples and a more detailed explanation.) Now
change to the program's source directory and type patch -s -pn
< patchfile, where n is the number of directories you need
to drop and patchfile is the path to the patch you want to supply. Do
not omit the -p flag even if n is zero; otherwise, directory
structure will not be preserved correctly.
If patch prompts you for a file to patch, you probably got n
wrong; take another look at the patch and try again (leading slashes count
too). If it complains about hunks failing, do not panic. Look at the
resulting .rej files one by one, figure out what changes they are
trying to make, and make them yourself. If you feel uncomfortable doing
this, ask somebody more experienced or politely post a query to an
appropriate mailing list or newsgroup.
Let us suppose that you have a program which you would like to turn in to an RPM. You might need to make some minor changes to the program to customize it for Red Hat Linux. Once you have made any necessary changes, you will need to generate one or more patches for RPM to use.
You can use gendiff to make the patches for your RPM. Just make
sure that for every file foo you modify, you keep an original version
of that file under a name like foo.dist. If you have done this, and
your sources are in the directory newpkg-1.7, just type ``gendiff
newpkg-1.7 .dist > mypatch'' and you'll get a patch you can use (with
-p1 in this case) in your RPM.
If you have made two independent changes (unrelated changes with the
additional property that neither affects a file affected by the other) you
can rename original files foo affected by the first change
foo.dist-1 and files bar affected by the second bar.dist-2;
then you can type ``gendiff newpkg-1.7 .dist-1 > mypatch-1'' and
``gendiff newpkg-1.7 .dist-2 > mypatch-2'' to obtain two separate
patches with very little work.
Then just create a specification file according to the directions in the RPM
HOWTO, which gives numerous examples at varying levels. Note that the
Icon field does not really need to be filled in; if it is left blank,
glint will use a default ``package'' icon.
This document is copyright (C) 1996 by Aaron Ucko. Redistribution of this document is permitted as long as the content remains completely intact and unchanged. In other words, you may reformat and reprint or redistribute only.