| www.delorie.com/gnu/docs/gmp/gmp_5.html | search |
 Buy GNU books! | |
| www.delorie.com/gnu/docs/gmp/gmp_5.html | search |
|
Buy GNU books! | |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
All the usual autoconf configure options are available, run `./configure --help' for a summary. The file `INSTALL.autoconf' has some generic installation information too.
`configure' requires various Unix-like tools. On an MS-DOS system DJGPP can be used, and on MS Windows Cygwin or MINGW can be used,
http://www.cygnus.com/cygwin http://www.delorie.com/djgpp http://www.mingw.org |
Microsoft also publishes an Interix "Services for Unix" which can be used to build GMP on Windows (with a normal `./configure'), but it's not free software.
The `macos' directory contains an unsupported port to MacOS 9 on Power Macintosh, see `macos/README'. Note that MacOS X "Darwin" should use the normal Unix-style `./configure'.
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.
To compile in a separate build directory, cd to that directory, and
prefix the configure command with the path to the GMP source directory. For
example
cd /my/build/dir /my/sources/gmp-4.1.2/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 in a separate directory. Use GNU make
instead.
By default both shared and static libraries are built (where possible), but one or other can be disabled. Shared libraries result in smaller executables and permit code sharing between separate running processes, but on some CPUs are slightly slower, having a small cost on each function call.
For normal native compilation, the system can be specified with `--build'. By default `./configure' uses the output from running `./config.guess'. On some systems `./config.guess' can determine the exact CPU type, on others it will be necessary to give it explicitly. For example,
./configure --build=ultrasparc-sun-solaris2.7 |
In all cases the `OS' part is important, since it controls how libtool generates shared libraries. Running `./config.guess' is the simplest way to see what it should be, if you don't know already.
When cross-compiling, the system used for compiling is given by `--build' and the system where the library will run is given by `--host'. For example when using a FreeBSD Athlon system to build GNU/Linux m68k binaries,
./configure --build=athlon-pc-freebsd3.5 --host=m68k-mac-linux-gnu |
Compiler tools are sought first with the host system type as a prefix. For
example m68k-mac-linux-gnu-ranlib is tried, then plain
ranlib. This makes it possible for a set of cross-compiling tools
to co-exist with native tools. The prefix is the argument to `--host',
and this can be an alias, such as `m68k-linux'. But note that tools
don't have to be setup this way, it's enough to just have a PATH with a
suitable cross-compiling cc etc.
Compiling for a different CPU in the same family as the build system is a form of cross-compilation, though very possibly this would merely be special options on a native compiler. In any case `./configure' avoids depending on being able to run code on the build system, which is important when creating binaries for a newer CPU since they very possibly won't run on the build system.
In all cases the compiler must be able to produce an executable (of whatever
format) from a standard C main. Although only object files will go to
make up `libgmp', `./configure' uses linking tests for various
purposes, such as determining what functions are available on the host system.
Currently a warning is given unless an explicit `--build' is used when
cross-compiling, because it may not be possible to correctly guess the build
system type if the PATH has only a cross-compiling cc.
Note that the `--target' option is not appropriate for GMP. It's for use when building compiler tools, with `--host' being where they will run, and `--target' what they'll produce code for. Ordinary programs or libraries like GMP are only interested in the `--host' part, being where they'll run. (Some past versions of GMP used `--target' incorrectly.)
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 CPUs have specific support. See `configure.in' for details of what code and compiler options they select.
CPUs not listed will use generic C code.
If some of the assembly code causes problems, or if otherwise desired, the generic C code can be selected with CPU `none'. For example,
./configure --host=none-unknown-freebsd3.5 |
Note that this will run quite slowly, but it should be portable and should at least make it possible to get something running if all else fails.
On some systems GMP supports multiple ABIs (application binary interfaces), meaning data type sizes and calling conventions. By default GMP chooses the best ABI available, but a particular ABI can be selected. For example
./configure --host=mips64-sgi-irix6 ABI=n32 |
See 2.2 ABI and ISA, for the available choices on relevant CPUs, and what applications need to do.
By default 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 systems, default compiler flags are set based on the CPU and compiler. 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.
The `CC' and `CFLAGS' used are printed during `./configure', and can be found in each generated `Makefile'. This is the easiest way to check the defaults when considering changing or adding something.
Note that when `CC' and `CFLAGS' are specified on a system supporting multiple ABIs it's important to give an explicit `ABI=whatever', since GMP can't determine the ABI just from the flags and won't be able to select the correct assembler code.
If just `CC' is selected then normal default `CFLAGS' for that compiler will be used (if GMP recognises it). For example `CC=gcc' can be used to force the use of GCC, with default flags (and default ABI).
Any flags like `-D' defines or `-I' includes required by the preprocessor should be set in `CPPFLAGS' rather than `CFLAGS'. Compiling is done with both `CPPFLAGS' and `CFLAGS', but preprocessing uses just `CPPFLAGS'. This distinction is because most preprocessors won't accept all the flags the compiler does. Preprocessing is done separately in some configure tests, and in the `ansi2knr' support for K&R compilers.
A separate `libgmpxx.la' has been adopted rather than having C++ objects within `libgmp.la' in order to ensure dynamic linked C programs aren't bloated by a dependency on the C++ standard library, and to avoid any chance that the C++ compiler could be required when linking plain C programs.
`libgmpxx.la' will use certain internals from `libgmp.la' and can only be expected to work with `libgmp.la' from the same GMP version. Future changes to the relevant internals will be accompanied by renaming, so a mismatch will cause unresolved symbols rather than perhaps mysterious misbehaviour.
In general `libgmpxx.la' will be usable only with the C++ compiler that built it, since name mangling and runtime support are usually incompatible between different compilers.
g++ normally preferred when available. The default for
`CXXFLAGS' is to try `CFLAGS', `CFLAGS' without `-g', then
for g++ either `-g -O2' or `-O2', or for other compilers
`-g' or nothing. Trying `CFLAGS' this way is convenient when using
`gcc' and `g++' together, since the flags for `gcc' will
usually suit `g++'.
It's important that the C and C++ compilers match, meaning their startup and runtime support routines are compatible and that they generate code in the same ABI (if there's a choice of ABIs on the system). `./configure' isn't currently able to check these things very well itself, so for that reason `--disable-cxx' is the default, to avoid a build failure due to a compiler mismatch. Perhaps this will change in the future.
Incidentally, it's normally not good enough to set `CXX' to the same as
`CC'. Although gcc for instance recognises `foo.cc' as
C++ code, only g++ will invoke the linker the right way when
building an executable or shared library from object files.
GMP allocates temporary workspace using one of the following three methods, which can be selected with for instance `--enable-alloca=malloc-reentrant'.
For convenience, the following choices are also available. `--disable-alloca' is the same as `--enable-alloca=no'.
alloca if available, otherwise
`malloc-reentrant'. This is the default.
alloca if available, otherwise
`malloc-notreentrant'.
alloca is reentrant and fast, and is recommended, but when working with
large numbers it can overflow the available stack space, in which case one of
the two malloc methods will need to be used. Alternately it might be possible
to increase available stack with limit, ulimit or
setrlimit, or under DJGPP with stubedit or
_stklen. Note that depending on the system the only indication of
stack overflow might be a segmentation violation.
`malloc-reentrant' is, as the name suggests, reentrant and thread safe, but `malloc-notreentrant' is faster and should be used if reentrancy is not required.
The two malloc methods in fact use the memory allocation functions selected by
mp_set_memory_functions, these being malloc and friends by
default. See section 14. Custom Allocation.
An additional choice `--enable-alloca=debug' is available, to help when debugging memory related problems (see section 3.12 Debugging).
By default multiplications are done using Karatsuba, 3-way Toom-Cook, and Fermat FFT. The FFT is only used on large to very large operands and can be disabled to save code size if desired.
The Berkeley MP compatibility library (`libmp') and header file (`mp.h') are built and installed only if `--enable-mpbsd' is used. See section 13. Berkeley MP Compatible Functions.
The optional MPFR functions are built and installed only if `--enable-mpfr' is used. These are in a separate library `libmpfr.a' and are documented separately too (see section `Introduction to MPFR' in MPFR).
This option enables some consistency checking within the library. This can be of use while debugging, see section 3.12 Debugging.
Profiling support can be enabled either for prof or gprof.
This adds `-p' or `-pg' respectively to `CFLAGS', and for some
systems adds corresponding mcount calls to the assembler code.
See section 3.13 Profiling.
Various assembler versions of each mpn subroutines are provided. For a given CPU, a search is made though a path to choose a version of each. For example `sparcv8' has
MPN_PATH="sparc32/v8 sparc32 generic" |
which means look first for v8 code, then plain sparc32 (which is v7), and finally fall back on generic C. Knowledgeable users with special requirements can specify a different path. Normally this is completely unnecessary.
The document you're now reading is `gmp.texi'. The usual automake targets are available to make PostScript `gmp.ps' and/or DVI `gmp.dvi'.
HTML can be produced with `makeinfo --html', see section `Generating HTML' in Texinfo. Or alternately `texi2html', see section `About' in Texinfo To HTML.
PDF can be produced with `texi2dvi --pdf' (see section `PDF Output' in Texinfo) or with `pdftex'.
Some supplementary notes can be found in the `doc' subdirectory.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| webmaster donations bookstore | delorie software privacy |
| Copyright © 2003 by The Free Software Foundation | Updated Jun 2003 |