[Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so!

[Alex Martelli]

On Apr 22, 2006, at 1:59 AM, pythonmac-sig-request at python.org wrote:

>  No arbitrary precison math on Mac-tel say it ain't so!

It ain't so.


> The analog of a single gene pool in nature has come to pass for  
> arbitrary precison math (APM) for OS X (native not Python).
> GMP is 'it' for APM as far as I can tell unless I want to write my  
> own.

I believe intel also has libraries (they offered them for beta at  
some point, but I didn't follow through on that), but that's not the  
key point.

> And GMP doesn't compile on Mac-tel and won't for some time:
>
> The current release is 4.2, released 2006-03-26. It fixes all bugs  
> found in 4.1.4, as well as several portability problems. It also  
> adds several new features. Note that we chose not to work around  
> all new GCC bugs in this release. Never forget to do a make check  
> after building the library to make likely it was not miscompiled!
>
> Issues with GMP 4.2:
>
> Miscompilation on several platforms using several different  
> compilers. Remember to run make check!
> GMP does not build on MacInteltoch machines. Since Apple uses their  
> own, creative assembly syntax, it is not trivial to fix this.
Nope. The current maintainer of GMP is apparently Apple-hostile AND  
by his own admission no expert on autoconf/libtools and similar  
blackmagic -- and apparently unable to admit it when he's dead wrong.

Apple's assembly syntax is totally irrelevant here.  The reason make  
check fails is Apple's creative *ld semantics*: an object file inside  
a library file is NOT brought in if the only symbols it satisfies are  
DATA ones.
Make check makes an executable with unresolved symbols because of  
this strange "optimization" in Apple's ld (I dimly remember from the  
past other linkers with this kind of strangeness), that's all.

Enrico Franchi posted to gmp-bugs, two weeks ago, a patch to gmp  4.2  
which I had sent him -- it's a TINY patch (aparts from comments  
explaining why it exists, it's just *THREE* bedraggled lines...!!!):

http://swox.com/list-archives/gmp-bugs/attachments/20060407/f364005b/ 
patch-0001.obj

GMP's maintainer rejected it as "THis is a too ugly patch for  
inclusion in GMP." (!!!).


Anyway, download and apply that patch, and make check passes with  
flying colors.


Then, I had the deadline for the 2nd ed of the Nutshell, then a  
week's vacation at the Grand Canyon, and have been catching up on  
things, so I haven't done any further followthrough - yet.

Once this idiocy is solved, there is another problem: I STILL can't  
link gmpy.so beause I can't make libgmp.a to build properly for  
linkage into a -bundle.  Specifically (with gmpy.sf.net's current CVS  
contents):

brain:~/alex/gmpy alex$ python setup.py build_ext -i
running build_ext
building 'gmpy' extension
creating build/temp.macosx-10.4-fat-2.4
creating build/temp.macosx-10.4-fat-2.4/src
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - 
fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - 
fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/usr/local/include -I/ 
Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c  
src/gmpy.c -o build/temp.macosx-10.4-fat-2.4/src/gmpy.o
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g  
-bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/src/ 
gmpy.o -L/usr/local/lib -lgmp -o gmpy.so
/usr/bin/ld: for architecture i386
/usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation  
entries in non-writable section (__TEXT,__text)
/usr/bin/ld: for architecture ppc
/usr/bin/ld: warning /usr/local/lib/libgmp.a archive's cputype (7,  
architecture i386) does not match cputype (18) for specified -arch  
flag: ppc (can't load from it)
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//ccGbVJa4.out (No such file or  
directory)
error: command 'gcc' failed with exit status 1
brain:~/alex/gmpy alex$

Don't worry about the failure on the ppc branch, that's just because  
the .a is not universal and would presumably result in making a non- 
universal .so -- could be fixed later.  I've tried with a  
nonuniversal 2.4.3 (from Activestate) and THAT halfbug goes away.   
It's yet another TODO item, with lower priority than "the biggie" below.

The biggie is the like:

/usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation  
entries in non-writable section (__TEXT,__text)

I've tried ("manually", i.e. with CFLAGS=... on the ./configure of  
GMP 4.2) various -f flags to try to make libgmp.a PIC (which I assume  
is what's the error's complaining about?) -- -fPIC, -fno-common,  
others; no luck so far.  I've explored every mention on the web of  
this errorcode about "local relocation entries in non-writable  
section", but, no luck so far.

It may be trivial for people more deeply familiar with Apple's  
toolchain (ld most of all) than I am, and I do have several at work I  
can consult on that, but, as I said, I didn't yet have much time for  
followup. Once I understand how to fix it with CFLAGS=..., then I  
must understand how to embed the fix via autoconf/configure/libtools,  
which is scary (MY knowledge of that part being very scarce).   
Finally, there will be the political fight to make the maintainer  
accept the resulting patches.

BTW, the biggie is fully reproducible on PPC Macs, too, so GMP 4.2  
builds on those in a state which still doesn't let gmpy.so link (it  
may feel less urgent just because GMP 4.1.* does build fine;-). I've  
even tried using 4.1.* on mac-intel but it breaks in different ways  
and it seems to me that there's no point fighting with that one,  I  
might well focus my limited time and energy on 4.2!-)

BTW**2, any advice from ANYbody with better grasp of Apple's ld, the  
significance of -bundle vs -dylib, autoconf and friends, etc, etc,  
will be most welcome!-)


Alex