I lang tid er tilføjelse af pakker til RedHat-afledte Linux-systemer blevet kaldt "RPM Hell", med god grund. Især før yum-værktøjet kom til at hjælpe, har det ofte været en besværlig opgave at få RPM til at gøre det rigtige. Jeg blev mindet om dette igen i dag, mens jeg forsøgte at kompilere en PostgreSQL-udvidelse på to næsten identiske CentOS-systemer.
PostgreSQL leverer et API ved navn PGXS, der lader dig bygge serverudvidelser, der både udnytter serverens kodebibliotek og kommunikerer med det. Vi bruger PGXS til at installere vores repmgr-værktøj, og med den veldefinerede API lader vi programmet udvikles eksternt fra hovedserverens kerne. Mange populære stykker af PostgreSQL-tilføjelser er afhængige af PGXS til at bygge sig selv. Faktisk er bidraget moduler, der kommer med selve PostgreSQL, er ofte bygget på denne måde. Får et lignende bidrag modul og hacking på det derfra er en velbelagt vej mod at bygge en ny PostgreSQL-udvidelse.
PGXS er afhængig af pg_config nytte er i din VEJ. pg_config kommer med postgresql-devel-pakken, som i dag faktisk hedder postgresql90-devel . Desværre er det ikke i vejen for nogen som standard. Så det første skridt, du skal bruge til at bygge ved hjælp af PGXS, er at gøre det der. Noget som dette vil fungere for de fleste UNIX-systemer:
Sådan så bygningen repmgr ud på arbejdssystemet:
Dette inkluderer –m64 -mtune=generic , som er gcc-mulighederne for at sige bygge til en 64 bit platform, men lad compileren finde ud af præcis hvilken du er på i forhold til de andre restriktioner. I dag kommer resultatet normalt ud optimeret til x86_64, hvis du har et 64-bit system. Den automatiske registrering var mere nyttig, da valgene var i386, i468, i586 og i686.
Til det besværlige system. Jeg troede, jeg ville sætte PostgreSQL på her identisk, men bygningen virkede slet ikke:
Hvad? Dette forsøger at bygge 32 bit kode: "-m32 -march=i386 -mtune=generic". På grund af det, når den forsøger at linke til alle 64-bit bibliotekerne på serveren som libpq og libtermcap, kan den ikke. Hvordan i alverden sker det?
Du kan se, hvor informationen, der indgår i en PGXS build-kommando, kommer fra ved at bruge pg_config . Sådan tjekker du den del, der er relateret til CFLAGS , den sektion, hvor bitstørrelsesoplysningerne er placeret på:
Nu er jeg sur. Dette siger også build til 64 bit, men det finder stadig 32-bit information. Hvor kommer det fra?
Nogle grave i PGXS-grænsefladen og prøvede at spore dette tilbage lod mig til sidst gå til /usr/pgsql-9.0/lib/pgxs/src/Makefile.global og her er, hvad ledetråden begyndte at dukke op. Det fil opført 32-bit compiler muligheder! Hvor kom de fra?
På dette tidspunkt begyndte jeg at se på præcis, hvilke RPM'er der var installeret på hver server,
fordi noget skulle være anderledes mellem dem. Her er en praktisk kommando at vide:
RHEL5 er i stand til at køre 32 og 64 bit applikationer side om side, du skal bare være omhyggelig med at kompilere dem. Så det er normalt, at databasekompatibilitetspakkerne compat-postgresql-libs og postgresql90-libs omfatter begge arkitekturer. Du har måske både 32 og 64 apps, der vil tale med den samme server. Dette er ofte irriterende, for eksempel når du vil slette en pakke, og den fortæller, at din anmodning matcher mere end én og ikke gør noget – du har brug for –allmatches for at rette det.
Hvad ser vi på serveren, der ikke vil kompilere? Ikke helt det samme:
Hvad er postgresql90-devel pakker til både i386 og x86_64 gør der? Det giver overhovedet ingen mening!
Nu, efter at have testet for at prøve at forstå dette, hvis du har en af -devel-pakken og prøver at installere den anden, sparker den den rigtige række af fejl tilbage for filer, der er i konflikt, som denne:
Pakkeren ved udmærket godt, at de overskriver den samme Makefile.global. Hvordan endte jeg med begge dele? Efter at have slettet alt, fandt jeg præcis hvordan:
Det er bestemt ikke OK! yum er helt glad for at kombinere dem, og det må jeg have gjort uden at have bemærket det før. Det viser sig, at hvis du lader dem begge installere på denne måde, vil den kopi, du sidder tilbage med, muligvis ikke rapportere de rigtige oplysninger tilbage til PGXS – ikke overraskende er den forvirret. Sådan endte jeg med mit problem. Jeg brugte Makefile.global installeret af i386-versionen, men alt andet på systemet var x86_64.
Så hvordan rydder man op? I betragtning af blandingen af filer her, kan du ikke rigtig stole på, at bare at slette den uønskede er nok. Så har du måske ingen kopier tilbage af alt, der kom i konflikt. Det eneste sikre valg er at nuke dem begge, så skal du bare installere x86_64-en, nu hvor vi ved præcis, at versionen er tilgængelig fra testen ovenfor:
Med dette ordnet, bygger min PGXS-udvidelse nu helt fint, og udviklingen
på repmgr fortsætter igen, efter en dag med tabt tid til at finde ud af det hele.
Lektioner for i dag: Vær forsigtig, når du installerer postgresql90-devel pakke via yum, og lad det ikke placere begge arkitekturer af den fil der. Brug kun den, der matcher platformen på din primære postgresql90 pakke. Og hvis du forsøger at bygge en PGXS-udvidelse på et RHEL/CentOS-system, og du ser spring inkompatibel biblioteksmeddelelse, start med at se på de PostgreSQL-udviklingspakker, du har installeret.
Vi vil sandsynligvis få denne særlige dårlige kombination blokeret af fremtidige opdateringer til PostgreSQL 9.0-pakkerne. Jeg syntes det var interessant at dele alligevel, for der er ikke mange gode eksempler på at lave fejlfinding som denne på RPM. Jeg skrev engang en med titlen Installation af PostgreSQL 8.2 RPM'erne på RHEL 5/CentOS 5, der gennemgår noget mere af baggrunden her. Men det var enklere dage, før 64-bit platforme var populære, og før du kunne installere mere end én PostgreSQL-version via RPM på samme tid. At kende den rigtige RPM besværgelse til at liste pakker installeret med deres tilknyttede arkitektur er et vigtigt trick i dag for at navigere din vej ud af RPM helvede.