操作系统python升级后，virtualenv python失败，出现“0”；未定义符号：_PyLong_AsInt¨；简单任务上的错误

我有一个基于python-2.7.3的长时间工作的virtualenv。在接受了推荐的平台操作系统（Ubuntu）更新（其中包括许多其他更改）后，将python提升到2.7.6，virtualenv中的python在基本上所有非平凡的任务上都开始出错，堆栈的结尾如下：

ImportError: /home/myusername/ENVS/myvenv/lib/python2.7/lib-dynload/_io.so: undefined symbol: _PyLong_AsInt

即使是

pip-freeze

也会因为这样的错误而失败——这使得在损坏的virtualenv中甚至无法获得已安装软件包的准确清单（以便重新安装到新的工作virtualenv中）

---

virtualenv不应该受到这种外部升级的保护吗？或者至少在2.7.x系列中

virtualenv引用的是外部安装——在本例中，

myvenv/lib/python2.7/lib-dynload

路径实际上是指向已更新的

/usr/lib/python2.7/lib-dynload

的软链接。那么，也许返回到2.7.3版可以奏效

尝试从python.org下载2.7.3源代码，并使用常用的咒语构建/安装（即使知道这是在破坏系统首选的python，使用完整的系统虚拟机快照可能会有风险）：

仍然没有运气：同样的错误，即使软链接现在指向一个基于2.7.3的资源。但是把system/usr/bin/python-2.7复制到virtualenv中怎么样？（我不愿意使用不同的版本，但在这一点上，为什么不呢？）

这就解决了问题。virtualenv现在正在工作，至少允许对“pip冻结”库存进行一些测试和提取。当然，依赖于2.7.6的外部内容现在可能会被破坏

而且，将system 2.7.6 python可执行文件拉入virtualenv以替换其损坏的版本可能已经足够安全了。（不知道——其他答案/参考资料意味着在virtualenv中升级python时会出现问题，除非以后重新安装所有包，尽管它们主要解决非点式修订，如2.5->2.6。）

您可以简单地执行

cp /usr/bin/python2 /path/to/my-virtualenv/bin/python2

或

---

为我从3.4.0切换到3.4.3（也将同一文件复制到env/bin/python和env/bin/python3.4）工作时，我能够跟踪到以下问题：

cp /usr/bin/python2 /path/to/my-virtualenv/bin/python2

cp /usr/bin/python3 /path/to/my-virtualenv/bin/python3