Node:Known Build Problems, Previous:Notes for Particular Systems, Up:Installing GMP

Known Build Problems

You might find more up-to-date information at http://swox.com/gmp/.

DJGPP

The DJGPP port of bash 2.03 is unable to run the configure script, it exits silently, having died writing a preamble to config.log. Use bash 2.04 or higher.

make all was found to run out of memory during the final libgmp.la link on one system tested, despite having 64Mb available. A separate make libgmp.la helped, perhaps recursing into the various subdirectories uses up memory.

DESTDIR and shared libgmpxx

make install DESTDIR=/my/staging/area or the same with a prefix override to install to a temporary directory is not fully supported by current versions of libtool when building a shared version of a library which depends on another being built at the same time, like libgmpxx and libgmp.

The problem is that libgmpxx is relinked at the install stage to ensure that if the system puts a hard-coded path to libgmp within libgmpxx then that path will be correct. Naturally the linker is directed to look only at the final location, not the staging area, so if libgmp is not already in that final location then the link will fail.

On systems which don't hard-code library paths, for instance SVR4 style systems such as GNU/Linux, a workaround is to insert a suitable -L in the relink_command of libgmpxx.la after building but before installing. This can be automated with something like

sed '/^relink_command/s:libgmp.la:-L /my/staging/area libgmp.la:' \
    <libgmpxx.la >libgmpxx.new
mv libgmpxx.new libgmpxx.la

GNU binutils strip

GNU binutils strip should not be used on the static libraries libgmp.a and libmp.a, neither directly nor via make install-strip. It can be used on the shared libraries libgmp.so and libmp.so though.

Currently (binutils 2.10.0), strip unpacks an archive then operates on the files, but GMP contains multiple object files of the same name (eg. three versions of init.o), and they overwrite each other, leaving only the one that happens to be last.

If stripped static libraries are wanted, the suggested workaround is to build normally, strip the separate object files, and do another make all to rebuild. Alternately CFLAGS with -g omitted can always be used if it's just debugging which is unwanted.

make syntax error

On certain versions of SCO OpenServer 5 and IRIX 6.5 the native make is unable to handle the long dependencies list for libgmp.la. The symptom is a "syntax error" on the following line of the top-level Makefile.

libgmp.la: $(libgmp_la_OBJECTS) $(libgmp_la_DEPENDENCIES)

Either use GNU Make, or as a workaround remove $(libgmp_la_DEPENDENCIES) from that line (which will make the initial build work, but if any recompiling is done libgmp.la might not be rebuilt).

NeXT prior to 3.3

The system compiler on old versions of NeXT was a massacred and old GCC, even if it called itself cc. This compiler cannot be used to build GMP, you need to get a real GCC, and install that. (NeXT may have fixed this in release 3.3 of their system.)

POWER and PowerPC

Bugs in GCC 2.7.2 (and 2.6.3) mean it can't be used to compile GMP on POWER or PowerPC. If you want to use GCC for these machines, get GCC 2.7.2.1 (or later).

Sequent Symmetry

Use the GNU assembler instead of the system assembler, since the latter has serious bugs.

Solaris 2.6

The system sed prints an error "Output line too long" when libtool builds libgmp.la. This doesn't seem to cause any obvious ill effects, but GNU sed is recommended, to avoid any doubt.

Sparc Solaris 2.7 with gcc 2.95.2 in ABI=32

A shared library build of GMP seems to fail in this combination, it builds but then fails the tests, apparently due to some incorrect data relocations within gmp_randinit_lc_2exp_size. The exact cause is unknown, --disable-shared is recommended.

Windows DLL test programs

When creating a DLL version of libgmp, libtool creates wrapper scripts like t-mul for programs that would normally be t-mul.exe, in order to setup the right library paths etc. This works fine, but the absence of t-mul.exe etc causes make to think they need recompiling every time, which is an annoyance when re-running a make check.