Pendant longtemps, l'ajout de packages aux systèmes Linux dérivés de RedHat a été appelé "RPM Hell", pour une bonne raison. Particulièrement avant que l'utilitaire yum n'arrive pour aider, faire en sorte que RPM fasse ce qu'il faut a souvent été une tâche fastidieuse. Cela m'a encore été rappelé aujourd'hui, alors que j'essayais de compiler une extension PostgreSQL sur deux systèmes CentOS presque identiques.
PostgreSQL fournit une API nommée PGXS qui vous permet de créer des extensions de serveur qui exploitent à la fois la bibliothèque de code du serveur et communiquent avec lui. Nous utilisons PGXS pour installer notre utilitaire repmgr, et avoir cette API bien définie permet au programme d'être développé en externe à partir du cœur du serveur principal. De nombreux modules populaires de PostgreSQL s'appuient sur PGXS pour se construire. En fait, la contrib les modules fournis avec PostgreSQL lui-même sont souvent construits de cette façon. Récupérer une contrib similaire module et le pirater à partir de là est un chemin bien tracé vers la construction d'une nouvelle extension PostgreSQL.
PGXS s'appuie sur pg_config utilitaire étant dans votre PATH. pg_config est livré avec le paquet postgresql-devel, qui s'appelle aujourd'hui postgresql90-devel . Malheureusement, ce n'est pas dans le chemin pour personne par défaut. Donc, la première étape dont vous avez besoin pour construire en utilisant PGXS est d'y arriver. Quelque chose comme ça fonctionnera pour la plupart des systèmes UNIX :
Voici à quoi ressemble la construction de repmgr sur le système de travail :
Cela inclut –m64 -mtune=generic , qui sont les options de gcc pour dire build pour une plate-forme 64 bits, mais laissez le compilateur déterminer exactement sur lequel vous vous trouvez par rapport aux autres restrictions. De nos jours, le résultat est normalement optimisé pour x86_64 si vous avez un système 64 bits. La détection automatique était plus utile lorsque les choix étaient i386, i468, i586 et i686.
Sur le système gênant. Je pensais mettre PostgreSQL ici de la même manière, mais la construction n'a pas fonctionné du tout :
Quelle? Il s'agit d'essayer de créer du code 32 bits : "-m32 -march=i386 -mtune=generic". À cause de cela, lorsqu'il essaie de se lier à toutes les bibliothèques 64 bits sur le serveur comme libpq et libtermcap, il ne peut pas. Comment diable cela se passe-t-il ?
Vous pouvez voir d'où proviennent les informations qui entrent dans une commande de construction PGXS en utilisant pg_config . Voici comment vérifier la partie relative aux CFLAGS , la section où se trouvent les informations sur la taille des bits :
Maintenant je suis énervé. Cela signifie également construire pour 64 bits, mais il trouve toujours des informations 32 bits. D'où cela vient-il ?
Certains creusant dans l'interface PGXS essayant de retracer cela m'ont finalement laissé /usr/pgsql-9.0/lib/pgxs/src/Makefile.global et voici ce que l'indice a commencé à apparaître. Ça fichier répertorie les options du compilateur 32 bits ! D'où viennent-ils ?
À ce stade, j'ai commencé à regarder exactement quels RPM étaient installés sur chaque serveur,
parce que quelque chose devait être différent entre eux. Voici une commande pratique à connaître :
RHEL5 est capable d'exécuter des applications 32 et 64 bits côte à côte, il suffit de faire attention à les compiler. Il est donc normal que les packages de compatibilité de base de données compat-postgresql-libs et postgresql90-libs inclure les deux architectures. Vous pouvez avoir à la fois 32 et 64 applications qui souhaitent communiquer avec le même serveur. C'est souvent ennuyeux, par exemple lorsque vous souhaitez supprimer un paquet et qu'il indique que votre demande correspond à plusieurs et ne fait rien - vous avez besoin de –allmatches pour résoudre ce problème.
Que voyons-nous sur le serveur qui ne se compile pas ? Pas tout à fait la même chose :
Que sont postgresql90-devel packages pour i386 et x86_64 faire là-bas? Cela n'a aucun sens !
Maintenant, après avoir testé pour essayer de donner un sens à cela, si vous avez l'un des packages -devel et essayez d'installer l'autre, il renvoie la bonne série d'erreurs pour les fichiers en conflit, comme ceci :
Le conditionneur sait parfaitement qu'ils écrasent le même Makefile.global. Comment ai-je fini avec les deux ? Après avoir tout effacé, j'ai trouvé exactement comment :
Ce n'est certainement pas OK! yum est parfaitement heureux de les combiner, et j'ai dû le faire sans m'en rendre compte auparavant. Il s'avère que si vous les laissez tous les deux s'installer comme ça, la copie qui vous reste peut ne pas rapporter les bonnes informations à PGXS - sans surprise, c'est confus. C'est comme ça que j'ai fini avec mon problème. J'utilisais le Makefile.global installé par la version i386, mais tout le reste sur le système était x86_64.
Alors, comment faire le ménage ? Étant donné le mélange de fichiers ici, vous ne pouvez pas vraiment croire que la simple suppression de l'indésirable suffit. Dans ce cas, il se peut que vous n'ayez plus aucune copie de tout ce qui est en conflit. Le seul choix sûr est de les détruire tous les deux, puis d'installer simplement celui x86_64, maintenant que nous savons exactement que la version est disponible à partir du test ci-dessus :
Maintenant que tout est réglé, mon extension PGXS se construit très bien, et le développement
sur repmgr reprend, après une journée de temps perdu à comprendre tout cela.
Leçons pour aujourd'hui :soyez prudent lors de l'installation de postgresql90-devel package via yum, et ne le laissez pas y mettre les deux architectures de ce fichier. N'utilisez que celui qui correspond à la plate-forme de votre postgresql90 principal emballer. Et si vous essayez de construire une extension PGXS sur un système RHEL/CentOS, et que vous voyez le message saut incompatible message de la bibliothèque, commencez par regarder le ou les packages de développement PostgreSQL que vous avez installés.
Nous obtiendrons probablement cette mauvaise combinaison particulière bloquée par les futures mises à jour des packages PostgreSQL 9.0. J'ai pensé que c'était intéressant à partager de toute façon, car il n'y a pas beaucoup de bons exemples de dépannage comme celui-ci sur RPM. Une fois, j'en ai écrit un intitulé Installation des RPM PostgreSQL 8.2 sur RHEL 5/CentOS 5 qui passe en revue un peu plus l'arrière-plan ici. Mais c'était une époque plus simple, avant que les plates-formes 64 bits ne soient populaires, et avant que vous puissiez installer plus d'une version de PostgreSQL via RPM en même temps. Connaître la bonne incantation RPM pour répertorier les packages installés avec leur architecture associée est aujourd'hui une astuce essentielle pour sortir de l'enfer RPM.
