36240 2019-03-06 16:40:59 +0300 Сломан postgis 2019-03-21 18:31:14 +0300 1 1 4 Development Sisyphus postgis unstable all Linux CLOSED FIXED P3 major --- 1 blacester cas aen cas ldv mithraen nickel taf qa-sisyphus oldest_to_newest 179228 0 blacester 2019-03-06 16:40:59 +0300 Установлен postgresql10 с расширением postgis которое перестало работать: Похоже - произошло из-за того что собрано на devel пакете от postgresql11 Вывод при попытке обновить расширение: ОШИБКА: загрузить библиотеку "/usr/lib64/pgsql/postgis-2.5.so" не удалось: /usr/lib64/pgsql/postgis-2.5.so: undefined symbol: SearchSysCache3 [root@pgsql-srv ~]# rpm -qa |grep postg postgresql-common-1.0-alt8.noarch postgis-2.5.1-alt2.x86_64 postgresql10-10.6-alt1.x86_64 postgresql10-python-10.6-alt1.x86_64 postgresql10-tcl-10.6-alt1.x86_64 postgresql10-server-10.6-alt1.x86_64 postgresql10-postgis-2.5.1-alt2.x86_64 postgresql10-contrib-10.6-alt1.x86_64 postgresql10-perl-10.6-alt1.x86_64 [root@pgsql-srv ~]# apt-cache search postgresql |grep post|grep devel ocaml-postgresql-devel - Development files for ocaml-postgresql postgresql11-devel - PostgreSQL development header files postgresql11-devel-static - Development static library for postgresql-devel Так как расширение жестко завязано на версию postgresql то оно должно собираться на devel пакете версии для которой оно предназначено, и по хорошему для всех существующих в репозитории версий postgresql для которых оно собиралось ранее, иначе ломаются базы в которых оно используется. 179231 1 ldv 2019-03-06 16:55:31 +0300 В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее: verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: SearchSysCache3 Предлагаю долинковать плагины, после чего включить %set_verify_elf_method strict 179245 2 taf 2019-03-07 10:00:09 +0300 По-идее, postgis надо просто пересобрать под PG-11, поправив в спеке %define pg_ver 10 на %define pg_ver 11 По крайней мере у меня получилось собрать, поставить и запустить расширение postgresql11-postgis 2.5.1. 179247 3 blacester 2019-03-07 11:14:55 +0300 (В ответ на комментарий №2) > По-идее, postgis надо просто пересобрать под PG-11, поправив в спеке > > %define pg_ver 10 > > на > > %define pg_ver 11 > > По крайней мере у меня получилось собрать, поставить и запустить расширение > postgresql11-postgis 2.5.1. Тогда каким образом переехать с postgresql10 у которого текущее расширение сломано, на postgresql11? Бакап сделать невозможно, базы бинарно не совместимы. 179248 4 taf 2019-03-07 11:16:32 +0300 Откатить из архива последний рабочий postgis и далее по инструкции. 179250 5 blacester 2019-03-07 11:46:37 +0300 (В ответ на комментарий №4) > Откатить из архива последний рабочий postgis и далее по инструкции. Может все таки более корректным будет: Собирать для postgres{X} devel пакеты которые провайдят только {names}{X}-devel Для основной версии провайдить еще имя {names}-devel Собрать postgis{X} расширение под текущие актуальные версии (9.4-11) опираясь на их {names}{X}-devel пакеты. У утилит postgis вообще отпилить зависимость на postgres{X}-postgis так как это чисто клиентская часть, которая может быть установлена не там где установлена серверная. 179252 6 taf 2019-03-07 12:30:43 +0300 Этап с несколькими -devel уже был. Не прижился по причине сразу же полезших конфликтов с линковкой, потому что помимо вручную прописанных provides rpmbuild генерит массу автоматических. В результате можно вообще не получить сборочную среду из-за конфликтов, либо приложение будет получать не ту версию, какая ей нужна. 179262 7 blacester 2019-03-07 14:20:21 +0300 (В ответ на комментарий №6) > Этап с несколькими -devel уже был. Не прижился по причине сразу же полезших > конфликтов с линковкой, потому что помимо вручную прописанных provides rpmbuild > генерит массу автоматических. В результате можно вообще не получить сборочную > среду из-за конфликтов, либо приложение будет получать не ту версию, какая ей > нужна. А можно детальней кого мое предложение потенциально разломает? 179264 8 taf 2019-03-07 14:46:46 +0300 Удаление всех libpq кроме самой последней было следствием невозможности собрать части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек, подтягиваемых по автоматически созданным зависимостям set-version. Когда во время прохождения тестов сборка обламывалась на установке debug-пакетов - тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только вернуть, но еще и расширить за счет -devel. Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть возможность сборки в опцией --with devel. В случае с postgis надо дождаться когда выкатят сборку под PG11. А до этого момента вернуться на последнюю работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По появлению пересобранного postgis провести обновление Hard Upgrade в документации postgis. 179265 9 ldv 2019-03-07 14:55:53 +0300 (In reply to comment #1) > В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее: > verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: > SearchSysCache3 > > Предлагаю долинковать плагины, после чего включить > %set_verify_elf_method strict В качестве приятного побочного эффекта это изменение заблокирует возможность установить модуль postgis вместе с несовместимой версией libpq. 179267 10 blacester 2019-03-07 15:16:47 +0300 (В ответ на комментарий №9) > (In reply to comment #1) > > В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее: > > verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: > > SearchSysCache3 > > > > Предлагаю долинковать плагины, после чего включить > > %set_verify_elf_method strict > > В качестве приятного побочного эффекта это изменение заблокирует возможность > установить модуль postgis вместе с несовместимой версией libpq. Именно расширение, насколько я понимаю, не линкуется на libpq, только клиентские утилиты, которые не сильно важны и могут быть собраны отдельно с любой угодной версией клиентской либы. Схожая ругань "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения Пример из сборки postgresql9.6 verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: UtfToLocal verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: error_context_stack 179268 11 ldv 2019-03-07 15:19:32 +0300 (In reply to comment #10) > Схожая ругань > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения > Пример из сборки postgresql9.6 > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: > UtfToLocal > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: > error_context_stack А в каком файле определены эти символы и почему модули самого postgresql не линкуются с этим файлом? 179269 12 blacester 2019-03-07 15:32:40 +0300 (В ответ на комментарий №11) > (In reply to comment #10) > > Схожая ругань > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения > > Пример из сборки postgresql9.6 > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: > > UtfToLocal > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: > > error_context_stack > > А в каком файле определены эти символы и почему модули самого postgresql не > линкуются с этим файлом? Ну чисто предположение (пока нет возможности копнуть): динамическая загрузка расширений а символы внутри того кто грузит? 179270 13 taf 2019-03-07 15:42:03 +0300 (В ответ на комментарий №11) > (In reply to comment #10) > > Схожая ругань > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения > > Пример из сборки postgresql9.6 > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: > > UtfToLocal > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: > > error_context_stack > > А в каком файле определены эти символы и почему модули самого postgresql не > линкуются с этим файлом? В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих объектов занимается сам процесс postgresql 179272 14 blacester 2019-03-07 16:13:43 +0300 (В ответ на комментарий №8) > Удаление всех libpq кроме самой последней было следствием невозможности собрать > части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек, > подтягиваемых по автоматически созданным зависимостям set-version. Когда во > время прохождения тестов сборка обламывалась на установке debug-пакетов - > тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только > вернуть, но еще и расширить за счет -devel. > > Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть > возможность сборки в опцией --with devel. В случае с postgis надо дождаться > когда выкатят сборку под PG11. А до этого момента вернуться на последнюю > работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По > появлению пересобранного postgis провести обновление Hard Upgrade в > документации postgis. Собрал в хашере по приведенной мной выше идее (собрал 9.3 и 9.6 devel пакеты которые провайдят только версионированные devel), собрал postgis9.3 и postgis9.6 с указанием жестких зависимостей и отпиленными пакетами с клиентской частью, собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь что из-за postgres). Что вижу - собиралось с postgresql11-devel, так как только он провайдит postgresql-devel, в одном из пакетов bacula9 есть зачем-то жестко прописанная зависимость на postgresql10. 179273 15 ldv 2019-03-07 16:22:51 +0300 (In reply to comment #13) > (В ответ на комментарий №11) > > (In reply to comment #10) > > > Схожая ругань > > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: > > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения > > > Пример из сборки postgresql9.6 > > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: > > > UtfToLocal > > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: > > > error_context_stack > > > > А в каком файле определены эти символы и почему модули самого postgresql не > > линкуются с этим файлом? > > В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как > undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих > объектов занимается сам процесс postgresql А кто следит за правильным порядком загрузки плагинов, тоже posgresql? Зачем такой закат солнца вручную? Похожая схема используется в /usr/lib64/lftp/, но там в конеченом итоге справились с этой задачей нормально, в отличие от postgresql. 179275 16 blacester 2019-03-07 16:33:17 +0300 (В ответ на комментарий №14) > (В ответ на комментарий №8) > > Удаление всех libpq кроме самой последней было следствием невозможности собрать > > части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек, > > подтягиваемых по автоматически созданным зависимостям set-version. Когда во > > время прохождения тестов сборка обламывалась на установке debug-пакетов - > > тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только > > вернуть, но еще и расширить за счет -devel. > > > > Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть > > возможность сборки в опцией --with devel. В случае с postgis надо дождаться > > когда выкатят сборку под PG11. А до этого момента вернуться на последнюю > > работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По > > появлению пересобранного postgis провести обновление Hard Upgrade в > > документации postgis. > > Собрал в хашере по приведенной мной выше идее (собрал 9.3 и 9.6 devel пакеты > которые провайдят только версионированные devel), собрал postgis9.3 и > postgis9.6 с указанием жестких зависимостей и отпиленными пакетами с клиентской > частью, собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь > что из-за postgres). Что вижу - собиралось с postgresql11-devel, так как только > он провайдит postgresql-devel, в одном из пакетов bacula9 есть зачем-то жестко > прописанная зависимость на postgresql10. Ошибся при наборе - не 9.3 а 9.4 179278 17 nickel 2019-03-07 16:46:23 +0300 (В ответ на комментарий №14) > собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь > что из-за postgres) начиная с 9.0.6-alt4 должна собираться 179317 18 taf 2019-03-08 17:08:27 +0300 (In reply to comment #15) > (In reply to comment #13) > > (В ответ на комментарий №11) > > > (In reply to comment #10) > > > > Схожая ругань > > > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: > > > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения > > > > Пример из сборки postgresql9.6 > > > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: > > > > UtfToLocal > > > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: > > > > error_context_stack > > > > > > А в каком файле определены эти символы и почему модули самого postgresql не > > > линкуются с этим файлом? > > > > В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как > > undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих > > объектов занимается сам процесс postgresql > > А кто следит за правильным порядком загрузки плагинов, тоже posgresql? Да. > Зачем такой закат солнца вручную? Возможно, разработчики посчитали это удобным. > Похожая схема используется в /usr/lib64/lftp/, но там в конеченом итоге > справились с этой задачей нормально, в отличие от postgresql. Вообще-то postgres и так с этим справляется успешно. С идущими в комплекте расширениями проблем нет. 179320 19 blacester 2019-03-08 21:04:33 +0300 (В ответ на комментарий №13) > (В ответ на комментарий №11) > > (In reply to comment #10) > > > Схожая ругань > > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: > > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения > > > Пример из сборки postgresql9.6 > > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: > > > UtfToLocal > > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: > > > error_context_stack > > > > А в каком файле определены эти символы и почему модули самого postgresql не > > линкуются с этим файлом? > > В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как > undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих > объектов занимается сам процесс postgresql Все таки настою на своем варианте ответа на вопрос Дмитрия. Процесс postgresql динамически грузит нужные расширения. Большая часть символов помеченных как undefined находятся в самом postgres (я думаю что вообще все, однако я это не проверял и утверждать не буду). Насколько я вижу расширения не имеют связей между собой поэтому тут нет значения в каком порядке они грузятся (да и грузится будут только те которые подключены в базе). Все стандартные расширения билдятся вместе с postgres, и с ними проблем нет. Postgis же - отдельное расширение, для сборки которого нужна серверная часть devel. Исходя из этого и понимая что вероятность появления devel пакетов крайне низка, есть еще вариант как сделать все таки по человечески, а не в варианте я вам тут поломал, а вы теперь сами разбирайтесь: Собирать postgis вместе с postgres, как будто он часть стандартных расширений. 179723 20 repository-robot 2019-03-21 18:31:14 +0300 postgis-2.5.2-alt1 -> sisyphus: Tue Mar 19 2019 Andrey Cherepanov <cas@altlinux> 2.5.2-alt1 - New version. - Require postgresql11 (ALT #36240).