[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
2.3 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 (see Library interface versions in GNU Libtool).
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’, see section 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’.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on March 31, 2014 using texi2html 5.0.