DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(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