Node:Notes for Package Builds, Next:, Previous:ABI and ISA, Up:Installing GMP


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. 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 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.

Using DESTDIR or a prefix override with make install and a shared libgmpxx may run into a libtool relinking problem, see Known Build Problems.

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 necessitate i386 for x86s, or plain sparc (meaning V7) for SPARCs.

Users who care about speed will want GMP built for their exact CPU type, to make 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.

Note that gmp.h is a generated file, and will be architecture and ABI dependent.