(gmp.info.gz) Notes for Package Builds
Info Catalog
(gmp.info.gz) ABI and ISA
(gmp.info.gz) Installing GMP
(gmp.info.gz) Notes for Particular Systems
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 ( Library
interface versions (libtool)Versioning.).
The GMP 4 series will be upwardly binary compatible in each release
and will be upwardly binary compatible with all of the GMP 3 series.
Additional function interfaces may be added in each release, so 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 GMP.
An auxiliary mechanism may also be needed to express that
`libgmpxx.la' (from `--enable-cxx', Build Options) requires
`libgmp.la' from the same GMP version, since this is not done by the
libtool versioning, nor otherwise. A mismatch will result in
unresolved symbols from the linker, or perhaps the loader.
When building a package for a CPU family, care should be taken to use
`--host' (or `--build') to choose the least common denominator among
the CPUs which might use the package. For example this might mean plain
`sparc' (meaning V7) for SPARCs.
For x86s, `--enable-fat' sets things up for a fat binary build,
making a runtime selection of optimized low level routines. This is a
good choice for packaging to run on a range of x86 chips.
Users who care about speed will want GMP built for their exact CPU
type, to make best 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 `--build' (and `--host') so
`./config.guess' will detect the CPU. But a way to manually specify a
`--build' will be wanted for systems where `./config.guess' is inexact.
On systems with multiple ABIs, a packaged build will need to decide
which among the choices is to be provided, see ABI and ISA. A
given run of `./configure' etc will only build one ABI. If a second
ABI is also required then a second run of `./configure' etc must be
made, starting from a clean directory tree (`make distclean').
As noted under "ABI and ISA", currently no attempt is made to follow
system conventions for install locations that vary with ABI, such as
`/usr/lib/sparcv9' for `ABI=64' as opposed to `/usr/lib' for `ABI=32'.
A package build can override `libdir' and other standard variables as
necessary.
Note that `gmp.h' is a generated file, and will be architecture and
ABI dependent. When attempting to install two ABIs simultaneously it
will be important that an application compile gets the correct `gmp.h'
for its desired ABI. If compiler include paths don't vary with ABI
options then it might be necessary to create a `/usr/include/gmp.h'
which tests preprocessor symbols and chooses the correct actual `gmp.h'.
Info Catalog
(gmp.info.gz) ABI and ISA
(gmp.info.gz) Installing GMP
(gmp.info.gz) Notes for Particular Systems
automatically generated byinfo2html