10

我正在编写的代码可以在 Windows XP 和 Mac OS X 上完美运行。在 CentOS（以及 Fedora 和 Ubuntu）上进行测试时，它无法正常运行。搜索网络使我得出结论，这是导致问题的glibc版本。iconv所以现在我需要 Zend Lucene 的libiconv版本iconv才能正常工作。

我已经下载了 libiconv 并使用 , 对其进行了配置--prefix=/usr/local，make然后make install没有任何错误。似乎它已成功安装，因为执行时/usr/local/bin/iconv --version说版本是libiconv. 虽然简单iconv --version还是给出了glibc版本。

然后我使用--with-iconv=/usr/local. 但是，仍然phpinfo()显示iconv正在使用的是glibc版本。我也已经尝试过使用--with-iconv-dir或 using 进行的其他几个编译/usr/local/bin/php。

当然，我在重新编译 PHP 后重新启动了 Web 服务器。

我在我的以下行/etc/httpd/conf/httpd.conf：

LoadModule /usr/lib/httpd/modules/libphp5.so

并且libphp5.so实际上在/usr/lib/httpd/modules.

phpinfo()显示 PHP 5.3.3。我还 yum 删除了预装的 PHP 5.1.* 以确保。但是 iconv 仍然使用 glibc 版本。

ldd /usr/lib/httpd/modules/libphp5.so给

linux-gate.so.1 =>  (0x003b1000)
/usr/local/lib/preloadable_libiconv.so (0x00110000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x001ed000)
librt.so.1 => /lib/librt.so.1 (0x0021f000)
libmysqlclient.so.15 => /usr/lib/mysql/libmysqlclient.so.15 (0x003b2000)
libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0x0026e000)
liblber-2.3.so.0 => /usr/lib/liblber-2.3.so.0 (0x00370000)
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00516000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x002a8000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00228000)
libz.so.1 => /usr/lib/libz.so.1 (0x00328000)
libcurl.so.3 => /usr/lib/libcurl.so.3 (0x00f23000)
libm.so.6 => /lib/libm.so.6 (0x0033b000)
libdl.so.2 => /lib/libdl.so.2 (0x00364000)
libnsl.so.1 => /lib/libnsl.so.1 (0x0037e000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00f5f000)
libssl.so.6 => /lib/libssl.so.6 (0x0862c000)
libcrypto.so.6 => /lib/libcrypto.so.6 (0x04145000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x08e2d000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0611a000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x005f4000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x0024e000)
libidn.so.11 => /usr/lib/libidn.so.11 (0x071f5000)
libc.so.6 => /lib/libc.so.6 (0x08aa6000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00397000)
/lib/ld-linux.so.2 (0x00251000)
libresolv.so.2 => /lib/libresolv.so.2 (0x0748a000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x07ddf000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x062b7000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00369000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0913b000)
libsepol.so.1 => /lib/libsepol.so.1 (0x07eb4000)

这是来自： NullPointer.ph的交叉帖子

4

5 回答 5

10

您的模块 ( libphp5.so) 链接到两个提供相同符号的共享库（在这种情况下，符号是iconv，库是libiconv.so.2并且可能是libc.so.6）。

发生这种情况时，将使用第一个加载的符号：可能libc.so.6之前已加载libiconv.so.2，因此它是为您提供符号的iconv符号。

您可以强制动态加载器先加载库；您可以通过将LD_PRELOAD环境变量设置为要预加载的库来做到这一点。

我不是 Apache 的专家，所以我不完全确定它是如何工作的，它如何启动它的进程以及它使用什么进程，但我认为LD_PRELOAD在运行 apache 之前进行设置应该可以解决问题：

LD_PRELOAD=/usr/local/lib/libiconv.so.2

一个实际展示的小例子LD_PRELOAD：

将编译myfopen.c为共享库（myfopen.so）：它将提供一个fopen符号（已在 中定义libc）：

$ cat myfopen.c
int fopen(const char *path, const char *mode){ return -1; }
$ gcc -o libmyfopen.so myfopen.c -shared

编译printfopen.c为可执行文件 ( printfopen)，它只打印fopen;的结果 将它链接到两者libc和libmyfopen（LD_LIBRARY_PATH需要让链接器在 中查找库.）：

