量子云科技

python使用requests爬取https网站出现EOF occurred in violation of protocol问题

作者: Asser
时间: 2016-06-07
分类:

tensorflow环境搭建后，运行Python test.py(含有import tensorflow as tf的Python程序)
Traceback (most recent call last):
  File "test.py", line 3, in <module>
    import tensorflow as tf
  File "/usr/local/lib/python2.7/site-packages/tensorflow/__init__.py", line 23, in <module>
    from tensorflow.python import *
  File "/usr/local/lib/python2.7/site-packages/tensorflow/python/__init__.py", line 45, in <module>
    from tensorflow.python import pywrap_tensorflow
  File "/usr/local/lib/python2.7/site-packages/tensorflow/python/pywrap_tensorflow.py", line 28, in <module>
    _pywrap_tensorflow = swig_import_helper()
  File "/usr/local/lib/python2.7/site-packages/tensorflow/python/pywrap_tensorflow.py", line 24, in swig_import_helper
    _mod = imp.load_module('_pywrap_tensorflow', fp, pathname, description)
ImportError: libstdc++.so.6:wrong ELF class:ELFCLASS32
这个问题可能是因为64位使用32位的问题,要解决这个问题，首先找对应的版本和使用一致的N位~
因此，进行如下的验证：
[..]# find / -name *libstdc++* -print
/usr/lib64/libstdc++.so.6.0.17
/usr/lib64/libstdc++.so.6
[..]# file /usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6: ELF 32-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
由于看到有libstdc++.so.6.0.17的存在，所以
[..]# file /usr/lib64/libstdc++.so.6.0.17
/usr/lib64/libstdc++.so.6.0.17: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
于是，抱着尝试的心态试了一下，将libstdc++.so.6.0.17代替libstdc++.so.6
mv /usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6_32bits
cp /usr/lib64/libstdc++.so.6.0.17 /usr/lib64/libstdc++.so.6
回到，test.py所在目录下，再次运行Python test.py，发现前面的问题没有了，却报出来另一个错误：
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.19' not found
百度了一番，得知问题是因为编译库的编译器和编译当前程序的编译器版本不一样，再具体一点就是因为，当前程序的编译器的版本是比较低的，于是用如下命令查看一下当前GCC版本：
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
得到如下结果：
GLIBCXX_3.4  
GLIBCXX_3.4.1  
GLIBCXX_3.4.2  
GLIBCXX_3.4.3  
GLIBCXX_3.4.4  
GLIBCXX_3.4.5  
GLIBCXX_3.4.6  
GLIBCXX_3.4.7  
GLIBCXX_3.4.8  
GLIBCXX_3.4.9  
GLIBCXX_3.4.10  
GLIBCXX_3.4.11  
GLIBCXX_3.4.12  
GLIBCXX_3.4.13
GLIBCXX_3.4.14  
GLIBCXX_3.4.15  
GLIBCXX_3.4.16  
GLIBCXX_3.4.17 
GLIBCXX_FORCE_NEW  
GLIBCXX_DEBUG_MESSAGE_LENGTH
并没有要求的GCC版本 “GLIBCXX_3.4.19”，所以需要进行升级一下我们的GCC版本
[..]# ggc -v
gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
本想将gcc升级成gcc-4.8.1就可以解决了，可折腾了好久，升级过程中出现error，升级各种失败，所以需要静一静...
在静了好久以后，发现既然上面可以用libstdc++.so.6.0.17代替libstdc++.so.6解决wrong ELF class:ELFCLASS32的问题，那是不是可以下载更新版本的libstdc++代替libstdc++.so.6，于是在网上下载了64位的libstdc++.so.6.0.20上传至服务器，由于对该资源不是很信任，所以在所在目录下试了
[..]# file libstdc++.so.6.0.20
[..]# strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
得到了结果是ELF 64-bit并且GLIBCXX达到了GLIBCXX_3.4.20，这才放心执行以下命令：
拷贝文件：cp libstdc++.so.6.0.20 /usr/lib64
进入到/usr/lib64：cd /usr/lib64
删除原来的libstdc++.so.6：rm libstdc++.so.6
重新建立软连接：ln libstdc++.so.6.0.20 libstdc++.so.6
再次用strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX查看一下，已经有了3.4.19版本，于是又回到test.py目录下，重试了Python test.py，发现程序可执行了。

libstdc++.so.6.0.20下载：http://download.csdn.net/detail/arackethis/8395651