File:  [gforth] / gforth / INSTALL
Revision 1.25: download - view: text, annotated - select for diffs
Thu Nov 7 22:31:31 1996 UTC (26 years, 2 months ago) by pazsan
Branches: MAIN
CVS tags: v0-2-1, v0-2-0, HEAD
Fixed some things with DOS

You need gcc version 2.0 or later to compile gforth.

First, type


(see Section Configuration Options below for details).

After configuration, type


Now you can check whether your shiny new Forth system works. Say

make test

You can run some benchmarks with

make bench

and compare them with the results in Benchres and in the manual.

If everything is all right, you may want to install gforth. Type

make install

You have to make an entry in the info directory file manually.

For paper documentation, print (a Postscript file (300dpi
fonts, i.e., it works, but does not produce best quality on better
printers)), or say

make gforth.dvi

and print the resulting file gforth.dvi. You can also get the
documentation in HTML format by typing

make html

If you prefer plain ASCII documentation, just concatenate the files* ('cat*' under Unix).

		Configuration Options

If you use GNU make, you can build in a directory different from the
source directory by changing to the build directory and invoking
configure thus:


where $srcdir is the source directory. (Note that we tested this only
for installation; i.e., if you want to hack the Gforth sources, you
should probably build in the source directory).

configure has the following useful parameters:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [default: /usr/local]
  --exec-prefix=PREFIX    install architecture-dependent files in PREFIX
                          [default: same as prefix]
  --enable-force-reg      Use explicit register declarations if they appear in
                          the machine.h file. This can cause a good speedup,
                          but also incorrect code with some gcc versions on
                          some processors (default disabled).
  --enable-direct-threaded      Force direct threading. This may not work on
                                some machines and may cause slowdown on others.
                                (default processor-dependent)
  --enable-indirect-threaded    Force indirect threading. This can cause a
                                slowdown on some machines.
                                (default processor-dependent)
  --with-debug     specifies option -g to compile with debug info (default)
  --without-debug  omits the -g switch and creates smaller images on
                   machines where strip has problems with gcc style
                   debugging informations.
  --help: tells you about other parameters.

The file Benchres shows which combination of the -enable options we
tried gave the best results for various machines.

If you don't like the defaults for the installation directories, you
should override them already during configure.  E.g., if you want to
install in the /gnu hierarchy instead of in the default /usr/local
hierarchy, say

./configure --prefix=/gnu

Moreover, if your GCC is not called gcc (but, e.g., gcc-2.7.1), you
should say so during configuration. E.g.:

env CC=gcc-2.7.1 ./configure

You can also pass additional options to gcc in this way, e.g., if you
want to generate an a.out executable under Linux with gcc-2.7.0:

env "CC=gcc -b i486-linuxaout -V 2.7.0" ./configure

You can change the sizes of the various areas used in the default
image `' by passing the appropriate Gforth command line
options in the FORTHSIZES environment variable:

env "FORTHSIZES=--dictionary-size=256k --data-stack-size=16k --fp-stack-size=16k --return-stack-size=16k --locals-stack-size=16k" ./configure

The line above reaffirms the default sizes. Note that the locals
stack area is also used as input buffer stack.

If C's "long long" do not work properly on your machine (i.e., if the
tests involving double-cell numbers fail), you can build Gforth such
that it does not use "long long":

env ac_cv_sizeof_long_long=0 ./configure


A few tests made by the configure script do not work in a
cross-compilation situation. You have to provide the results of these
tests by hand. E.g., if you compile for a 386 architecture processor:

env ac_cv_sizeof_char_p=4 ac_cv_sizeof_short=2 ac_cv_sizeof_int=4 ac_cv_sizeof_long=4 ac_cv_sizeof_long_long=8 ac_cv_c_bigendian=no ./configure

The ac_cv_sizeof_... variables give the sizes of various C types;
ac_cv_sizeof_char_p is the same as "sizeof(char*)" in C code. The
ac_cv_c_bigendian variable gives the byte order.

		Preloading installation-specific code

If you want to have some installation-specific files loaded when
Gforth starts (e.g., an assembler for your processor), put commands
for loading them into /usr/local/share/gforth/site-forth/site-init.fs
(if the commands work for all architectures) or
/usr/local/lib/gforth/site-forth/site-init.fs (for
architecture-specific commands);
/usr/local/lib/gforth/site-forth/site-init.fs takes precedence if both
files are present (unless you change the search path). The file names
given above are the defaults; if you have changed the prefix, you have
to replace "/usr/local" in these names with your prefix.

By default, the installation procedure creates an empty
/usr/local/share/gforth/site-forth/site-init.fs if there is no such

If you change the site-init.fs file, you should run "make install"
again for the changes to take effect (Actually, the part of "make
install" starting with "rm" is sufficient).

		Multiple Versions and Deinstallation

Several versions of Gforth can be installed and used at the same
time. Version `foo' can be invoked with `gforth-foo'. We recommend to
keep the old version for some time after a new one has been installed.

You can deinstall this version of Gforth with 'make uninstall' and
version foo with 'make uninstall VERSION=foo'. 'make uninstall' also
tells you how to uninstall Gforth completely.

			A Possible Problem

You need to read this only if you see a message like

The Gforth installer should look into the INSTALL file

1) "gforth: Cannot load nonrelocatable image (compiled for address $1234) at address $5678
The Gforth installer should look into the INSTALL file"

Gforth supports both relocatable and fixed-address images. If you load
normal Forth code and save the image, you get a fixed-address
image. Producing a relocatable image is more difficult.

Therefore, Gforth has only a relocatable image of the kernel
(, which is powerful enough to load the rest of
Gforth. However, loading the rest takes a noticable amount of time. To
avoid this delay (which would occur on every startup), the
installation procedure produces an image fixed at an address
determined at the Gforth run that produced the image. This
fixed-address image is loaded by default. On most OSs this works,
because the first chunk of memory is always allocated at the same
address. If the address changes, you get the message above.

An image address change can be caused by a change of the gforth
executable, or by a change (upgrade) of the OS; in these cases you
just have to rebuild and reinstall the fixed address image with

rm; make; make install

If you get such a message with a different address in place of the
$5678 each time you try to start gforth, you cannot use fixed-address
images on your OS. In this case, send us a message so that we start
searching for a comfortable solution to this problem. In the
meantime, start gforth with

gforth -i startup.fs

If the addresses changes by only a small amount (e.g. by one or two
pages), you can fix it by defining FUZZ (in config.h) to a number at
least two times the changes you observe (0x4000 is a good idea, this
is four 4k pages) and recompile. We do this for the DJGPP port for
DOS, because the start address there changes by one or two pages, and
it helps us to keep the DOS people happy without investing too much
work in a braindead environment.

2) "%s: Checksum of image ($13579b) does not match the executable ($2468a)
The Gforth installer should look into the INSTALL file"

A fixed-address image is not only fixed with respect to its base
address, but also with respect to certain addresses in the gforth
executable and the threading method. These things are encoded in a

If the checksum of the executable and the checksum of the image are
not equal, you get the message above. This can be caused, e.g., by
trying to run an image produced for a direct threading system on an
indirect threaded system.

Chances are that you unintentionally tried to execute an image from
the wrong directory. As a remedy, you can specify Gforth's search
path with the "-p" command line option and with the GFORTHPATH
environment variable.

On the other hand, if you need to solve the problem by creating a new
fixed-address image, you can use the steps described above.

FreeBSD-CVSweb <>