See section Prerequisites, for what you need to have installed before you can compile these programs.
After that, here's what to do:
sh configurein the top-level directory. This tries to figure out system dependencies and the installation prefix. See section The
configurescript, for options and other information about the
If you encounter problems anywhere along the line, let us know. Known problems are listed below (see section Problems). See section Bugs, for details on how to submit a useful bug report.
(This section is largely from the Autoconf manual, by David MacKenzie.
See section `Running
configure scripts' in Autoconf.)
configure script that comes with the font utilities is
generated automatically by the Autoconf program. You can regenerate
configure by rerunning Autoconf (for example, if a new version of
Autoconf is released); you must arrange for Autoconf to use the macros
in `./aclocal.m4' (see section `Generating
configure' in Autoconf).
The purpose of
configure is to adapt the source code to your
system: for example, the name of the directory header file
(`dirent.h' or `sys/dir.h'), whether an
is available, and so on.
Normally, you do not need to give any options to
cd to the directory with the source code and type
`configure'. Exceptions: if `.' is not in your
you must type `./configure'; if you are using a
non-Bourne-compatible shell on some old systems, you must samp `sh
configure takes a minute or two. While it is running, it
prints some messages that tell what it is doing. If you don't want to
see the messages, run
configure with its standard output
redirected to `/dev/null'; for example, `configure >/dev/null'.
To compile the package in a different directory from the one containing
the source code, you must use a variant of Make that supports the
VPATH variable, such as GNU Make.
cd to the
directory where you want the object files and executables to go and run
configure with the option `--srcdir=dir', where
dir is the directory that contains the source code. Using this
option is unnecessary if the source code is in the parent directory of
the one in which you are compiling;
checks for the source code in `..' if it does not find it in
configure guesses the default installation prefix (we'll call it
$(prefix)) by looking for the directory which contains the
gcc, and using its parent. For example, if
installed as `/usr/local/gnu/bin/gcc',
$(prefix) will be set
You can override this default guess for the installation prefix by giving
configure the option `--prefix=path'. You can also
specify separate installation prefixes for architecture-specific files
and architecture-independent files by giving
configure the option
`--exec_prefix=xpath'. Then xpath will be the prefix
for installing programs and libraries. Data files and documentation
will still use the regular prefix. Normally, all files are installed
using the regular prefix.
You can tell
configure to figure out the configuration for your
system, and record it in `config.status', without actually
configuring the package. To do this, give
`--no-create' option. Later, you can run `./config.status' to
actually configure the package. This option is useful mainly in
`Makefile' rules for updating `config.status' and the
`Makefile' itself. You can also give `config.status' the
`--recheck' option, which makes it rerun
configure with the
same arguments you used before. This is useful if you change
configure ignores any other arguments that you give it.
On systems that require unusual options for compilation or linking that
configure script does not know about, you can give
configure initial values for variables by setting them in the
environment. In Bourne-compatible shells, you can do that on the
command line like this:
CC='gcc -traditional' LIBS=-lposix sh configure
The Make variables that you might want to override with
environment variables when running
(For these variables, any value given in the environment overrides the
configure would choose.)
gccif that is in your
installif you have it,
(For these variables, any value given in the environment is added to
the value that
AC_CONFIG_HEADER(including the file utilities) do not use this variable.
Of course, problems requiring manual intervention (e.g., setting these variables) should ideally be fixed by updating either the Autoconf macros or the `configure.in' file for that package.
To compile and use these programs, the following are necessary:
gawk. This is only needed if you want to use GSrenderfont.
See the section below for information on how to get all these programs.
The canonical source for all GNU software, including the GNU C compiler, GNU make, and Ghostscript, is `prep.ai.mit.edu [126.96.36.199]:pub/gnu'. That directory is replicated at many other sites around the world, including:
wuarchive.wustl.edu gatekeeper.dec.com:pub/GNU uxc.cso.uiuc.edu ftp.uu.net:packages/gnu
archive.eu.net src.doc.ic.ac.uk:gnu ftp.funet.fi nic.funet.fi:pub/gnu ugle.unit.no isy.liu.se ftp.diku.dk
ftp.cs.titech.ac.jp utsun.s.u-tokyo.ac.jp:ftpsync/prep archie.au:gnu
You can also order tapes with GNU software from the Free Software Foundation (thereby supporting the development of the font utilities and the rest of the GNU project); send mail to `email@example.com' for the latest prices and ordering information, or retrieve the file `DISTRIB' from a GNU archive.
The canonical source for the X window system is `export.lcs.mit.edu:pub/R5'. That directory is also shadowed at many other sites, including `gatekeeper.dec.com'. The FSF also sells X distribution tapes.
TeX is more scattered. A complete Unix TeX distribution is available for ftp on the machine `byron.u.washington.edu', or by ordering a tape from the University of Washington (send email to `firstname.lastname@example.org'. What is on `byron' for ftp is often out-of-date, though.
The canonical sources for just Web2C--the port of just TeX, Metafont, and friends to Unix, without DVI processors, fonts, macro packages, etc.---are:
ftp.cs.umb.edu [188.8.131.52]:pub/tex/ (Boston) ics.uci.edu [184.108.40.206]:TeX/ (California) ftp.th-darmstadt.de [220.127.116.11]:pub/tex/src/web2c/ (Germany)
At all these sites, the files to retrieve are `web.tar.Z' and `web2c.tar.Z'.
The DVI-to-PostScript driver we recommend is Tom Rokicki's Dvips, and the X window system driver we recommend is Paul Vojta's XDvi. These programs are available from, respectively,
We have modified XDvi and Dvips to use the same path searching code as the current distribution of TeX and these font utilities; the modified versions are available from `ftp.cs.umb.edu:pub/tex'.
To use Metafont, you must have a file defining output devices. (See section Metafont and BZRto.) We recommend you obtain `modes.mf' from
You can retrieve the document describing all the details of the naming scheme for TeX fonts from
This section lists some things which have caused trouble during installation. If you encounter other problems, please send a bug report. See section Bugs, for how to submit a useful bug report.
__Xsi...), and furthermore that the multibyte functions need to specifically call the dynamic linking functions.) The file `lib/dlsym.c' (from the MIT X distribution) defines the
dlopensymbols, so static linking should work now. If the current setup fails, it might work to change `-lXaw' in the definition of
X_librariesin `lib/defs.make' to the full pathname of the Xaw library.
fmod: the routine takes two doubles, not one. We simply corrected our system include file. You may get compiler warnings for the file `widgets/Bitmap.c' at the lines which use the Xt function
XtIsRealizedon systems which define
(void *) 0. The reason is that macro definition of
XtIsRealizedin `<X11/IntrinsicP.h>' incorrectly compares the result of
NULL, instead of
0. If the warnings bother you, fix `IntrinsicP.h'.
XAPPLRESDIRenvironment variable to that directory. See the tutorial on resources that comes with the MIT X distribution (`mit/doc/tutorial/resources.txt') for more information.