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

[Daniel Lord]

On Apr 22, 2006, at 9:50, Alex Martelli wrote:
>
>> 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

Thanks Alex! I'll give this a try. I have to believe there is a way  
around this--we just need to find the right person at Apple. I know  
someone who might know someone...

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

Given the importance of scientific and academic computing to Apple,  
someone at Apple should hear about this unacceptable and behavior and  
deal with it 'appropriately'.
If not, I think Karl Rove has a little time on his hands before the  
election ;-)

Volunteering for the role of maintainer is a role of stewardship that  
requires a reticence in the face of criticism and histrionics as well  
as a dedication to serve the community. But sometimes unfortunately,  
it is done more out of ego, a need to control, and a desire to mete  
out petty revenge on mere mortals from on high. If that's the case  
here, it would be a real shame--let's hope its not. Perhaps we just  
misunderstand his position and Apple can help with detente.

I'll try to do what I can to help with gmpy though the inner workings  
of ld are probably too arcane and labyrinthine for me.

> 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