Przez długi czas dodawanie pakietów do systemów Linux opartych na RedHat było nazywane „RPM Hell”, nie bez powodu. Szczególnie zanim narzędzie yum zaczęło pomagać, nakłonienie RPM do właściwego działania często było kłopotliwym zadaniem. Przypomniało mi się o tym dzisiaj, gdy próbowałem skompilować rozszerzenie PostgreSQL na dwóch prawie identycznych systemach CentOS.
PostgreSQL udostępnia interfejs API o nazwie PGXS, który umożliwia tworzenie rozszerzeń serwera, które zarówno wykorzystują bibliotekę kodu serwera, jak i komunikują się z nim. Używamy PGXS do zainstalowania naszego narzędzia repmgr, a posiadanie tego dobrze zdefiniowanego API pozwala programowi być rozwijanym zewnętrznie z głównego rdzenia serwera. Wiele popularnych dodatków do PostgreSQL polega na PGXS do samodzielnego budowania. W rzeczywistości wkład moduły dostarczane z samym PostgreSQL są często budowane w ten sposób. Pobieranie podobnego wkładu i hackowanie go stamtąd jest dobrą ścieżką do zbudowania nowego rozszerzenia PostgreSQL.
PGXS opiera się na pg_config narzędzie znajdujące się w twojej PATH. pg_config zawiera pakiet postgresql-devel, który obecnie nazywa się postgresql90-devel . Niestety, domyślnie nie znajduje się to na ścieżce dla nikogo. Więc pierwszym krokiem, który musisz zbudować za pomocą PGXS, jest zrobienie tego tam. Coś takiego będzie działać w większości systemów UNIX:
Oto jak budowanie repmgr wyglądało w działającym systemie:
Obejmuje to –m64 -mtune=generic , które są opcjami gcc, aby powiedzieć build dla platformy 64-bitowej, ale pozwól kompilatorowi dokładnie określić, na której jesteś w stosunku do innych ograniczeń. Obecnie wynik zwykle wychodzi zoptymalizowany pod kątem x86_64, jeśli masz system 64-bitowy. Automatyczne wykrywanie było bardziej przydatne, gdy do wyboru były i386, i468, i586 i i686.
Do kłopotliwego systemu. Myślałem, że umieściłbym PostgreSQL w identyczny sposób, ale kompilacja w ogóle nie działała:
Co? To próbuje zbudować 32-bitowy kod:„-m32 -march=i386 -mtune=generic”. Z tego powodu, gdy próbuje połączyć się ze wszystkimi 64-bitowymi bibliotekami na serwerze, takimi jak libpq i libtermcap, nie może. Jak u licha to się dzieje?
Możesz zobaczyć, skąd pochodzą informacje, które trafiają do polecenia budowania PGXS, używając pg_config . Oto jak sprawdzić część związaną z CFLAGS , sekcja, w której znajdują się informacje o rozmiarze bitowym:
Teraz jestem wkurzony. Oznacza to również kompilację dla 64 bitów, ale nadal znajduje 32-bitowe informacje. Skąd to się bierze?
Niektóre grzebanie w interfejsie PGXS, próbujące prześledzić to wstecz, w końcu pozwoliło mi na /usr/pgsql-9.0/lib/pgxs/src/Makefile.global i oto, jak zaczęła się pojawiać wskazówka. To Lista plików 32-bitowych opcji kompilatora! Skąd pochodzą?
W tym momencie zacząłem dokładnie przyglądać się, jakie pakiety RPM zostały zainstalowane na każdym serwerze,
ponieważ coś między nimi musiało być inne. Oto przydatne polecenie:
RHEL5 jest w stanie uruchamiać aplikacje 32- i 64-bitowe obok siebie, musisz tylko uważać, aby je skompilować. To normalne, że pakiety kompatybilności baz danych compat-postgresql-libs i postgresql90-libs uwzględnij obie architektury. Możesz mieć 32 i 64 aplikacje, które chcą komunikować się z tym samym serwerem. Jest to często denerwujące, na przykład, gdy chcesz usunąć pakiet i mówi, że twoje żądanie pasuje do więcej niż jednego i nic nie robi - potrzebujesz -allmatches by to naprawić.
Co widzimy na serwerze, który się nie kompiluje? Niezupełnie to samo:
Co to jest postgresql90-devel pakiety dla i386 i x86_64 robisz tam? To nie ma żadnego sensu!
Teraz, po przetestowaniu, aby spróbować zrozumieć to, jeśli masz pakiet -devel i spróbujesz zainstalować drugi, wykopie właściwą serię błędów dla plików, które są w konflikcie, na przykład:
Pakowacz doskonale wie, że nadpisuje ten sam Makefile.global. Jak skończyłem z obydwoma? Po wyczyszczeniu wszystkiego odkryłem dokładnie, jak:
To na pewno nie jest OK! mniam jest doskonale szczęśliwy, mogąc je połączyć, a ja musiałem to zrobić, nie zauważając wcześniej. Okazuje się, że jeśli pozwolisz im obu zainstalować się w ten sposób, kopia, którą pozostaniesz, może nie zgłosić właściwych informacji z powrotem do PGXS - nic dziwnego, że jest zdezorientowana. Tak skończyłem z moim problemem. Używałem Makefile.global zainstalowany przez wersję i386, ale wszystko inne w systemie to x86_64.
Jak więc posprzątać? Biorąc pod uwagę mieszankę plików tutaj, nie można naprawdę ufać, że wystarczy usunąć niechciany. Wtedy możesz nie mieć żadnych kopii wszystkiego, co zostało skonfliktowane. Jedynym bezpiecznym wyborem jest zniszczenie ich obu, a następnie po prostu zainstalowanie jednego x86_64, teraz, gdy wiemy, że dokładna wersja jest dostępna z powyższego testu:
Po rozwiązaniu tego, teraz moje rozszerzenie PGXS buduje się dobrze, a rozwój
na repmgr przebiega ponownie, po dniu straconym na rozgryzienie tego wszystkiego.
Lekcje na dzisiaj:zachowaj ostrożność podczas instalacji postgresql90-devel pakiet za pośrednictwem yum i nie pozwól, aby umieścił tam obie architektury tego pliku. Używaj tylko tego, który pasuje do platformy twojego głównego postgresql90 pakiet. A jeśli próbujesz zbudować rozszerzenie PGXS w systemie RHEL/CentOS i widzisz pomijanie niezgodne wiadomość o bibliotece, zacznij od obejrzenia pakietów rozwojowych PostgreSQL, które zainstalowałeś.
Prawdopodobnie ta konkretna zła kombinacja zostanie zablokowana przez przyszłe aktualizacje pakietów PostgreSQL 9.0. Pomyślałem, że i tak warto się podzielić, ponieważ nie ma wielu dobrych przykładów rozwiązywania takich problemów w RPM. Kiedyś napisałem jeden zatytułowany Instalacja pakietów RPM PostgreSQL 8.2 na RHEL 5/CentOS 5, który zawiera więcej informacji tutaj. Ale to były prostsze czasy, zanim popularne stały się platformy 64-bitowe i zanim można było zainstalować więcej niż jedną wersję PostgreSQL przez RPM w tym samym czasie. Znajomość właściwej inkantacji RPM, aby wyświetlić listę zainstalowanych pakietów wraz z powiązaną z nimi architekturą, jest obecnie kluczową sztuczką, aby wydostać się z piekła RPM.
