| www.delorie.com/gnu/docs/gmp/gmp_8.html | search |
![]() Buy GNU books! | |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
On systems `*-*-aix[34]*' shared libraries are disabled by default, since
some versions of the native ar fail on the convenience libraries
used. A shared build can be attempted with
./configure --enable-shared --disable-static |
Note that the `--disable-static' is necessary because in a shared build
libtool makes `libgmp.a' a symlink to `libgmp.so', apparently for
the benefit of old versions of ld which only recognise `.a',
but unfortunately this is done even if a fully functional ld is
available.
On systems `arm*-*-*', versions of GCC up to and including 2.95.3 have a bug in unsigned division, giving wrong results for some operands. GMP `./configure' will demand GCC 2.95.4 or later.
iostream, a standard one and
an old pre-standard one (see `man iostream_intro'). GMP can only use the
standard one, which unfortunately is not the default but must be selected by
defining __USE_STD_IOSTREAM. Configure with for instance
./configure --enable-cxx CPPFLAGS=-D__USE_STD_IOSTREAM |
./configure --disable-static --enable-shared |
Static and DLL libraries can't both be built, since certain export directives in `gmp.h' must be different. `--enable-cxx' cannot be used when building a DLL, since libtool doesn't currently support C++ DLLs. This might change in the future.
lib /machine:IX86 /def:_libs/libgmp-3.dll-def cp libgmp-3.lib /my/inst/dir/lib cp _libs/libgmp-3.dll-exp /my/inst/dir/lib/libgmp-3.exp |
MINGW uses `msvcrt.dll' for I/O, so applications wanting to use the GMP I/O routines must be compiled with `cl /MD' to do the same. If one of the other I/O choices provided by MS C is desired then the suggestion is to use the GMP string functions and confine I/O to the application.
`m68k' is taken to mean 68000. `m68020' or higher will give a performance boost on applicable CPUs. `m68360' can be used for CPU32 series chips. `m68302' can be used for "Dragonball" series chips, though this is merely a synonym for `m68000'.
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 PATH. The bug
is fixed in OpenBSD 2.7, so either upgrade or use GNU m4.
In GMP, CPU types `power*' and `powerpc*' will each use instructions
not available on the other, so it's important to choose the right one for the
CPU that will be used. Currently GMP has no assembler code support for using
just the common instruction subset. To get executables that run on both, the
current suggestion is to use the generic C code (CPU `none'), possibly
with appropriate compiler options (like `-mcpu=common' for
gcc). CPU `rs6000' (which is not a CPU but a family of
workstations) is accepted by `config.sub', but is currently equivalent to
`none'.
`sparcv8' or `supersparc' on relevant systems will give a significant performance increase over the V7 code.
g2, g3 and g4, the same way
that the GCC default `-mapp-regs' does (see section `SPARC Options' in Using the GNU Compiler Collection (GCC)).
This makes that code unsuitable for use with the special V9
`-mcmodel=embmedany' (which uses g4 as a data segment pointer),
and for applications wanting to use those registers for special purposes. In
these cases the only suggestion currently is to build GMP with CPU `none'
to avoid the assembler code.
/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).
`i386' selects generic code which will run reasonably well on all x86 chips.
`i586', `pentium' or `pentiummmx' code is good for the intended P5 Pentium chips, but quite slow when run on Intel P6 class chips (PPro, P-II, P-III). `i386' is a better choice when making binaries that must run on both.
`pentium4' and an SSE2 capable assembler are important for best results on Pentium 4. The specific code is for instance roughly a 2x to 3x speedup over the generic `i386' code.
If the CPU selected 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. The same applies to SSE2.
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).
Solaris 2.6 and 2.7 as generate incorrect object code for register
to register movq instructions, and so can't be used for MMX code.
Install a recent gas if MMX code is wanted on these systems.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| webmaster donations bookstore | delorie software privacy |
| Copyright © 2003 by The Free Software Foundation | Updated Jun 2003 |