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 while the compiler have gradually gotten slightly better, the number of problems with the linker and assembler seems to be ever increasing.

Apple decided to use an archaic object file format for Mac OS X, a variant of the old aout format. This format predates dynamic linking. Apparently without proper staffing, they have to reinvent lots of stuff for their obsolete object format. Had they chosen a current object formats, they could have taken more benefit of the the quality work already done within the GNU project.

Here are a few example of serious problems we've run into:

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 tries to handle this, but new Apple assembler/linker sometimes breaks it again. 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