Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Problème de compilation : où trouver les librairies X11 ?

benj63

Bonjour,

Je cherche à compiler un programme sous Fedora 5 64 bits, qui nécessite notamment les librairies X11. Sous Mandriva, elles sont installées dans le répertoire /usr/X11R5/lib64, mais sous Fedora 5, elles n'y sont pas par défaut !

Existe-t'il une méthode pour les installer ? Puis-je les trouver autre part sur mon système ?

J'ai également des soucis bizarres de compilation pour une autre application. Voici les messages d'erreur que j'obtiens lors de la compilation avec le compilateur PGF (je parviens à compiler d'autres applications) :

pgf90 -o eff-1.1 eff.o -Mnomain -Wl,-static eff-1.1.a -ldl -lpthread
/usr/lib64/libc.a(iofwrite.o): dans la fonction Â« fwrite Â»:
(.text+0x15f): rÃ©fÃ©rence indÃ©finie vers Â« _Unwind_Resume Â»
/usr/lib64/libc.a(iofwrite.o):(.eh_frame+0x14b): rÃ©fÃ©rence indÃ©finie vers Â« c_personality_v0 Â»
/usr/lib64/libc.a(ioputs.o): dans la fonction Â« puts Â»:
(.text+0x186): rÃ©fÃ©rence indÃ©finie vers Â« _Unwind_Resume Â»
/usr/lib64/libc.a(ioputs.o):(.eh_frame+0x14b): rÃ©fÃ©rence indÃ©finie vers Â« __personality_v0 Â»
/usr/lib64/libc.a(syslog.o): dans la fonction Â« openlog Â»:
(.text+0x3d7): rÃ©fÃ©rence indÃ©finie vers Â« _Unwind_Resume Â»
/usr/lib64/libc.a(syslog.o): dans la fonction Â« __vsyslog_chk Â»:
(.text+0x939): rÃ©fÃ©rence indÃ©finie vers Â« _Unwind_Resume Â»

Merci pour vos idées !

VINDICATORs

déjà chez nous c'est /usr/X11R6/ après pourquoi ne pas installer les devels de X11? après pourquoi ne pas faire une tite recherche de fichier?

benj63

Pour le souci lié à "Unwind_resume...", c'est corrigé avec une option de compilation.
Pour x11-static-devel, je ne vois pas pourquoi il manque les fichiers libx11.a et le répertoire /usr/X11R6/lib64 n'existe pas... Que faire ? Je n'ai pas trouvé de rpm sur le web pour résoudre cela...

Merci !

remi

Le répertoire X11R6 a disparu avec la nouvelle version de xorg

Les bibliothèques sont directement dans /usr/lib (ou /usr/lib64)

A+

benj63

Merci, pourtant quand j'essaie de compiler avec -lX11 j'obtiens cela :

pgf90 -o (...) -L/usr/lib64 -lX11 (...)
/usr/bin/ld: ne peut trouver -lX11

Si j'enlève -lX11 cela semble compiler, mais j'imagine que la librairie X11 n'est pas incluse à mon fichier de sortie... (qui est utilisé lors des compilations suivantes du makefile)...

benj63

Je pense d'ailleurs qu'il cherche les librairies X11 statiques (libX11.a par exemple), qui ne sont pas présentes par défaut dans /usr/lib64 (contrairement à libX11.so)

VINDICATORs

mince alors? pourquoi j'ai toujours X11R6 moi?

Anvil

benj63 a écrit :
Merci, pourtant quand j'essaie de compiler avec -lX11 j'obtiens cela :
pgf90 -o (...) -L/usr/lib64 -lX11 (...)
/usr/bin/ld: ne peut trouver -lX11
Si j'enlève -lX11 cela semble compiler, mais j'imagine que la librairie X11 n'est pas incluse à mon fichier de sortie... (qui est utilisé lors des compilations suivantes du makefile)...

Si ca compile sans c'est que tu n'en as pas besoin.
Si tu as vraiment besoin de la libX11, installe le package de developpement de la libX11.

benj63

En fait, ça ne compile pas, ça plante plus loin, donc j'ai vraiment besoin de la librairie statique libX11.a 🙁

J'ai déjà installé la librairie de développement X11 (libX11-devel-1.0.0-3) et celle-ci ne fournit que le fichier /usr/lib64/libX11.so, mais pas le .a qui m'est nécessaire !

http://rpm.pbone.net/index.php3/stat/6/idpl/2722247

A moins qu'on puisse spécifier qu'on veut utiliser les .h du répertoire "include" lors de la compilation ? (mais je ne sais pas faire 🙁 )

eddy33

tu peux faire une compilation dynamique (utilise les .so).
t'as pas forcement besoin des .a !
ca plante ou plus loin ? c'est une erreur de compilation ou d'edition de liens ?
++

benj63

