Personne n'a encore osé voter ?

Pour en revenir au problème, un simple lien symbolique ne réglerait pas le problème ?

Heu et l'option -I pour ajouter un répertoire de header ? Je pense aussi que tu peux même définir un variable d'environnement pour cela genre GCC_INCLUDE_DIR.
En gros je crois qu'ils te disent RTFM !

Le répertoire par défaut peut-être défini à la compilation.

C'est défini par le wrapper MPI, ce n'est pas à moi de connaître l'endroit où les bibliothèques sont installées (surtout qu'ils ont le chic de changer les chemins définis par défaut qui fonctionnent ailleurs sur la Terre :/). J'ai des -I pour mes en-têtes des bibliothèques additionnelles, idem pour les -L et -l.
Et si ça marche avec la version n-1, je ne devrai pas avoir à tout revoir et explorer les dossiers pour faire marcher la version n !

Pas sûr que ça suffise, car ce chemin de base est utilisé pour les en-têtes et pour les bibliothèques. De plus, le chemin dans la version n existe sur certaines frontales, mais pas sur les noeuds de compilation/calcul.
Normalement, c'est spécifié proprement dans un fichier de config, mais les copier/coller...

Je ne sais pas qui le fait chez vous, mais le MPI est un projet touchant plusieurs autres personnes.
Donc chacun met où il veut ses librairies et ses entêtes. Je ne vois pas pourquoi ils devraient deviner où tu veux les mettre.

Normalement opt est sous la racine dans le FHS... par défaut c'est bien /opt/ vous avez surement une install baroque.

En même temps ce n'est pas un truc super dur à surmonter. Je pense que tu as mis plus de temps à écrire ton mail qu'à renseigner ta variable d'environnement après un find.

Après c'est au gars qui l'a installé qui devrait vérifier les chemins et tester... Tout dépend de quel support tu parles parce que ceux du projet mpi n'y sont pour rien.

Tu peux en mettre plusieurs des -L et -I aux dernières nouvelles ça marche aussi sur le wrapper et tu peux même configurer tes profils. ;)

«Et si ça marche avec la version n-1, je ne devrai pas avoir à tout revoir et explorer les dossiers pour faire marcher la version n !» Il y a forcement une raison. Quand windows est passé de documents puis document and settings puis user t'as envoyé un mail au support pour signaler que ton script ne marche plus ?

