Дълго време добавянето на пакети към Linux системи, извлечени от RedHat, се нарича „RPM Hell“ с добра причина. Особено преди помощната програма yum да дойде да помогне, накарането на RPM да направи правилното нещо често е била проблемна задача. Напомних ми за това отново днес, докато се опитвах да компилирам разширение на PostgreSQL на две почти идентични CentOS системи.
PostgreSQL предоставя API на име PGXS, който ви позволява да създавате сървърни разширения, които едновременно използват кодовата библиотека на сървъра и комуникират с нея. Ние използваме PGXS, за да инсталираме нашата помощна програма repmgr, а наличието на този добре дефиниран API позволява на програмата да се разработва външно от основното ядро на сървъра. Много популярни части от добавките на PostgreSQL разчитат на PGXS, за да се изградят сами. Всъщност приносът модулите, които идват със самия PostgreSQL, често се изграждат по този начин. Вземане на подобен принос модул и хакването на него от там е добре изтъпкан път към изграждането на ново разширение PostgreSQL.
PGXS разчита на pg_config полезността е във вашия PATH. pg_config идва с пакета postgresql-devel, който днес всъщност се нарича postgresql90-devel . За съжаление не е в пътя за никого по подразбиране. Така че първата стъпка, която трябва да изградите с помощта на PGXS, е да го направите там. Нещо подобно ще работи за повечето UNIX системи:
Ето как изглеждаше изграждането на repmgr на работещата система:
Това включва –m64 -mtune=generic , които са опциите на gcc, за да се каже изграждане за 64-битова платформа, но нека компилаторът да разбере на коя точно се намирате спрямо другите ограничения. В днешно време резултатът обикновено излиза оптимизиран за x86_64, ако имате 64-битова система. Автоматичното откриване беше по-полезно, когато изборът беше i386, i468, i586 и i686.
Към проблемната система. Мислех, че ще сложа PostgreSQL тук по същия начин, но сборката изобщо не работи:
Какво? Това се опитва да изгради 32-битов код: „-m32 -march=i386 -mtune=generic“. Поради това, когато се опита да се свърже с всички 64-битови библиотеки на сървъра като libpq и libtermcap, не може. Как за Бога става това?
Можете да видите откъде идва информацията, която влиза в командата за изграждане на PGXS, като използвате pg_config . Ето как да проверите частта, свързана с CFLAGS , секцията, където се намира информацията за битовите размери на:
сега съм ядосана. Това казва и изграждане за 64 бита, но все още намира 32-битова информация. Откъде идва това?
Някои ровене в интерфейса на PGXS, опитвайки се да проследят това назад, в крайна сметка ми позволиха да /usr/pgsql-9.0/lib/pgxs/src/Makefile.global и ето какво започна да се показва уликата. Това файл изброени опции за 32-битов компилатор! Откъде са дошли?
В този момент започнах да разглеждам точно какви RPM са инсталирани на всеки сървър,
защото нещо трябваше да е различно между тях. Ето една удобна команда, която трябва да знаете:
RHEL5 е в състояние да изпълнява 32 и 64 битови приложения едно до друго, просто трябва да внимавате да ги компилирате. Така че е нормално пакетите за съвместимост на базата данни compat-postgresql-libs и postgresql90-libs включват и двете архитектури. Може да имате както 32, така и 64 приложения, които искат да говорят със същия сървър. Това често е досадно, например когато искате да изтриете пакет и той казва, че заявката ви съвпада с повече от едно и не прави нищо – имате нужда от – всички съвпадения за да поправите това.
Какво виждаме на сървъра, което не се компилира? Не е съвсем същото нещо:
Какво представляват postgresql90-devel пакети както за i386, така и за x86_64 правят ли там? Това изобщо няма смисъл!
Сега, след тестване, за да опитате да разберете това, ако имате един от двата пакета -devel и се опитате да инсталирате другия, той връща правилната серия от грешки за файлове, които са в конфликт, като това:
Пакетиращият знае отлично, че те презаписват същия Makefile.global. Как приключих и с двете? След като изтрих всичко, открих как точно:
Със сигурност не е наред! yum е напълно щастлив да ги комбинира и сигурно съм го направил, без да съм забелязал преди. Оказва се, че ако оставите и двамата да се инсталират по този начин, копието, което ви е останало, може да не докладва правилната информация обратно на PGXS – не е изненадващо, че е объркано. Така приключих с моя проблем. Използвах Makefile.global инсталиран от версията i386, но всичко останало в системата беше x86_64.
И така, как да почистите? Като се има предвид комбинацията от файлове тук, не можете наистина да се доверите, че просто изтриването на нежелания е достатъчно. Тогава може да не са ви останали копия от всичко, което е събрано. Единственият безопасен избор е да ги изстреляте и двете, след което просто инсталирайте x86_64, сега, когато знаем, че точната версия е налична от теста по-горе:
След като това е подредено, сега моето разширение PGXS се надгражда добре и разработката
на repmgr продължава отново, след ден загубено време, за да разбера всичко това.
Уроци за днес: внимавайте, когато инсталирате postgresql90-devel пакет чрез yum и не позволявайте да поставя и двете архитектури на този файл там. Използвайте само този, който съответства на платформата на вашия основен postgresql90 пакет. И ако се опитвате да изградите разширение PGXS на система RHEL/CentOS и виждате пропускане несъвместимо съобщение на библиотеката, започнете с преглед на пакета(ите) за разработка на PostgreSQL, който сте инсталирали.
Вероятно тази конкретна лоша комбинация ще бъде блокирана от бъдещи актуализации на пакетите PostgreSQL 9.0. Все пак реших, че е интересно да споделя, защото няма много добри примери за извършване на подобно отстраняване на неизправности в RPM. Веднъж написах един, озаглавен Инсталиране на PostgreSQL 8.2 RPM на RHEL 5/CentOS 5, който преминава през още малко от фона тук. Но това бяха по-прости дни, преди 64-битовите платформи да станат популярни и преди да можете да инсталирате повече от една версия на PostgreSQL чрез RPM едновременно. Познаването на правилния RPM заклинание за изброяване на пакети, инсталирани с тяхната свързана архитектура, е жизненоважен трик в днешно време, за да се движите от ада на RPM.