J'ai essayé une compilation dynamique (si je ne me trompe pas dans la ligne ci-dessous !) et voici les messages d'erreurs...

pgf90 -o rams-5.02 rammain.o -Wl,-static rams-5.02.a ../librams-5.02/librams-5.02.a ../libutils-1.1/libutils-1.1.a -L/usr/local/ncarg-4.4.1/lib -lncarg -lncarg_gks -lncarg_c -L/usr/lib64/libX11.so -L/usr/local/hdf4.1r5/lib -lmfhdf -ldf -ljpeg -lz -L/usr/local/mpich-1.2.6/lib -lmpich -lc -lgcc_eh -ldl -lpthread

/usr/local/ncarg-4.4.1/lib/libncarg_c.a(ncarg_path.o): dans la f[onction Â« _NGResolvePath Â»:
ncarg_path.c:(.text+0x104): AVERTISSEMENT: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
ncarg_path.c:(.text+0x118): AVERTISSEMENT: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
ncarg_path.c:(.text+0x81): AVERTISSEMENT: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/local/mpich-1.2.6/lib/libmpich.a(p4_sock_util.o): dans la fonction Â« gethostbyname_p4 Â»:
p4_sock_util.c:(.text+0x18c1): AVERTISSEMENT: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/local/ncarg-4.4.1/lib/libncarg_gks.a(xattribute.o): dans la fonction Â« X11_SetClipIndicator Â»:
xattribute.c:(.text+0x243): rÃ©fÃ©rence indÃ©finie vers Â« XSetClipRectangles Â»
xattribute.c:(.text+0x269): rÃ©fÃ©rence indÃ©finie vers Â« XSetClipRectangles Â»
xattribute.c:(.text+0x28f): rÃ©fÃ©rence indÃ©finie vers Â« XSetClipRectangles Â»
xattribute.c:(.text+0x2b5): rÃ©fÃ©rence indÃ©finie vers Â« XSetClipRectangles Â»
xattribute.c:(.text+0x2db): rÃ©fÃ©rence indÃ©finie vers Â« XSetClipRectangles Â»
......

La commande de compilation d'origine était :

pgf90 -o rams-5.02 rammain.o -Wl,-static rams-5.02.a ../librams-5.02/librams-5.02.a ../libutils-1.1/libutils-1.1.a -L/usr/local/ncarg-4.4.1/lib -lncarg -lncarg_gks -lncarg_c -L/usr/lib64 -lX11 -L/usr/local/hdf4.1r5/lib -lmfhdf -ldf -ljpeg -lz -L/usr/local/mpich-1.2.6/lib -lmpich -lc -lgcc_eh -ldl -lpthread

drpixel

Dans les RPMs de façons générale, les fichies .a et .la ne sont pas gardés.
(Ceci dit ce n'est pas toujours vrai)

Sat

Il me semble que c'est une politique Fedora de privilégier les bibliothèques partagées et pas les statiques.
La raison est surtout sécuritaire, si une faille de sécurité est détecté dans la libmachin.a, tout les logiciels compilé avec libmachin.a seront affectés et donc il faut tout recompiler et tout réinstaller alors qu'avec une bibliothèque partagée il suffit de remplacer uniquement libmachin.so.

Sinon, ça ne m'étonne pas que ta compilation foire vu la commande, par défaut, gcc compile contre les bibliothèques partagées (.so) si possible et tu lui fais passer la directive -static lui ordonnant de compiler contre les bibliothèques statiques (.a) or comme tu l'as remarqué libX11.a n'existe pas. De plus, en général le -lX11 suffit.

Anvil

Dans les RPMs de façons générale, les fichies .a et .la ne sont pas gardés.

Les .a sont bels et bien presents. Les .la sont effaces, oui.

Il me semble que c'est une politique Fedora de privilégier les bibliothèques partagées et pas les statiques.

C'est pas une politique fedora, c'est d'un cote le bon sens, et de l'autre c'est juste que y'a des trucs fonctionnent plus suivant ce que tu mets en statique.
Mettre la libX11 en statique, ca ne sert generalement a rien, aussi je pense. :p

De plus, ca, c'est incorrect : -L/usr/lib64/libX11.so
-L attend un repertoire qui contient des bibliothques, pas une lib.

benj63

Merci à tous, j'ai corrigé le problème en enlevant le -static :

pgf90 -o rams-5.02 rammain.o -Wl rams-5.02.a ../librams-5.02/librams-5.02.a ../libutils-1.1/libutils-1.1.a -L/usr/local/ncarg-4.4.1/lib -lncarg -lncarg_gks -lncarg_c -L/usr/lib64 -lX11 -L/usr/local/hdf4.1r5/lib -lmfhdf -ldf -ljpeg -lz -L/usr/local/mpich-1.2.6/lib -lmpich -lc -lgcc_eh -ldl -lpthread

ça fonctionne :-D