hello,

je cherche à compiler un programme pour lequel j'ai besoin de 2 headers en C : pgm.h et floatingpoint.h ; qui n'étaient présentes sur ma machine. je les ai téléchargées et mises dans /usr/include. Mais à la compilation j'ai toujours ce :
checking pgm.h presence... no
Qu'est ce que j'ai mal fait ?
tu veux dire que tu as telechargé juste les .h??
yum provides "*/pgm.h"
oui pardon j'avais oublié de préciser, cette lib est dans netpbm-devel, que j'ai installé ; mais pour autant elle n'est pas trouvé à la compilation, du coup je me suis dit que ptete que la mettre dans /usr/include ça règlerait le problème. mais apparemment non ^^

du coup ça viendrait de la manière dont le compilateur est configuré alors ? y a t il un moyen de lui indiquer qu'il faut aller chercher dans /usr/include/netpbm/ ?
Il passe par pkg-config?

pkg-config --cflags netpbm

normalement ça t'indiquera les flags de compilation à mettre, quelque chose en -I/usr/include/netpbm (i majuscule, pour inclure un repertoire)
allons bon, il n'y a pas de fichiers netpbm.pc ; du coup je ne peux pas dire à PKG_CONFIG_PATH où aller chercher ...

une alternative ?
regarde avec

rpm -q netpbm-devel --filesbypkg

où se trouve le fichier que tu cherches.
nouvo, ta commande me donne /usr/include/netpbm mais je savais déjà cela.

ce qui m'embête c'est qu'a priori il faut que j'indique le répertoire à PKG_CONFIG_PATH où se situe le netpbm.pc , or ce dernier semble ne pas exister. qu'est ce que je n'ai pas compris ?
Salut,

Par curiosité, quel est le programme que tu cherches à installer ?
gerris, c'est un programme de simulation pour fluides complexes. La procédure pour l'installation est décrite ici.

Ils ont une version packagée (non officielle) pour f16 mais ça me gave un peu d'installer f16.


Maintenant je viens de penser à un truc : est ce que à partir du rpm pour f16 je peux me débrouiller pour faire un rpm pour f17 ?

