Symbol not found: __PyCodecInfo_GetIncrementalDecoder
Solution 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??
Solution 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.
Solution 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"
Solution 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.
Solution 5
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.
orome
"I mingle the probable with the necessary and draw a plausible conclusion from the mixture."
Updated on July 05, 2022Comments
-
orome almost 2 years
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
-
orome over 8 yearsWeirdly, 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. I suspect the path in my IDE.
-
ivan_pozdeev over 8 years@raxacoricofallapatorius check environments, executable paths and
sys.path
for differences. -
orome over 8 yearsAlso checking here, since it's IDE-specific.
-
Codious-JR over 8 yearsthank you @ivan_pozdeev. Downgrading from python 2.7.11 to 2.7.10 fixed the problem
-
skybondsor over 8 years@Codious-JR How did you downgrade? I am having the hardest time figuring that out (using homebrew, not conda)
-
skybondsor over 8 yearsI'm not using anaconda, tho at this point I'm starting to think installing it will be my easiest path forward since homebrew doesn't have previous versions of python "on tap"
-
Codious-JR over 8 yearshey @skybondsor, i am using anaconda, so the command conda install python=2.7.10 worked for me. Is there any specific reason why you don't want to use anaconda? cause otherwise i really recommend using it.
-
Codious-JR over 8 years@skybondsor I found the previous releases page on python.org, here you can find the mac installer for the version 2.7.10. python version 2.7.10
-
Stuart Berg over 8 yearsThe fundamental problem here is that bash's
hash
cache can become incorrect immediately after you install a new version of python. (Trytype python
to verify that's the problem.) The person you quoted may have accidentally fixed this via all the uninstalling/reinstalling they described, but the straightforward fix is to typehash -r python
into the terminal. -
Tim Smith over 8 yearsMixing and matching extension modules from Python 2.7.11 and the system Python, which is 2.7.10 on recent systems, is a very crude way to resolve this issue. The root problem is that Python 2.7.10 is attempting to import a module that belongs to 2.7.11; the symbol is defined in 2.7.11 but not 2.7.10. A better solution is to understand why Python 2.7.10 is being invoked at all.
-
Yanan over 8 yearsThanks Tim. I run into this problem when using Anaconda. Anaconda2.4.1 has scipy-0.16.0 as one of the dependencies, and scipy-0.16.0 requires python 2.7.11. The default python in Anaconda is 2.7.10 (as well as the rest of the dependent libs are using 2.7.10), so that after upgrading to the newest Anaconda, I was unable to use it. While I'm waiting for the official bug fix of Anaconda, I need to run several conda scripts. So I decided to use this crude way to resolve the issue temporarily.
-
Tuxdude over 8 yearsI had installed
macvim
using an older version of Python and after upgrading Python, my vim was giving me this error every time when a plugin wanted to use python modules. Runningbrew upgrade macvim
upgraded my vim to be built using the updated python path. This fixed the issue for me. PS: At least for me, it was not a bash caching issue as mentioned in the above post. -
GiriB about 8 yearslogin and logout worked. Notably I had installed python using brew during the session.
-
Sergey Orshanskiy about 8 yearsAlso see joernhees.de/blog/2014/02/25/…
-
James McLaughlin about 8 yearsThis fixed it for me. Thanks!
-
gogasca about 8 yearsAfter installing Dato Launcher I had this issue. After trying many of the options above this helped.
-
Srini almost 8 yearsGotta love StackOverflow!!
-
Sisyphus almost 8 yearsif
hash -r python
says too many args, you can userehash
command.