Как заставить PHP использовать libiconv версию iconv вместо установленной версии CentOS, установленной на CentOS?

Я только что изменил свой php-5.3.3 с иконки glibc на GNU libiconv с помощью ручной перекомпиляции расширения php iconv. Следуй этим шагам:

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 

* Этот трюк заставляет configure выбирать GNU libiconv вместо значка glibc. По умолчанию он проверяет значок glibc на первом шаге и вообще не проверяет GNU libiconv.

Ваш модуль ( libphp5.so ) связан с двумя разделяемыми библиотеками, которые предоставляют один и тот же символ (в этом случае символ iconv а библиотеки – libiconv.so.2 и, возможно, libc.so.6 ).

Когда это произойдет, используется первый загруженный символ: возможно, libc.so.6 загружается до libiconv.so.2 и, таким образом, он предоставляет вам 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 потому что первый загружается приложением (apache?), Прежде чем он загрузит модуль PHP.

Вы уверены, что LD_LIBRARY_PATH правильно настроен для процесса httpd (веб-сервер)? Если нет, попробуйте установить его так:

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

… в скрипте, который запускает процесс (т.е. apachectl ).

ldd вами вывод ldd выглядит корректно, но вы вызывали ldd из среды пользователя, а httpd – разные.

Это также может помочь установить PATH на «/ usr / local / bin: $ {PATH}», на всякий случай.

Я понимаю, что этот вопрос уже ответил и почти мертв, но в последнее время я попытался найти способ скомпилировать PHP с libiconv, потому что в PHP я не мог преобразовать «∙» из UTF8 в CP1251 даже с iconv // IGNORE. Но я нашел другое решение, которое работало для меня без перекомпиляции (просто используйте // TRANSLIT):

iconv («UTF8», «CP1251 // TRANSLIT // IGNORE», $ text)

// TRANSLIT транслитерирует ТОЛЬКО неизвестных персонажей (не все, как некоторые могут догадываться), поэтому он преобразует русский 'ё', но транслитерирует неизвестный '∙' в 0x95 (который выглядит так же в целевой кодировке).

Я не знаю о CentOS, но в дистрибутивах на основе debian, таких как Ubuntu, вы можете выбрать версию программы, которую вы хотите определить символическими ссылками в / etc / alternatives.

Итак, если вы измените ссылку symbolink / etc / alternatives / iconv, чтобы указать на / usr / local / bin / iconv, этот момент вперед должен использовать правильную версию.

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