5.4 Details, custom compilation
Read this section if you have problems or want to know more. It is
not necessary most of the time.
Most of the development of Gnucap was done on a PC running Linux. I have
also compiled it successfully on several other systems, listed at the
end of this file. Other users have ported it to several other
systems. Some of the files are included in the distribution. They
may not have been tested in the latest release. It should compile
with any “standard” C++ compiler. It should produce no warnings when
compiled with the switches in the supplied makefiles and g++, except
those due to the system supplied header files being defective. It
requires templates, but not exceptions.
All source files are in the src and modelgen directories. I use
subdirectories for the .o files each supported machine. This makes it
possible to install it on several different machines all sharing the
same file system.
To avoid maintaining multiple versions of Makefiles, I have broken
them up to parts that must be concatenated: Make1.*, Make2.*, Make3.*.
In general, to make a Makefile for your system, cat one of each. See
the Makefile for details. I have automated this for some systems.
Just “make your-machine”, if it is one that is supported. In some
cases, the Makefile will compile both a “release” and “debug”
version. In these cases, type “make your-machine-release” or “make
your-machine-debug” depending on which you want. This will make the
appropriate Makefile, cd to where the .o's go and run make from there.
For porting information for specific machines, read its Make2.*
I assume that make will follow “VPATH” to find the sources. This
system makes it possible to manage several platforms on a single file
system which may be NFS mounted to all the supported machines. If
your make does not support VPATH, there are three options. The
preferred method on unix based systems is to cd to where the .o's go
and type ln -s ../*.cc ../*.h .. (The command ends with a dot.)
This will set up links so the Makefiles will work as intended. In
some cases we have set up the Makefile to do this automatically. The
second method, which may be needed on systems that don't have symbolic
links is to copy the .c and .h files to satisfy make. The third
option, where you have only one computer, is to move the machine
specific Makefile to the src directory and run make from there.
If you have g++ on a unix type system that is not directly supported,
try to compile it by just typing make. In most cases this will
do it, but you may get a few warnings. If it doesn't work, look in
the file md.h for hints. Just plain make will build a
guess at a release version, assuming a Linux-like system with GNU
If you want a development version with additional debugging enabled,
type make debug. This results in a significant speed penalty.
Then make the installation version, select the machine you have from
the make file and make that. The machine specific versions will
build in their own directory, have debugging code disabled, and
options are set for best speed. The general purpose make g++
builds a version that is optimized as much as it can be in the
If you have a cfront-type compiler, called CC, and your system
is not directly supported, try it first by typing make CC. Again,
you may get a few warnings but it should work. Look in the file
md.h for hints, if it doesn't work, or if the warnings look
Since C++ is an evolving language, there are some known portability
problems. All of them are due to compilers that do not implement the
standard correctly. Since the problems will go away in time, I have
chosen not to burden the code with them, except where a few
mainstream systems fail. All dependencies should be confined to the
two files md.h and md.cc, if possible.
There should be NO non-portable code anywhere but the md_*
files. If a fix is absolutely necessary elsewhere, #define some
symbol in md.h and refer to it elsewhere. Then consider it to