[Update] I gave up on 2.7.x. Nothing I did made it work. I removed all the options apart from prefix for compilation of 3.4.0.
That worked. Now onto building ipython, ijulia and other good things (SciPy stack).
We will use 3.x going forward rather than try to remain compatible with 2.x.
Updating our tool chain to include a modern python which will be outside of the distro version. Long … long experience dealing with distro based tools are that they are usually … badly … out of date. Red Hat is shipping a Perl in RHEL6 which has been EOLed since before RHEL shipped … Yeah, its that bad.
So I am setting up our Python 2.7.6 build. And I want to make sure its a 64 bit build in case we want to use large data sets in RAM, big files, etc. So I make sure that the system is compiled with the -m64 option.
Not that I should have to do this … modern 64 bit linux has been mainstream for 10+ years now. 32 bit tools need not apply. But I noticed in the configure output that fseek was seen, but fseek64 was not. And the sizes of ints and other bits suggested a 32 bit focus.
Hmmm. Looking online, others have done a 64 bit build, and no one is reporting problems. Great, we should be in fine shape. Python is a smart tool, we shouldn’t have trouble with this.
Except we did.
root@debian:~/build/ipython-rel-1.2.1# /opt/scalable/bin/python ./setup.py Traceback (most recent call last): File "./setup.py", line 215, in
from distutils.command.upload import upload File "/opt/scalable/lib/python2.7/distutils/command/upload.py", line 7, in from urllib2 import urlopen, Request, HTTPError File "/opt/scalable/lib/python2.7/urllib2.py", line 94, in import httplib File "/opt/scalable/lib/python2.7/httplib.py", line 79, in import mimetools File "/opt/scalable/lib/python2.7/mimetools.py", line 6, in import tempfile File "/opt/scalable/lib/python2.7/tempfile.py", line 32, in import io as _io File "/opt/scalable/lib/python2.7/io.py", line 51, in import _io ImportError: /opt/scalable/lib/python2.7/lib-dynload/_io.so: undefined symbol: PyUnicodeUCS2_Replace
and the magic explanation …
You are using a version of Python that uses a 4-byte representation for Unicode characters, but some C extension module you are importing was compiled using a Python that uses a 2-byte representation for Unicode characters (the default).
The only way to solve this problem is to use extension modules compiled with a Python binary built using the same size for Unicode characters.
No no no no no …
The 1990’s called, and wants its ridiculous ABI scenarios back.
Unicode ABIs at that.
Fine. Will remove all 64 bit compilation options. My Perl is 64 bit. My julia is 64 bit. Why can’t my Python work correctly like this? Maybe 3.x?
Viewed 67992 times by 6540 viewers