Haha du coup en cherchant le lien pour le rpm f16 je me suis aperçu qu'il y a un rpm pour f17. ça n'était pas le cas il y a quelques semaines je crois (quand je m'y suis intéressé), ou alors j'ai manqué un truc.

je l'installe via yum puis je clorai ce fil... merci quand même pour vos contributions et passez de bonnes fêtes 😉
GNNNNNNNNNNNNNNNNNNNNNNNNN

Allons bon...

Donc j'ai fait un make uninstall puis un make clean, puis j'ai supprimé les sources.

lors du yum install, je me retrouve avec un :
=================================================================================================
 Package                      Architecture  Version                          Dépôt         Taille
=================================================================================================
Installation de :
 gerris-snapshot              x86_64        1.3.2-159.1                      gerris        701 k
Installation pour dépendances :
 gerris-snapshot-devel        x86_64        1.3.2-159.1                      gerris        171 k
 gts                          x86_64        0.7.6-20.20111025.fc17           fedora        201 k
 gts-devel                    x86_64        0.7.6-20.20111025.fc17           fedora         24 k
 gts-snapshot                 x86_64        0.7.6-48.1                       gerris        208 k
 gts-snapshot-devel           x86_64        0.7.6-48.1                       gerris         31 k

Résumé de la transaction
=================================================================================================
Installation   1 Paquet (+5 Paquets en dépendance)

Taille totale  : 1.3 M
Taille d'installation : 4.4 M
Est-ce correct [o/N] : o
Téléchargement des paquets :
Test de la transaction en cours
Lancement de la transaction de test
Donc jusque là, nickel, puis j'ai un
Erreur du contrôle de transaction :
  file /usr/bin/gts2dxf conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/gts2oogl conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/gts2stl conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/gtscheck conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/gtscompare conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/gtsdelaunay conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/gtshapprox conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/gtstransform conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/stl2gts conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/lib64/libgts-0.7.so.5.0.1 conflicts between attempted installs of gts-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-0.7.6-48.1.x86_64
  file /usr/bin/gts-config conflicts between attempted installs of gts-devel-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-devel-0.7.6-48.1.x86_64
  file /usr/include/gts.h conflicts between attempted installs of gts-devel-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-devel-0.7.6-48.1.x86_64
  file /usr/include/gtsconfig.h conflicts between attempted installs of gts-devel-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-devel-0.7.6-48.1.x86_64
  file /usr/lib64/pkgconfig/gts.pc conflicts between attempted installs of gts-devel-0.7.6-20.20111025.fc17.x86_64 and gts-snapshot-devel-0.7.6-48.1.x86_64
je trouve ça étonnant... je dois supprimer les /usr/bin/gts* à coup de rm -f ? ou y a t il plus propre ?
Le problème c'est que la version de gts de Fedora n'est pas à jour, d'ou les problème de dépendances...
En regardant sur koji, je vois que la version est gts-0.7.6-20, et pas de trace de gts 0.7.6-48: http://koji.fedoraproject.org/koji/buildinfo?buildID=285852

Je pense qu'il faudrait demander au mainteneur de gts sur fedora de mettre à jour vers cette version 0.7.6-48, en faisant un rapport sur le bugzilla.
ok je fais ça de suite, en attendant je vais faire le sale à coup de rm...

merci pour vos conseils
le problème c'est pas la version (0.7.6 pour les 2), c'est que le gts de fedora, et le paquet gts-snapshot embarquent les mêmes fichiers, donc forcément conflit... D'ailleurs ton rm tu veux le faire sur quoi? C'est déjà forcément une mauvaise idée à la base (sauf si tu veux tout peter), mais surtout les fichiers cités sont dans les paquets que yum n'a pu installer à cause du conflit de fichiers detecté.

tu peux donc regler le problème avec la commande suivante:
yum install gerris-snapshot --exclude=gts
j'aurai voulu virer les /usr/bin/gts* qui posait problème.

ce que tu proposes marche très bien, merci pour la solution élégante.

ce qu'il me manque c'est une version parallélisée du programme, je n'y arrivais pas à la main et le paquet précompilé ne le supporte pas non plus, mais anyway, je laisse tomber ça pour l'instant.

merci encore et passez de bonnes fêtes !
c'est pour ça que tu voulais compiler gts? tu devais pas être bien loin si c'est juste une histoire de .h qu'il ne sait pas trouver. Des fois le script configure propose des options genre --with-netpbm=/chemin et on peut lui indiquer où chercher.
là où ça bloque pour le parallèle c'est plutôt à la compilation de gerris, il semble qu'il n'y ait pas besoin de compiler gts d'une manière particulière pour faire tourner des simu en parallèle.

Avec un module load openmpi, gerris ne compile pas (et j'ai la flemme de me retaper la compilation là pour être honnête, donc pour les messages d'erreur on va attendre ^^)pour l'instant j'apprends à utiliser ce logiciel, quand j'aurai besoin de faire tourner des simu plus grosses je me repencherai dessus. je vous laisse tranquille pour les fêtes =)

de toute façon pour faire ça il faudrait que je sois un peu moins une bille, c'est la première fois que j'essaie de compiler un programme, du coup je ne sais pas comment quelles options passer au compilateur pour que ça se passe bien... ça attendra.
il faudrait que je sois un peu moins une bille
Au contraire, c'est parce que tu ne l'es pas que tu essaies. Bien sur qu'il y a des astuces et des obstacles mais personne n'a eu le don à la naissance, de savoir comment compiler un programme.

Aussi longue soit la route, elle commence toujours par un pas. Tu l'as fait. Bravo. Continue, à ton rythme.
merci pour les encouragements nouvo 😉 au passage s'il tu as un bon tuto pour apprendre à compiler, je suis preneur
Edouard_le_homard wrote:merci pour les encouragements nouvo 😉 au passage s'il tu as un bon tuto pour apprendre à compiler, je suis preneur
Il n'y a pas de compilation standard, vu d'une part qu'il manque souvent les dépendances, et d'autre part qu'elle ne s'effectuera pas forcément de la même manière, selon qu'il y aura un configure ou pas, ou bien qu'il faudra exécuter cmake à la place, ou directement make, sans oublier à la fin 'make install', etc..., ou encore qu'il faudra ou pas se placer dans un dossier à part...

Donc, avant de compiler, perdre quelques minutes pour se préparer, ne pas se précipiter.

1) Si on le peut, se renseigner avec Google quelles sont les dépendances éventuellement manquantes avant de compiler, les éventuels problèmes, et la procédure de compilation, ça fait souvent gagner du temps et de la sueur.

2) Une fois le fichier décompressé, avant de compiler lire le READ ME et zyeuter dans le principal dossier s'il y a le fichier 'configure', le 'make', éventuellement un 'cmake', pour ne pas partir à l'aveuglette.

3) Une fois compilé, il faut souvent déplacer le bin dans l'emplacement habituel /usr/bin

4) Il faut créer son petit raccourci à la main qui sera en fait un script (clic droit dans bureau et "Créer un nouveau lien vers une application"), pas dur, et aller chercher le logo souvent en png, ou en xpm, pour "habiller" ce raccourci.

Bonnes fêtes et bonnes compilations ! 🙂