On Apr 22, 2006, at 1:59 AM, [EMAIL PROTECTED] 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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
