|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
||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 ||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?
-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
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: