[Pythonmac-SIG] GMP bigot now chastened.

[Daniel Lord]

Alex,
Just so you and anyone who cares that our platform get fair treatment  
know. Turns out the Mac bigot was behaving badly again. GMP 4.2  
doesn't compile on PPC macs either and he was blaming Apple's  
compilers. Turns out we figured out a fix involving PIC--it seems  
Linux PPCs have the same problem. So it was gcc problem not an Apple  
one. I called him on and asked that he fix the site to avoid further  
embarassment ( i did that privately) but I publicly asked him to  
include the patches for Apple i386 and PPC in the source and wondered  
why they hadn't been adopted. That struck a nerve so he set my mail  
address to be moderated effectively quarantining me to stifle me. I  
figured this would happen and I didn't care--I got in a few licks and  
he's made a fool of himself. He took down the diatribe against Apple  
at least. In my life experience, I have found that appeasing such  
ignorant fools drunk with power only encourages them. It was a good  
fight, I accomplished what I wanted, and I feel no loss with the gmp  
list--I really only want it to work.

On Apr 22, 2006, at 9:50, Alex Martelli wrote:

>
> 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
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

Daniel Lord
daniellord at mac.com
---
"You will never regret getting up too early,
and you'll always regret getting up too late,
but sometimes you may regret giving up too late."
                           -- Mountaineer's Adage