problème curl = libintl.a(libintl.so.8) Fermé

Question

Bonjour, 

Je suis sur AIX
xxxxxxxxx@root /opt/freeware/lib#> uname -a
AIX xxxxxxxxx 3 5 00C8A6204C00

Cette machine a été upgradée récemment par nos services Unix et depuis cette date, curl ne fonctionne plus, car il ne peux plus accéder à deux librairies :

xxxxxxxxx@root /opt/freeware/lib#> curl
Could not load program curl:
Could not load module /opt/freeware/lib/libidn.a(libidn.so.11).
        Dependent module /opt/freeware/lib/libintl.a(libintl.so.8) could not be loaded.
        Member libintl.so.8 is not found in archive
Could not load module curl.
        Dependent module /opt/freeware/lib/libidn.a(libidn.so.11) could not be loaded.
Could not load module .

Donc je confirme que les deux fichiers suivants sont bien présents :

libidn.a
libintl.a

Et les droits unix ne sont pas un problème (777 pour être tranquille).

Mais ces fichiers doivent contenir les librairies libidn.so.11 et libintl.so.8, or ce n'est pas le cas semble-t-il.

Cela est dû à quoi selon vous ? Un outdating d'un package (donc à mettre à jour).

Peut-on aller chercher une version récente de ces fichiers libidn.a et libintl.a ?

Merci par avance pour votre éventuel retour d'expérience.

Configuration: Windows XP / Firefox 3.6.9

mamiemando · Answer

Si c'est comme sous Linux je pense qu'il y a une confusion entre librairie statique (.a) et librairie dynamique (.so comme shared object).

Quand tu compiles un logiciel avec un .a, le contenu du .a est "injecté" dans l'exécutable le rendant indépendant de cette fameuse librairie. L'exécutable s'en trouve donc plus gros puisqu'il contient une partie du .a. Au contraire, un .so est lié à l'exécutable et c'est tout. Sans ses .so, l'exécutable ne peut se lancer (erreur à l'exécution).

L'étape consistant à coupler un programme et des librairie se fait à la dernière phase de compilation (au linkage). On peut raisonnablement espérer que les compilateurs utilisés pour générer curl et compiler les librairies en question soient les mêmes (où aient produit des binaires compatibles).

Dans ton cas c'est vraiment bizarre, car on utilise pour une librairie donnée soit son ".a", soit son ".so" selon qu'on veut un programme standalone ou un exécutable léger.

Je ne sais pas trop d'où vient le problème, mais dans le doute je ferais ceci :
1) tout mettre à jour
2) réinstaller les paquets liés à curl (et les éventuelles dépendances) si AIX fournit comme linux un gestionnaire de paquets. Sous debian on utiliserait typiquement apt-file pour trouver les paquets fournissant ces répertoires et aptitude pour réinstaller curl.
3) appeler ldconfig (si ça existe sous AIX), implicitement appelé par la plupart des gestionnaires de paquets modernes et sensé corriger les liens dynamiques vers des librairies.

Peut-être que (3) suffit dans ton cas.

J'espère que ça t'aidera...

romegonic · Answer

Hélas,

xxxxxxxxx@root /root#> uname -a
AIX quawas1f1 3 5 00C8A6204C00
xxxxxxxxx@root /root#> ldconfig
ksh: ldconfig:  not found
xxxxxxxxx@root /root#>

Mais pas grave les admins Unix sont censés s'en occuper, je reviendrais quand même ici pour vous apporter un feedback sur ce qui a été fait.

Je ne peux pas mettre à jour les librairies à mon niveau, je suis admin applicatif, pas système.

Merci en tous cas pour ta réponse, mamiemando

mamiemando · Answer

Ok, désolée de ne pas avoir trop pu te dépanner sur ce coup, j'ai l'impression que AIX et linux diffèrent pas mal à ce niveau. J'attends ton feedback pour y voir plus clair ;-)

Problème curl => libintl.a(libintl.so.8)

3 réponses

Discussions similaires