Perl/Postgresql: plperl.so неопределенный символ: Perl_sv_2bool_flags

Question

Это мой первый пост здесь, извините, если я не предоставляю всю необходимую информацию с первого раза!

Мой босс и я пытались установить plperl при нашей установке postgres на одном из наших серверов (Centos 6.5, Postgres 9.2.1, Perl 5.10.1), и мы продолжаем сталкиваться с той же проблемой, которая заключается в следующем:

ERROR:  could not load library "/opt/PostgreSQL/9.2/lib/postgresql/plperl.so": 
/opt/PostgreSQL/9.2/lib/postgresql/plperl.so: undefined symbol: Perl_sv_2bool_flags

Эта ошибка возвращается, когда мы пытаемся установить язык (создаем язык plperl;) либо через SQL, либо с помощью графического интерфейса PgAdmin III.

Я проверил, что у нас есть lperl.so файл в /opt/PostgreSQL/9.2/lib/postgresql/ а также ищет libperl.so как подсказывает большинство постов, относящихся к этой проблеме. Я пытался разместить libperl.so во многих разных местах, так как у каждого человека и его собаки есть разные предположения относительно того, где это должно быть размещено.

Бег ldd /opt/PostgreSQL/9.2/lib/postgresql/plperl.so возвращает следующее:

ldd /opt/PostgreSQL/9.2/lib/postgresql/plperl.so
        linux-vdso.so.1 =>  (0x00007fff2d9b7000)
        libperl.so => /lib64/libperl.so (0x00007f8ab5c11000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8ab59f3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f8ab565f000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8ab5445000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f8ab522b000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f8ab5027000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f8ab4da3000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8ab4b6b000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f8ab4968000)
        /lib64/ld-linux-x86-64.so.2 (0x00000034aa800000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007f8ab46f1000)

Я не думаю, что версии Postgres и Perl являются проблемой, потому что у нас есть еще один сервер с Centos 6.5, Postgres 9.3 и Perl 5.10.1 с pl/perl, который работает отлично (я также пытался посмотреть, что там происходит, чтобы исправить это) это, но не могу решить это).

Из того, что я могу сказать, Postgres ожидает, что libperl.so будет в /lib64, однако, когда Perl был установлен, он был установлен где-то еще. На данный момент Postgres - это единственное, что будет использовать libperl.so

К сожалению, я не знаю, как все было установлено на этом сервере, так как мой начальник все настроил до того, как я присоединился к компании, и он только решил, что нам действительно нужно, чтобы он работал.

Глядя на оба наших сервера, я не вижу никаких различий в установках и конфигурациях, из-за которых один работает, а другой - нет.

Я почти сошел с ума с этим (это последняя проблема, которую нам нужно исправить с помощью установки Postgres), поэтому любые предложения будут оценены.

ура

Answer 1

Используете ли вы бинарные пакеты, установленные с менеджером пакетов, который должным образом контролирует зависимости? Собираете библиотеки сами? Хотя можно принудительно установить бинарные пакеты с помощью инструмента "admin" с графическим интерфейсом пользователя или поместить файлы в место, где PostgreSQL сможет их найти, вы не должны ожидать, что они будут работать должным образом, если они не скомпилированы / связаны на достаточно похожих платформах.

Похоже, вы используете версию Perl, которая была скомпилирована с флагами или параметрами, отличными от plperl.so файл, который вы устанавливаете. Посмотрите на вывод perl -V чтобы увидеть, как был скомпилирован ваш Perl, важно согласованное использование параметров потоков.

Какие /opt/PostgreSQL/9.2/lib/postgresql/plperl.so говорит вам, что один из его символов не определен. Это может быть связано с опциями компиляции или может означать, что вам нужна более новая версия Perl и libperl.so (5.10.1 довольно старый). Последние версии PotgreSQL и plperl обычно требуется более новая версия perl чем тот, который вы цитируете.

libperl.so должен быть установлен в согласованном месте для вашей платформы и других приложений, которые были скомпилированы / связаны для его использования - вам не нужно перемещать его. Действительно, если есть многочисленные копии libperl.so в вашей системе plperl может найти устаревшую версию libperl.so когда он загружается.

Для сравнения приведу выходные данные команд, которые вы запускали на одной из моих систем:

/usr/local/lib/postgresql/plperl.so:
       libperl.so => /usr/local/lib/perl5/5.16/mach/CORE/libperl.so (0x801214000)
       libthr.so.3 => /lib/libthr.so.3 (0x80158f000)
       libc.so.7 => /lib/libc.so.7 (0x80081b000)
       libm.so.5 => /lib/libm.so.5 (0x8017b2000)
       libcrypt.so.5 => /lib/libcrypt.so.5 (0x8019d3000)
       libutil.so.9 => /lib/libutil.so.9 (0x801bf2000)

Символ присутствует:

strings /usr/local/lib/perl5/5.16/mach/CORE/libperl.so | grep 2bool
 Perl_sv_2bool_flags
 Perl_sv_2bool

Скорее всего где-то в вашем стеке есть perl Модуль XS или .so файл, указывающий на неправильное место. Возможно, на системном уровне есть некоторая путаница с кэшированными библиотеками... Я считаю, ldconfig это инструмент, который вы используете для управления этим в Linux.