由于checksetup.pl脚本的存在，其实bugzilla的安装应该是非常顺利的，10多分钟，基本所有bugzilla需要的cpan扩展包都安装成功，最后出了一个数据库选择的提示。bugzilla目前可支持MySQL、PostgreSQL、Oracle三种数据库，需要要按自己的实际环境安装不同数据库的CPAN模块。所有的中文文档里，对这个步骤的形容都是跟其他模块一样，一条“/usr/bin/perl install-module.pl DBD::mysql”就可以搞定，可实际上……并非如此，起码我这么装没有成功，我个人估计，是因为他们安装Bugzilla的服务器跟mysql所运行的服务器在一台上面。我要安装Bugzilla的服务器，只编译安装了mysqlclient，并没有server存在。

在安装Bugzilla的时候，通过其提供的“install-module.pl”命令安装的CPAN模块，都是装在Bugzilla所在目录的lib目录下。而手动下载CPAN模块并安装的时候，在我的这台服务器上，默认是安装到“/usr/lib/perl5/5.8.5/”目录下的。这两个目录的结构相同。Bugzilla的checksetup.pl脚本在检测安装所需模块的时候，这连个路径都会扫描。

通过http://search.cpan.org搜索“DBD-mysql”，并下载“DBD::mysql”。解压缩后运行下面命令：

perl Makefile.PL –libs=”-L/usr/local/mysql-5.1.36/lib/mysql -lmysqlclient -L/usr/lib -lz” –cflags=-I/usr/local/mysql-5.1.36/include/mysql –mysql_config=/usr/local/mysql-5.1.36/bin/mysql_config –testhost=192.168.1.208 –testdb=test –testuser=bugs –testpassword=bugs

其中的“/usr/local/mysql-5.1.36”是安装mysqlclient的路径。在安装DBD::mysql的时候，会检测与mysql服务器的联通性，这里的testhost、testdb、testuser、testpassword就是做这个用的。用户bugs我事先在mysql服务器添加好了。

安装好“DBD::mysql”后，再次运行checksetup.pl脚本，出现了如下提示：

Reading ./localconfig…
Checking for       DBD-mysql (v2.9003) ok: found v4.005
Had to create DBD::mysql::dr::imp_data_size unexpectedly at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/DBI.pm line 1213, <DATA> line 228.
Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/DBI.pm line 1213, <DATA> line 228.
Had to create DBD::mysql::db::imp_data_size unexpectedly at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI.pm line 1243, <DATA> line 228.
Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI.pm line 1243, <DATA> line 228.
There was an error connecting to MySQL:

Undefined subroutine &DBD::mysql::db::_login called at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/mysql.pm line 142, <DATA> line 228.

在网上查了很长时间，按照网上的描述，修改localconfig文件n次，重新安装配置DBD::mysqln次，依然未果，而且就网上的说法，造成这个错误提示的原因有很多种。正在抓耳挠腮，郁闷之极的时候，突然看到一个邮件里表里有说mysql lib的问题。马上想到自己安装mysql的时候，是rpm卸载掉系统默认的4.0后，手动编译安装的mysql5.1。赶紧运行ldconfig，靠的，还真没有mysql的lib。修改/etc/ld.so.conf文件，把mysql的lib路径加进去，运行ldconfig。然后回到bugzilla目录重新运行checksetup.pl，一切哦耶了。

在中文论坛里，也看到一些人说mysql本来是4.x，bugzilla运行正常，后来升级成5.x之后，就出错了。这些错误应该也是跟我的问题一样，跟mysql的版本没什么关系。

关于ldconfig的问题，再次提醒下自己……http://kevin.9511.net/archives/177.html

也不知道是机器慢，还是的确如此，编译gcc花了快一个小时。。。很是吐血。

结果编译安装完成后，去编译其他东西，结果发现了找不到编译器的提示。。。

东查西找，左蒙右猜，终于把问题搞定了，问题就出在这个 LD_LIBRARY_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中，或则在/etc/ld.so.conf.d里创建一个文件，把目录加到这个文件里。当然，这是系统范围内全局有效的，而环境变量只对当前shell有效。按照惯例，除非你用上述方式指明，loader是不会在当前目录下去找共享库的，正如shell不会在当前目前找可执行文件一样。