GMP and Mac OS

This page is an attempt to help and caution GMP users of the problems to expect when compiling GMP on Mac OS.

Most people use Apple's "Xcode" bundles for compilation on these systems. Unfortunately, of the many Xcode releases we've tried, none has worked properly. The most common problem is that the compiler generates incorrect code. But there have also been problems with the linker and assembler.

Please do not report any problem you encounter with building or running GMP on Apple systems to us, if you've used Xcode. You're on your own here. You might want to report Apple's bugs to Apple, though.

Here is a partial list of problems we've run into recently:

Problem Description	Systems Affected
Using Xcode 2.4.1 for PPC and X86 systems using the 64-bit ABI, you cannot build the Berkeley MP compatible functions due to a linker bug. (This used to work with older releases, but we do not know at what point Apple introduced this bug.)	PPC/64 and X86/64
Using Xcode 2.4.1, the assembler fails to return with an error exit code, when given command line options it does not understand. It outputs a flurry of error messages, though. The autoconf system as used in GMP then assumes the option works, resulting in a failed build. (This used to work with older releases, but we do not know at what point Apple introduced this bug.)	PPC/32
Apple uses unique conventions for position independent code (PIC) on X86/32. The GMP assembly code does not yet handle this. Your remedy is to either disable the assembly code by passing --host=none-apple-darwin to configure, or use the 64-bit ABI. The latter will give far superior performance, but is not always an option, since it requires a 64-bit X86 processor, for example.	X86/32 and X86/64
The linker has a long-standing and serious bug that causes references from one file to common data in another file to give spurious error messages about undefined symbols, unless there are also references to the text segment between the same files.	X86/32
A non-pic build using the 32-bit ABI on X86 provokes a linker bug. It is triggered by even a trivial hello.c program	X86/32
Running make check makes some tool, presumably the linker, output many null characters to stdout/stderr. We have not isolated it, as it is just a minor nuisance.	X86/32

Apple got the options controlling PIC code generation all messed up wrt the various ABIs they attempt to support. PIC is the default on all the ABIs, but how do we create a non-pic binary, for best speed?

On X86/32, -fno-pic makes gcc emit non-pic code. Logical, isn't it? But on X86/64, -fno-pic doesn't seem to have any effect whatsoever. Another option, -fno-common, makes gcc emit non-pic code.

To make things worse, it seems non-pic code never works with the X86/32 ABI:

sill$ gcc -fno-pic -m32 ~/hello.c
/usr/bin/ld: /var/tmp//ccq4V1c6.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_puts