Ouh la, tu n'as jamais travaille dans le domaine HPC... Jamais entendu quelqu'un de ce milieu dire "le MPI".
Dans ces domaines la, on utilise des installations communes a toutes les equipes utilisant le cluster. C'est le boulot de l'administration systeme de configurer correctement les paquets mis a disposition (parce que je n'ai pas les droits par ex de telecharger la version optimisee de la bibliotheque pour mon cluster), pas le mien.
Ici, /opt/etait visible depuis les frontales, mais pas depuis les noeuds ou il y avait un /endroit/ a mettre avant.

De toute maniere, dans toutes les compilations avec MPI, on utilise le wrapper qui place tout correctement. Le fait que ce ne soit pas possible a cause d'un pb de l'installateur/admin est un PEBKAC.

Tu me fais bien rire.
-C'est vrai le HPC est un club très fermé avec un seul cluster où tout est pareil dans le monde. Je ne travaille pas dans ton équipe effectivement, ni chez météo france.
-Certes mon domaine n'est pas exclusivement sur le HPC, je fais aussi de vrais algo distribués déployables sur grid5000, amazon, etc.
-J'ai accès à plusieurs types de clusters bien hétérogènes. D'ailleurs je vais bientôt travailler sur un projet de convergence pour que le chercheur de base arrive facilement à déployer son bousin.
-Je te parle de ce projet http://www.open-mpi.org/ donc l'open-mpi si tu préfères.
-Tu pourrais être administrateur système, je ne te connais pas.
-Ta dernière phrase me montre que tu n'as jamais installé le projet dont je te parle. Car ce wrapper n'est pas magique, il se configure. Tu n'as pas besoin d'être admin pour linker les choses. Ton répertoire ressemble à un point de montage. Si le point de montage n'est plus monté, effectivement, il y a un souci. Mais tu n'en parles pas. Mais ça reste une install baroque. Autant monter tout le /opt/ plutôt que le mettre ailleurs.

j'ai rien compris, ni au texte, ni aux commentaires...
c'est un "diner de c#ns"?

ps: Puis de toute façon ce site n'est pas un repère des private jokes de membres de telle équipe
Comme on dit dans la recherche si ton reviewer n'a pas compris ce n'est pas parce qu'il n'est pas du domaine ou qu'il est nul c'est que tu l'as mal écrit.

Avant toute chose, cherche ce qu'est le MPI, tout deviendra de suite plus clair.

Je vais tenter faire mon captain obvious, enfin si j'ai bien compris.
Là le gars il est coincé parce qu'il n'arrive pas à trouver un fichier .h d'une bibliothèque pour l'implémentation d'une MPI. Qui est un vieux protocole de communication bas niveau. Effectivement, t'as open-mpi, lam4, libmpi* etc. Bref ça reste une lib.

Il écrit au support : "Ca marchait avant maintenant ça ne marche plus" le support lui répond : "c'est normal, il faut prendre l'include à tel endroit" (là où gcc choper ces fichiers header - .h ).
Après il renvoie les deux log de chaque run. le support lui, renvoie la réponse "oui c'est normal vous devez prendre les h à tel endroit".

Le dialogue de sourds en clair.

J'en déduis qu'il pourrait les prendre à tel endroit. Mais aucune indication du pourquoi, il ne peut pas régler cette variable (indiqué dans la doc, déconseillé éviter les confusions des utilisateurs). Le seul argument qu'il avance c'est que le wrapper doit tout faire, que ce n'est pas à lui de savoir et que je ne suis pas membre de la team HPC donc que je ne peux pas comprendre.

Est-ce plus clair ?

Merci la molécule!

D'ailleurs je préfère celui-ci que le PEBKAC précédent: #008127

« Comme on dit dans la recherche si ton reviewer n'a pas compris ce n'est pas parce qu'il n'est pas du domaine ou qu'il est nul c'est que tu l'as mal écrit. »

Moui, mais c'est vachement rassurant de dire que c'est le reviewer qui est nul… quand on n'est pas reviewer. Sinon, évidemment, c'est l'auteur qui est naze.

En toute objectivité. Toujours.

On ne dit pas l'open-mpi, on dit Open MPI. Tu peux configurer ce projet, OK, mais si ce n'est pas la bibliothèque que tu dois utiliser, tu ne peux pas l'installer. Dingue... Tu connais Intel MPI ? MPT ? Ce sont des implémentations payantes,qui doivent être utilisées, avec gestion de licence et que le développeur lambda ne peut pas récupérer et installer lui-même. Sinon naturellement que je l'aurai fait (je l'ai fait dans d'autres cas, peut-être bien plus que toi).
Mais tu ne travailles sans doute pas dans une entreprise où l'installation des bibliothèques est réalisé par une équipe différente de celle qui l'utilise.

Vieux protocole de communication bas niveau ? Tu ne connais vraiment pas MPI. Le premier standard est peut-être vieux, mais la dernière itération est très récente et clairement pas bas niveau !
Ce n'est pas une bibliothèque, c'est potentiellement plusieurs bibliothèques, selon l'implémentation, avec différents headers. La manière de fonctionner est d'utiliser un wrapper qui passe les options de compilation au compilateur derrière automatiquement. Sauf que contrairement à ce que certains croient, il y a des endroits sur Terre où on n'a pas accès en écriture au wrapper (tu imagines le bordel dans une équipe de 30 personnes si chacun avait le droit de changer les config, dans des projets à millions de dollars sur un cluster à plusieurs dizaines de millions de dollars ?) et où on ne peut pas installer la bibliothèque non optimisée qu'on veut parce qu'il n'y a pas la bibliothèque OFED ou DAPLA qui va bien.

Moot > le dernier était très con, l'exemple typique de plus tu veux aller vite, plus tu vas lentement :p

Ben non je suis dans un labo de recherche. C'est moi qui doit me démerder tout seul et en plus je suis moins payé. A croire que je suis maso.

"OK, mais si ce n'est pas la bibliothèque que tu dois utiliser, tu ne peux pas l'installer. " Pourquoi l'installer si tu ne dois pas l'utiliser ?

"Tu connais Intel MPI ?" de nom, mais mon but n'est pas de connaitre toutes les implémentation possibles et inimaginable.

Félicitation tu confonds plein de termes. Vieux ne veut pas dire abandonné. Regarde IP.

Ce n'est pas parce qu'il existe plusieurs implem de la jvm que son assembleur n'est pas de bas niveau.

"Il y a des endroits sur Terre où on n'a pas accès en écriture au wrapper " On ne te demande pas de le réécrire, on te dit d'utiliser les bonnes options. Passer une option ne nécessite pas de posséder les droits d'admin, je te rassure.

OFED serait une bibliothèque et tu me fais chier sur MPI. Heu OFED ne serait pas plus proche d'un OS ? Mais tu peux utiliser des lib pour t'en servir.

Après forcément si tu bloques sur l'écriture de OpEn=MpI forcément le dialogue va tourner court.
Puis j'aime bien aussi c'est comme ça s'écrit comme cela, c'est comme cela qu'on fait, c'est la manière de l'utiliser.
Hey Garry, c'est comme cela que vous l'écrivez, c'est comme cela que vous faites et c'est la manière que vous l'utilisez.
Désolé de te dire, mais tu n'es pas en possession de la vérité absolue.
Mais je comprends le dialogue de sourds maintenant.

Désolé mais sur ce coup, Matthieu n'a pas tort, si l'environnement par défaut n'est pas utilisable, c'est clairement la faute des admins de la machine.

Et pour OFED, plus proche d'un OS ? Va falloir expliquer pourquoi, parce que c'est une remarque qu'on attendrait d'un kissikoné induit en erreur par le mot "Distribution"...

«si l'environnement par défaut n'est pas utilisable, c'est clairement la faute des admins de la machine.»
Ca dépend de ta définition d'utilisable. Ce terme est très relatif à l'utilisateur. Comme le gars qui décrète que son ordinateur est inutilisable, car l'icône n'est pas à l'emplacement habituel. Le problème c'est que l'explication précise n'est pas dans le pebkac et très partiellement dans commentaires. Avoir une lib à un autre endroit n'a jamais rendu un environnement inutilisable.

S'il veut que le profile de son wrapper dans son cluster soit "bien" configuré il aurait dû envoyé un mail du style : «Pouvez-vous configurer le profils machin avec un include pointant dans le bon endroit /endroit/... merci d'avance», La réponse du support est «Vous utilisez include /opt/... vous devez utiliser /endroit/...»
Et il renvoie ces log... heu premier pebkac. Renvoyer un mail en disant «Bonjour, j'ai bien noté votre remarque, mais je ne peux/sais pas configurer; car je dois respecter une norme d'interopérabilité» aurait été peut-être mieux. Mais là d'après le doc il est possible de régler ce genre de truc en cas de non-configuration du profil et sans être root. Donc je demande pourquoi il n'utilise pas le -L ou d'autres flag ou variables. Si t'as deux chemins possibles, tu mets les deux. Sa réponse est ça marchait avant et qu'il n'a pas à le savoir et que je ne connais pas le MPI.

Mettez-vous deux secondes à la place du gars qui fait le support. Il a peut-être fait une erreur. Mais je crois qu'il n'a pas compris ce qu'on lui demandait et à sa place je n'aurais pas compris non plus.

«Et pour OFED, plus proche d'un OS ? Va falloir expliquer pourquoi, parce que c'est une remarque qu'on attendrait d'un kissikoné induit en erreur par le mot "Distribution"...»
Parce qu'il a toutes les couches pour partir du matériel jusqu'à l'applicatif (bypass du kernel). Ce qui est la définition d'un OS. Bon il manque quelques éléments d'où le presque mais bon.

Quelle mauvaise foi, comparer ça au placement d'une icône sur le bureau. Si mpicc existe, c'est bien que lancer le compilo à la main comporte un risque d'erreurs important (trucs en dur la ou il faut pas, utilisation de bouts de versions différentes incompatibles, etc). Lui dire que la bonne solution est de corriger ses chemins a la main, c'est équivalent a dire que mpicc ne sert a rien; c'est peut-être vrai dans l'absolu, mais en pratique on attend autre chose des admins.

Si on considère que le rôle fondamental d'un OS est d'arbitrer l'accès au matériel (mémoire et CPU inclus), OFED n'inclut ni un gestionnaire de mémoire ni un ordonnanceur, et les drivers sont maintenant distribué avec le kernel depuis un moment. Le kernel bypass n'existe que pour des raisons de performance et n'intervient qu'après la bénédiction du kernel. Vis a vis de l'utilisateur, l'ABI reste celle du noyau de l'OS sous-jacent utilisé, la seule différence est une poignée de libs en plus, alors oui, c'est tout à fait raisonnable et correct d'appeler ça une librairie.

@B0th : Icon Lib elle est juste pas au bon endroit. C'est assez similaire.

mpicc existe ce n'est pas le problème. Il accepte aussi les paramètres (je crois que je l'ai répéter un bon nombre de fois), pourquoi ne pas les utiliser sans forcement lancer les compilations à la main ?
Je ne dis pas non plus que c'est une bonne solution. Je n'ai pas cette prétention, je lui demande juste pourquoi, il ne le fait pas.
D'après ce que j'ai lu, tu peux même coller un profil par rapport au nœud lors du déploiement sans polluer ton projet (ni être admin).

"mais en pratique on attend autre chose des admins." Il pourrait au moins à l'admin ce qu'il attend de lui. Ca n'apparait même pas dans le pebkac. Là effectivement si tu lui demandes correctement, s'il n'y arrive pas, il y a pebkac. Mais vu ces explications et le pebkac en lui même et au risque de me répéter, il n'a pas du comprendre.
Après s'il sort à l'admin : tu ne connais rien au MPI. Je crois qu'il pourra courir pour qu'il lève le petit doigt.

pour OFED : d'où le mot "presque". quoique DOS (les premiers) n'a absolument rien de tout cela

Je ne dis pas que ce n'est pas correct d'appeler cela une Lib. Mais je demande pourquoi ce n'est pas correct d'appeler le bout du projet open-MPI qu'il link avec son projet une Lib.

"Je teste un compilateur avec sa bibliothèque MPI associée" puis juste après : "Ce n'est pas une bibliothèque"

read error : device 0 failed to read program "pebkac#8128" ; too many uncomprehensible syntax. Safe mode failed. Please reboot brain.