Per molto tempo, l'aggiunta di pacchetti ai sistemi Linux derivati da RedHat è stata chiamata "RPM Hell", per una buona ragione. Soprattutto prima che l'utilità yum venisse in aiuto, far sì che RPM facesse la cosa giusta è stato spesso un compito problematico. Me lo sono ricordato di nuovo oggi, mentre cercavo di compilare un'estensione PostgreSQL su due sistemi CentOS quasi identici.
PostgreSQL fornisce un'API denominata PGXS che consente di creare estensioni del server che sfruttano la libreria di codice del server e comunicano con esso. Usiamo PGXS per installare la nostra utilità repmgr e, avendo quell'API ben definita, il programma può essere sviluppato esternamente dal core del server principale. Molti componenti aggiuntivi popolari di PostgreSQL si basano su PGXS per costruirsi da soli. Infatti, il contributo i moduli forniti con PostgreSQL stesso sono spesso costruiti in questo modo. Afferrare un simile contributo modulo e l'hacking su di esso da lì è un percorso ben tracciato verso la costruzione di una nuova estensione PostgreSQL.
PGXS si basa su pg_config l'utilità è nel tuo PERCORSO. pg_config viene fornito con il pacchetto postgresql-devel, che al giorno d'oggi è chiamato postgresql90-devel . Sfortunatamente non è nel percorso per nessuno per impostazione predefinita. Quindi il primo passo che devi costruire usando PGXS è farlo lì. Qualcosa del genere funzionerà per la maggior parte dei sistemi UNIX:
Ecco come la creazione di repmgr è apparsa sul sistema funzionante:
Ciò include –m64 -mtune=generic , che sono le opzioni gcc per dire build per una piattaforma a 64 bit, ma lascia che il compilatore determini esattamente quale ti trovi rispetto alle altre restrizioni. Al giorno d'oggi il risultato normalmente risulta ottimizzato per x86_64 se si dispone di un sistema a 64 bit. Il rilevamento automatico era più utile quando le scelte erano i386, i468, i586 e i686.
Sul sistema problematico. Ho pensato di inserire PostgreSQL qui allo stesso modo, ma la build non ha funzionato affatto:
Che cosa? Questo sta cercando di creare codice a 32 bit: "-m32 -march=i386 -mtune=generic". Per questo motivo, quando tenta di collegarsi con tutte le librerie a 64 bit sul server come libpq e libtermcap, non può. Come diavolo sta succedendo?
Puoi vedere da dove provengono le informazioni che entrano in un comando di build PGXS usando pg_config . Ecco come controllare la parte relativa ai CFLAGS , la sezione in cui si trovano le informazioni sulla dimensione del bit in:
Ora sono incazzato. Questo significa costruire anche per 64 bit, ma sta ancora trovando informazioni a 32 bit. Da dove viene?
Alcuni scavando nell'interfaccia PGXS cercando di risalire a questo alla fine mi hanno permesso di /usr/pgsql-9.0/lib/pgxs/src/Makefile.global ed ecco cosa ha iniziato a rivelarsi l'indizio. Quello opzioni del compilatore a 32 bit elencate nel file! Da dove vengono?
A questo punto ho iniziato a guardare esattamente quali RPM erano installati su ciascun server,
perché qualcosa doveva essere diverso tra loro. Ecco un comando utile da sapere:
RHEL5 è in grado di eseguire applicazioni a 32 e 64 bit affiancate, devi solo fare attenzione a compilarle. Quindi è normale che i pacchetti di compatibilità del database compat-postgresql-libs e postgresql90-libs includere entrambe le architetture. Potresti avere sia 32 che 64 app che vogliono parlare con lo stesso server. Questo è spesso fastidioso, ad esempio quando vuoi eliminare un pacchetto e dice che la tua richiesta corrisponde a più di uno e non fa nulla:hai bisogno di –allmatches per risolverlo.
Cosa vediamo sul server che non viene compilato? Non proprio la stessa cosa:
Cosa sono postgresql90-devel pacchetti sia per i386 che x86_64 ci fanno? Non ha alcun senso!
Ora, dopo aver testato per cercare di dare un senso a questo, se hai uno dei pacchetti -devel e provi a installare l'altro, restituisce la giusta serie di errori per i file in conflitto, come questo:
Il packager sa perfettamente che sovrascrivono lo stesso Makefile.global. Come ho fatto a finire con entrambi? Dopo aver spazzato via tutto ho trovato esattamente come:
Di certo non va bene! yum è perfettamente felice di combinarli, e devo averlo fatto senza accorgermene prima. Si scopre che se li lasci installare entrambi in questo modo, la copia che ti rimane potrebbe non riportare le informazioni corrette a PGXS, non sorprende che sia confusa. È così che ho finito con il mio problema. Stavo usando Makefile.global installato dalla versione i386, ma tutto il resto sul sistema era x86_64.
Allora come pulire? Dato il mix di file qui, non puoi davvero fidarti che sia sufficiente eliminare solo quello indesiderato. Quindi potresti non avere più copie di tutto ciò che è conflittuale. L'unica scelta sicura è eliminarli entrambi, quindi installare semplicemente quello x86_64, ora che sappiamo esattamente che la versione è disponibile dal test sopra:
Una volta risolto il problema, ora la mia estensione PGXS viene compilata correttamente e lo sviluppo
su repmgr procede di nuovo, dopo una giornata di tempo perso per capire tutto.
Lezioni di oggi: fai attenzione quando installi postgresql90-devel pacchetto tramite yum e non lasciare che metta entrambe le architetture di quel file lì. Usa solo quello che corrisponde alla piattaforma del tuo postgresql90 principale pacchetto. E se stai provando a creare un'estensione PGXS su un sistema RHEL/CentOS e vedi il salto incompatibile messaggio della libreria, inizia osservando i pacchetti di sviluppo PostgreSQL che hai installato.
Probabilmente otterremo questa particolare combinazione errata bloccata da futuri aggiornamenti ai pacchetti PostgreSQL 9.0. Ho pensato che fosse comunque interessante condividere, perché non ci sono molti buoni esempi di risoluzione dei problemi come questo su RPM. Una volta ne ho scritto uno intitolato Installazione degli RPM PostgreSQL 8.2 su RHEL 5/CentOS 5 che passa attraverso un po' più di sfondo qui. Ma quelli erano giorni più semplici, prima che le piattaforme a 64 bit diventassero popolari e prima che si potesse installare più di una versione di PostgreSQL tramite RPM contemporaneamente. Conoscere il giusto incantesimo RPM per elencare i pacchetti installati con la loro architettura associata è un trucco fondamentale al giorno d'oggi per uscire dall'inferno degli RPM.
