Go to the first, previous, next, last section, table of contents.

Installing GMP

GMP has an autoconf/automake/libtool based configuration system. On a Unix-like system a basic build can be done with 

./configure
make

Some self-tests can be run with 

make check

And you can install (under `/usr/local' by default) with 

make install

If you experience problems, please report them to bug-gmp@gnu.org. (See section Reporting Bugs, for information on what to include in useful bug reports.)

Build Options

All the usual autoconf configure options are available, run `./configure --help' for a summary.

Non-Unix Systems
`configure' needs various Unix-like tools installed. On an MS-DOS system cygwin or djgpp should work. It might be possible to build without the help of `configure', certainly all the code is there, but unfortunately you'll be on your own.
Object Directory
To compile in a separate object directory, cd to that directory, and prefix the configure command with the path to the GMP source directory. For example `../src/gmp/configure'. Not all `make' programs have the necessary features (VPATH) to support this. In particular, SunOS and Slowaris make have bugs that make them unable to build from a separate object directory. Use GNU make instead.
@option{--disable-shared, @option{--disable-static}}
By default both shared and static libraries are built (where possible), but one or other can be disabled. Shared libraries are very slightly slower, having a small cost on each function call, but result in smaller executables and permit code sharing between separate running processes.
@option{--target=CPU-VENDOR-OS}
The build target can be specified in the usual way, for either native or cross compilation. If @option{--target} isn't given, `./configure' builds for the host system as determined by `./config.guess'. On some systems this can't distinguish between different CPUs in a family, and you should check the guess. Running `./config.guess' on the target system will also show the relevant `VENDOR-OS', if you don't already know what it should be. In general, if you want a library that runs as fast as possible, you should configure GMP for the exact CPU type your system uses. However, this may mean the binaries won't run on older members of the family, and might run slower on other members, older or newer. The best idea is always to build GMP for the exact machine type you intend to run it on. The following CPU targets have specific assembly code support. See `configure.in' for which `mpn' subdirectories get used by each. CPUs not listed use generic C code. If some of the assembly code causes problems, the generic C code can be selected with CPU `none'.
@option{CC, @option{CFLAGS}}
The C compiler used is chosen from among some likely candidates, with GCC normally preferred if it's present. The usual `CC=whatever' can be passed to `./configure' to choose something different. For some configurations specific compiler flags are set based on the target CPU and compiler, see `CFLAGS' in the generated `Makefile's. The usual `CFLAGS="-whatever"' can be passed to `./configure' to use something different or to set good flags for systems GMP doesn't otherwise know. Note that if `CC' is set then `CFLAGS' must also be set. This applies even if `CC' is merely one of the choices GMP would make itself. This may change in a future release.
@option{--disable-alloca}
By default, GMP allocates temporary workspace using alloca if that function is available, or malloc if not. If you're working with large numbers and alloca overflows the available stack space, you can build with @option{--disable-alloca} to use malloc instead. malloc will probably be slightly slower than alloca. When not using alloca, it's actually the allocation function selected with mp_set_memory_functions that's used, this being malloc by default. See section Custom Allocation. Depending on your system, the only indication of stack overflow might be a segmentation violation. It might be possible to increase available stack space with limit, ulimit or setrlimit, or under DJGPP with stubedit or _stklen.
@option{--enable-fft}
By default multiplications are done using Karatsuba and 3-way Toom-Cook algorithms, but a Fermat FFT can be enabled, for use on large to very large operands. Currently the FFT is recommended only for knowledgeable users who check the algorithm thresholds for their CPU.
@option{--enable-mpbsd}
The Berkeley MP compatibility library (`libmp.a') and header file (`mp.h') are built and installed only if @option{--enable-mpbsd} is used. See section Berkeley MP Compatible Functions.
@option{MPN_PATH}
Various assembler versions of mpn subroutines are provided, and, for a given CPU target, a search is made though a path to choose a version of each. For example `sparcv8' has path `"sparc32/v8 sparc32 generic"', which means it looks first for v8 code, falls back on plain sparc32, and finally falls back on generic C. Knowledgeable users with special requirements can specify a path with `MPN_PATH="dir list"'. This will normally be unnecessary because all sensible paths should be available under one or other CPU target.
Demonstration Programs
The `demos' subdirectory has some sample programs using GMP. These aren't built or installed, but there's a `Makefile' with rules for them. For instance, `make pexpr' and then `./pexpr 68^975+10'.
Documentation
The document you're now reading is `gmp.texi'. The usual automake targets are available to make `gmp.ps' and/or `gmp.dvi'. Some supplementary notes can be found in the `doc' subdirectory.

ABI and ISA

ABI (Application Binary Interface) refers to the calling conventions between functions, meaning what registers are used and what sizes the various C data types are. ISA (Instruction Set Architecture) refers to the instructions and registers a CPU has available.

Some 64-bit ISA CPUs have both a 64-bit ABI and a 32-bit ABI defined, the latter for compatibility with older CPUs in the family. GMP chooses the best ABI available for a given target system, and this generally gives significantly greater speed.

The burden is on application programs and cooperating libraries to ensure they match the ABI chosen by GMP. Fortunately this presents a difficulty only on a few systems, and if you have one of them then the performance gains are enough to make it worth the trouble.

Some of what's described in this section may change in future releases of GMP.

HPPA 2.0
CPU target `hppa2.0' uses the hppa2.0n 32-bit ABI, but either a 32-bit or 64-bit limb. A 64-bit limb is available on HP-UX 10 or up when using c89. No gcc support is planned for 64-bit operations in this ABI. Applications must be compiled with the same options as GMP, which means 
c89  +DA2.0 +e -D_LONG_LONG_LIMB
A 32-bit limb is used in other cases, and no special compiler options are needed. CPU target `hppa2.0w' uses the hppa2.0w 64-bit ABI, which is available on HP-UX 11 or up when using c89. gcc support for this is in progress. Applications must be compiled for the same ABI, which means 
c89  +DD64
MIPS 3 and 4 under IRIX 6
Targets `mips*-*-irix6*' use the n32 ABI and a 64-bit limb. Applications must be compiled for the same ABI, which means either 
gcc  -mabi=n32
cc   -n32
PowerPC 64
CPU target `powerpc64' uses either the 32-bit ABI or the AIX 64-bit ABI. The latter is used on targets `powerpc64-*-aix*' and applications must be compiled using either 
gcc  -maix64
xlc  -q64
On other systems the 32-bit ABI is used, but with 64-bit limbs provided by long long in gcc. Applications must be compiled using 
gcc  -D_LONG_LONG_LIMB
Sparc V9
On a sparc v9 CPU, either the v8plus 32-bit ABI or v9 64-bit ABI is used. Targets `ultrasparc*-*-solaris2.[7-9]', `sparcv9-*-solaris2.[7-9]' and `sparc64-*-linux*' use the v9 ABI, if the compiler supports it. Other targets use the v8plus ABI (but with as much of the v9 ISA as possible in the circumstances). Note that Solaris prior to 2.7 doesn't save all registers properly, and hence uses the v8plus ABI. For the v8plus ABI, applications can be compiled with either 
gcc  -mv8plus
cc   -xarch=v8plus
For the v9 ABI, applications must be compiled with either 
gcc  -m64 -mptr64 -Wa,-xarch=v9 -mcpu=v9
cc   -xarch=v9
Don't be confused by the names of these options, they're called `arch' but they effectively control the ABI.

Notes for Package Builds

GMP should present no great difficulties for packaging in a binary distribution.

Libtool is used to build the library and `-version-info' is set appropriately, having started from `3:0:0' in GMP 3.0. The GMP 3 series will be upwardly binary compatible in each release, but may be adding additional function interfaces. On systems where libtool versioning is not fully checked by the loader, an auxiliary mechanism may be needed to express that a dynamic linked application depends on a new enough minor version of GMP.

When building a package for a CPU family, care should be taken to use `--target' to choose the least common denominator among the CPUs which might use the package. For example this might necessitate `i386' for x86s, or plain `sparc' (meaning V7) for SPARCs.

Users who care about speed will want GMP built for their exact CPU type, to make use of the available optimizations. Providing a way to suitably rebuild a package may be useful. This could be as simple as making it possible for a user to omit `--target' in a build so `./config.guess' will detect the CPU. But a way to manually specify a `--target' will be wanted for systems where `./config.guess' is inexact.

Notes for Particular Systems

AIX 4.3
Targets `*-*-aix4.[3-9]*' have shared libraries disabled since they seem to fail on AIX 4.3.
OpenBSD 2.6
m4 in this release of OpenBSD has a bug in eval that makes it unsuitable for `.asm' file processing. `./configure' will detect the problem and either abort or choose another m4 in the @env{PATH}. The bug is fixed in OpenBSD 2.7, so either upgrade or use GNU m4.
Sparc V8
Using CPU target `sparcv8' or `supersparc' on relevant systems will give a significant performance increase over the V7 code.
SunOS 4
/usr/bin/m4 lacks various features needed to process `.asm' files, and instead `./configure' will automatically use /usr/5bin/m4, which we believe is always available (if not then use GNU m4).
x86 Pentium and PentiumPro
The Intel Pentium P5 code is good for its intended P5, but quite slow when run on Intel P6 class chips (PPro, P-II, P-III). `i386' is a better choice if you're making binaries that must run on both.
x86 MMX and old GAS
Old versions of GAS don't support MMX instructions, in particular version 1.92.3 that comes with FreeBSD 2.2.8 doesn't (and unfortunately there's no newer assembler for that system). If the target CPU has MMX code but the assembler doesn't support it, a warning is given and non-MMX code is used instead. This will be an inferior build, since the MMX code that's present is there because it's faster than the corresponding plain integer code.
x86 GCC 2.95.2 `-march=pentiumpro'
GCC 2.95.2 miscompiles `mpz/powm.c' when `-march=pentiumpro' is used, so that option is omitted from the @env{CFLAGS} chosen for relevant CPUs. The problem is believed to be fixed in GCC 2.96.

Known Build Problems

You might find more up-to-date information at http://www.swox.com/gmp/.

Generic C on a 64-bit system
When making a generic C build using `--target=none' on a 64-bit system (meaning where unsigned long is 64 bits), BITS_PER_MP_LIMB, BITS_PER_LONGINT and BYTES_PER_MP_LIMB in `mpn/generic/gmp-mparam.h' need to be changed to 64 and 8. This will hopefully be automated in a future version of GMP.
NeXT prior to 3.3
The system compiler on old versions of NeXT was a massacred and old GCC, even if it called itself `cc'. This compiler cannot be used to build GMP, you need to get a real GCC, and install that before you compile GMP. (NeXT may have fixed this in release 3.3 of their system.)
POWER and PowerPC
Bugs in GCC 2.7.2 (and 2.6.3) mean it can't be used to compile GMP on POWER or PowerPC. If you want to use GCC for these machines, get GCC 2.7.2.1 (or later).
Sequent Symmetry
Use the GNU assembler instead of the system assembler, since the latter has serious bugs.
Stripped Libraries
GNU binutils `strip' should not be used on the static libraries `libgmp.a' and `libmp.a', neither directly nor via `make install-strip'. It can be used on the shared libraries `libgmp.so' and `libmp.so' though. Currently (binutils 2.10.0), `strip' extracts archives into a single directory, but GMP contains multiple object files of the same name (eg. three versions of `init.o'), and they overwrite each other, leaving only the one that happens to be last. If stripped static libraries are wanted, the suggested workaround is to build normally, strip the separate object files, and do another `make all' to rebuild. Alternately `CFLAGS' with `-g' omitted can always be used if it's just debugging which is unwanted.
SunOS 4 Native Tools
The setting for GSYM_PREFIX in `config.m4' may be incorrectly determined when using the native grep, leading at link-time to undefined symbols like ___gmpn_add_n. To fix this, after running `./configure', change the relevant line in `config.m4' to `define(<GSYM_PREFIX>, <_>)'. The ranlib command will need to be run manually when building a static library with the native ar. After `make', run `ranlib .libs/libgmp.a', and when using @option{--enable-mpbsd} run `ranlib .libs/libmp.a' too.
VAX running Ultrix
You need to build and install the GNU assembler before you compile GMP. The VAX assembly in GMP uses an instruction (jsobgtr) that cannot be assembled by the Ultrix assembler.

Go to the first, previous, next, last section, table of contents.