PycURL-7.15.5，POST数据异常引起的一系列问题

原文地址：http://blog.itblood.com/pycurl-7-15-5%EF%BC%8Cpost-data-error.html




在CentOS release 5.7，x86_64系统中，使用PycURL-7.15.5，在调用setopt(pycurl.POSTFIELDS)时，抛出”pycurl.error: (2, ”)”异常，后来在其官方网站的ChangeLog中找到解决方法，这个Bug已经在Version 7.16.2.1中修复，只要下载新版本就可以了。

将最新版本Version 7.19.0下载解压，安装后又提示：
src/pycurl.c:61:4: error: #error “Need libcurl version 7.19.0 or greater to compile pycurl.” ，libcurl的版本太低。


curl --version
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b
zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
当前为系统自带的7.15.5的版本，yum库中最新的就是这个，只能到libcurl官方网站下载最新版本了。

[root@localhost src]# cd curl-7.21.2
[root@localhost curl-7.21.2]# configure && make && make install
之后顺利安装pycurl-7.19.0，在python shell中测试又出现新的问题:

[root@localhost pycurl-7.19.0]# python
Python 2.4.3 (#1, Sep  3 2009, 15:37:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information
>>> import pycurl
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: libcurl.so.4: cannot open shared object file:
No such file or directory
>>>
提示找不到共享库libcurl.so.4，按照网上找的资料做软连接

[root@localhost pycurl-7.19.0]# find /usr -name "libcurl.so*"
/usr/local/src/curl-7.21.4/lib/.libs/libcurl.so
/usr/local/src/curl-7.21.4/lib/.libs/libcurl.so.4
/usr/local/src/curl-7.21.4/lib/.libs/libcurl.so.4.2.0
/usr/local/lib/libcurl.so
/usr/local/lib/libcurl.so.4
/usr/local/lib/libcurl.so.4.2.0
/usr/lib/libcurl.so.3.0.0
/usr/lib/libcurl.so.3
/usr/lib/libcurl.so
/usr/lib64/libcurl.so.3.0.0
/usr/lib64/libcurl.so.3
/usr/lib64/libcurl.so

[root@localhost pycurl-7.19.0]# ln -s  /usr/local/lib/libcurl.so.
4.2.0 /usr/lib64/libcurl.so.4
我这里还是不行，于是又找了另一种方法：

export LD_LIBRARY_PATH=/usr/local/lib
这个只对当前shell有效，想永久有效，需要把这个加到/etc/bashrc，或/etc/profile，或～/.bash_profile中，可是总觉得似乎不是那么完美。

下面附上LD_LIBRARY_PATH的说明：

在 Linux 下面，共享库的寻找和加载是由 /lib/ld.so 实现的。 ld.so 在标准路经(/lib, /usr/lib) 中寻找应用程序用到的共享库。

但是，如果需要用到的共享库在非标准路经，ld.so 怎么找到它呢？

目前，Linux 通用的做法是将非标准路经加入 /etc/ld.so.conf，然后运行 ldconfig 生成 /etc/ld.so.cache。 ld.so 加载共享库的时候，会从 ld.so.cache 查找。

传统上，Linux 的先辈 Unix 还有一个环境变量：LD_LIBRARY_PATH 来处理非标准路经的共享库。ld.so 加载共享库的时候，也会查找这个变量所设置的路经。

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./lib
export LD_LIBRARY_PATH

但是，有不少声音主张要避免使用 LD_LIBRARY_PATH 变量，尤其是作为全局变量。这些声音是：
* LD_LIBRARY_PATH is not the answer
* Why LD_LIBRARY_PATH is bad
* LD_LIBRARY_PATH – just say no

解决这一问题的另一方法是在编译的时候通过 -R<path> 选项指定 run-time path。

1. 往/lib和/usr/lib里面加东西，是不用修改/etc/ld.so.conf的，但是完了之后要调一下ldconfig，不然这个library 会找不到

2. 想往上面两个目录以外加东西的时候，一定要修改/etc/ld.so.conf，然后再调用ldconfig，不然也会找不到。

比如安装了一个mysql到/usr/local/mysql，mysql有一大堆library在/usr/local/mysql/lib下 面，这时就需要在/etc/ld.so.conf下面加一行/usr/local/mysql/lib，保存过后ldconfig一下，新的 library才能在程序运行时被找到。

3. 如果想在这两个目录以外放lib，但是又不想在/etc/ld.so.conf中加东西（或者是没有权限加东西）。那也可以，就是export一个全局变 量LD_LIBRARY_PATH，然后运行程序的时候就会去这个目录中找library。一般来讲这只是一种临时的解决方案，在没有权限或临时需要的时 候使用。

4. ldconfig做的这些东西都与运行程序时有关，跟编译时一点关系都没有。编译的时候还是该加-L就得加，不要混淆了。

5. 总之，就是不管做了什么关于library的变动后，最好都ldconfig一下，不然会出现一些意想不到的结果。不会花太多的时间，但是会省很多的事。

LD_LIBRARY_PATH 这个环境变量是大家最为熟悉的，它告诉loader：在哪些目录中可以找到共享库。可以设置多个搜索目录，这些目录之间用冒号分隔开。在linux下，还 提供了另外一种方式来完成同样的功能，你可以把这些目录加到/etc/ld.so.conf中，然后调用ldconfig。当然，这是系统范围内全局有效 的，而环境变量只对当前shell有效。按照惯例，除非你用上述方式指明，loader是不会在当前目录下去找共享库的，正如shell不会在当前目前找 可执行文件一样。

参考文档：
1.http://james23dier.iteye.com/blog/763274
2.http://www.h2z.org/read.php?13

除非注明，文章为IT热血青年原创，欢迎转载！转载请注明本文地址，谢谢。
本文地址：http://blog.itblood.com/pycurl-7-15-5%ef%bc%8cpost-data-error.html