wangtongada / gmpy

Automatically exported from code.google.com/p/gmpy
GNU Lesser General Public License v3.0
0 stars 0 forks source link

gmpy1.15 build fails to compile due to lack of Py_ssize_t definitions #55

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Attempting to build/install gmpy1.15 on a linux-x86_64 machine with python 2.4. 
 gcc fails on compilation of gmpy.c, burping on anything that needs definitions 
of Py_ssize_t or related symbols.  It appears these symbols were not added to 
python until after 2.4 (I infer this from the abstract in 
http://www.python.org/dev/peps/pep-0353).

Thus it would be helpful if gmpy1.15's setup.py included a test that prohibits 
attempts to build with python < 2.5, similar to how gmpy2 prohibits builds with 
python < 2.6.

For those like me would would like to plow onward with python 2.4, is there any 
simple way to make a substitute .h file that would provide the requisite sizing 
definitions?  I assume these need to be compatible with the sizes in-use when 
python itself was compiled.

Original issue reported on code.google.com by rsharris...@gmail.com on 8 May 2012 at 2:51

GoogleCodeExporter commented 8 years ago
My apologies for jumping the gun in my description.  I find that gmpy 
compensates for a missing Py_ssize_t by defining it in gmp.h.  What it fails to 
compensate for is the related PY_FORMAT_SIZE_T.  By adding a definition for 
this I was able to get rid of all the compile errors, though there are still 
several warnings (for what look to be debug prints).

The definition I used was
    #define PY_FORMAT_SIZE_T ""
just after line 35
    typedef int Py_ssize_t;

That seems like the right thing for PY_FORMAT_SIZE_T given Py_ssize_t being a 
plain old int.

Original comment by rsharris...@gmail.com on 8 May 2012 at 5:46

GoogleCodeExporter commented 8 years ago
Sorry about breaking compatibility with 2.4. 1.14 should compile without 
errors. I added the PY_FORMAT_SIZE_T in 1.15 while trying to eliminate compiler 
warnings on Windows. Your fix is correct.

You can ignore the warnings in the debug print statements.

I've created a 1.16 under tags in the svn repository so the fix will be around. 
Unless you need an official release, I probably won't release it soon unless I 
find a critical bug.

Original comment by casevh on 9 May 2012 at 4:49