$ cat printfopen.c
#include <stdio.h>
int main( ) {
    printf( "%d\n", fopen("","") );
    return 0;
}
$ gcc -o printfopen printfopen.c -L. -lmyfopen
$ LD_LIBRARY_PATH=. ldd printfopen
    linux-gate.so.1 =>  (0xb779d000)
    libmyfopen.so => ./libmyfopen.so (0xb779a000)
    libc.so.6 => /lib/libc.so.6 (0xb762f000)
    /lib/ld-linux.so.2 (0xb779e000)

现在我正在运行它，以测试是否LD_PRELOAD有效：

$ LD_LIBRARY_PATH=. ./printfopen
-1
$ LD_PRELOAD=/lib/libc.so.6 LD_LIBRARY_PATH=. ./printfopen
0
$ LD_PRELOAD=libmyfopen.so LD_LIBRARY_PATH=. ./printfopen
-1

默认情况下它会libmyfopen先加载libc，然后我尝试强制加载libc，然后再加载libmyfopen。

我猜你的情况libc是之前加载的，libiconv因为前者是在加载 PHP 模块之前由应用程序（apache？）加载的。

于 2011-01-30T15:13:04.907 回答
10

我刚刚通过手动重新编译 php iconv 扩展将我的 php-5.3.3 从 glibc 的 iconv 更改为 GNU libiconv。跟着这些步骤：

  1. 下载php-5.3.3源代码包
  2. 解压并进入php-5.3.3/ext/iconv子目录
  3. 执行phpize命令（如果你没有这样的命令，那么安装php-devel包）

  4. (*) 编辑配置文件 ( vim configure)：iconv_impl_name=""在 4664 行添加（您的系统配置上的确切行号可能不同）：

    ...
iconv_impl_name=""
    if test -z "$iconv_impl_name"; then
      { $as_echo "$as_me:${as_lineno-$LINENO}: checking if using GNU libiconv" >&5<
...

  5. ./configure --with-iconv=/usr/local|grep iconv：

    checking if using GNU libiconv... yes

  6. make

  7. sudo make install

现在我运行php -i|grep "iconv impl"并得到：

iconv implementation => libiconv

* 这个技巧强制配置选择 GNU libiconv 而不是 glibc 的 iconv。默认情况下，它在第一步检查 glibc 的 iconv，根本不检查 GNU libiconv。

于 2011-01-31T12:50:46.243 回答
0

您确定LD_LIBRARY_PATH为 httpd（Web 服务器）进程正确设置了吗？如果没有，请尝试将其设置为：

export LD_LIBRARY_PATH="/usr/local/lib:${LD_LIBRARY_PATH}"

...在启动进程的脚本中（即apachectl）。

您显示的ldd输出看起来是正确的，但是您ldd是从用户环境调用的，而 httpd 的输出可能会有所不同。

以防万一，将 PATH 设置为“/usr/local/bin:${PATH}”也可能会有所帮助。

于 2011-01-29T01:49:00.930 回答
0

我知道，这个问题已经得到解答并且几乎已经死了，但是最近我试图找到一种使用 libiconv 编译 PHP 的方法，因为在 PHP 中，即使使用 iconv //IGNORE，我也无法将“∙”从 UTF8 转换为 CP1251。但我找到了另一个无需重新编译即可为我工作的解决方案（只需使用//TRANSLIT）：

iconv("UTF8", "CP1251//TRANSLIT//IGNORE", $text)

//TRANSLIT 将只音译未知字符（不是全部，有些人可能会猜到），所以它转换俄语 'ё'，但将未知的 '∙' 音译为 0x95（在目标字符集中看起来相同）。

于 2015-03-26T01:51:46.933 回答
-1

我不了解 CentOS，但在基于 debian 的发行版中，例如 Ubuntu，您可以选择要启动的程序版本，在 /etc/alternatives 定义符号链接。

因此，如果您更改符号链接链接 /etc/alternatives/iconv 以指向 /usr/local/bin/iconv，那么它应该使用正确的版本。

http://www.debian-administration.org/articles/91

于 2011-01-25T16:44:45.187 回答