Symbol not found: __PyCodecInfo_GetIncrementalDecoder

Posted on

Question :

Symbol not found: __PyCodecInfo_GetIncrementalDecoder

Since updating from Homebrew Python 2.7.11 (from 2.7.10) I’m suddenly unable to test register my package on PyPi from the PyCharm IDE console.

Running (as an “External Tool”)

python -B setup.py register -r pypitest

I now get

Traceback (most recent call last):
  File "setup.py", line 22, in <module>
    from setuptools import setup
  File "/usr/local/lib/python2.7/site-packages/setuptools/__init__.py", line 12, in <module>
    from setuptools.extension import Extension
  File "/usr/local/lib/python2.7/site-packages/setuptools/extension.py", line 8, in <module>
    from .dist import _get_unpatched
  File "/usr/local/lib/python2.7/site-packages/setuptools/dist.py", line 16, in <module>
    from setuptools.depends import Require
  File "/usr/local/lib/python2.7/site-packages/setuptools/depends.py", line 6, in <module>
    from setuptools import compat
  File "/usr/local/lib/python2.7/site-packages/setuptools/compat.py", line 17, in <module>
    import httplib
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 80, in <module>
    import mimetools
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/mimetools.py", line 6, in <module>
    import tempfile
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tempfile.py", line 32, in <module>
    import io as _io
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
    import _io
ImportError: dlopen(/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
  Referenced from: /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
  Expected in: flat namespace
 in /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so

Process finished with exit code 1

I’m not sure how to proceed. I only get this issue if I execute from within my IDE’s console. If I do it directly at the system command line (Terminal on OS X) I have no problems.


OS X 10.11.3; Homebrew Python 2.7.11; PyCharm 5.0.3

Asked By: orome

||

Answer #1:

tl;dr: Fix this issue by doing one of the following:

  • type hash -r python, OR
  • log out and log in.

EDIT: An answer to my related question makes it clear what’s happening here. When you install a new version of python, you may need to run hash -r python to tell bash to reset the “cached” location to the python executable.

In my case, I was typing python, which was on my $PATH at /usr/local/bin/python. But bash was still using the old cache location /usr/bin/python. So, the old executable was called, but the new path was provided to python in sys.argv[0]. This means that the old executable was running, but the new sys.executable value caused all the wrong modules to get loaded (including the io module).


I’m having the same problem. I installed python 2.7.11 via an installer from Python.org. Strangely, the issue seems to be related to some subtle difference between how OSX launches python when I invoke it from the shell using the full path vs. using just the word python.

So, for me, this works (invoking python via the full path /usr/local/bin/python):

$ which python
/usr/local/bin/python
$ /usr/local/bin/python -c "import io"
$

… but this doesn’t:

$ python -c "import io"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
    import _io
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
  Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
  Expected in: flat namespace
 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so

So, as a workaround, you can try doing the same thing.

Elsewhere, I’ve posted a separate question about this puzzling behavior. Maybe somehow merely calling python invokes some strange mix of the 2.7.11 executable with the 2.7.10 dylibs??

Answered By: Stuart Berg

Answer #2:

According to https://github.com/klen/python-mode/issues/634:

I had the same issue, but successfully fixed. In my case I compiled
python and vim with homebrew, when PYTHON_PATH has been specified and
set to one of my dev environments, where I also had some libraries,
including io. Workaround was simple: open new terminal, make sure that
you do not have custom PYTHON_PATH, uninstall python, uninstall vim.
Reinstall both of them.

and

Problem solved.

Culprit is the update from python 2.7.10 to 2.7.11.

If you are using conda package control, simply run “conda install
python=2.7.10” will solve this problem.

This doesn’t give the root cause though. Since this happens with _io, this looks like a bug in python 2.7.11 (unlikely, there would be a world-scale outcry and a prompt fix if it was) or some packaging bug or version mismatch specifically with the homebrew version (and maybe some related ones, too).

Try to import _io in the console and if it succeeds, check if it was loaded from the same path.

Answered By: ivan_pozdeev

Answer #3:

Reinstall python.

brew unlink python && brew reinstall python

Secure the path

export PYTHONPATH=$PYTHONPATH:/usr/local/bin/

BACKUP and Change the order of “paths” file.

sudo nano /etc/paths

it seems, the order of paths, it is decisive to run python properly. In my case, the result was:

#sudo nano /etc/paths
  /usr/bin  
  /usr/local/bin
  /bin
  /usr/sbin
  /sbin

On my mac, path is like this.

$ which python
    /usr/local/bin/python

Now I can run both:

$ /usr/local/bin/python -c "import io"
$ python -c "import io"
Answered By: Noel Ruault

Answer #4:

I had the same issue, it is successfully fixed by just replacing the _io.so file.

sudo find / -name _io.so

copy the path of the _io.so file which DOES NOT belong to python-2.7.11. For example, copy the path of _io.so which is under python-2.7.5:
/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so

Replace the /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so file with the _io.so that you just found.

Answered By: Yanan

Answer #5:

This happened to me as well in MacVim. I solved it by making sure :python print(sys.path) is using system Python (e.g. /Library/Python/2.7/...)

Since I installed MacVim via Homebrew, I just did that by:

  1. Spawn a new shell that had which python -> /usr/bin/python. For my case I needed to remove the pyenv line from my .bash_profile. If you installed Python via Homebrew you may want to brew unlink python first

  2. brew reinstall macvim

Answered By: kizzx2

Answer #6:

If your problem is caused by anaconda, it is unnecessary to remove //anaconda directory.

Just open your ~/.bash_profile, find the line

export PATH="//anaconda/bin:$PATH

and comment it out, then restart your terminal session.

Answer #7:

Another quick workaround if you don’t mind sticking with Python 2.7.10 is to specify the path of the Python interpreter executable that will be used for the virtualenv. On OSX that path is usually /usr/bin/python:

virtualenv venv --python=/usr/bin/python
Answered By: skeller88

Answer #8:

Can’t add comment (?) so this just to share my exp., downgrade to 2.7.10 works fr me.

Answered By: tngn

Leave a Reply

Your email address will not be published. Required fields are marked *