Herezh++

c'est très étrange !
Normalement pour mac il faut charger la librairie Boost via par exemple macport (c'est ce que je fais personnellement)
https://www.macports.org/install.php
mais c'était vrai aussi pour les anciennes versions depuis longtemps ???

oui ton analyse est bonne.
Normalement les derniers exécutables n'utilisent pas MPI par défaut, ce sont d'autres exécutables qui sont générés pour utiliser MPI, cela via des directives de précompilation (ifdef ....).
Donc je pensais que les bibli MPI n'étaient pas demandés lors de l'exécution d'HZpp_Vn-1 et la version fast (je n'avais pas vraiment vérifié !). Mais a priori Xcode me les intègre quand même malgré le fait qu'elles ne soient pas nécessaire, cela sans doute parce qu'elles sont dans la liste des bibli possibles que j'ai mis pour l'édition de liens.
Ceci étant les versions MPI sont en cours et tu risques de vouloir les utiliser. Du coup, le plus simple serait de récupérer la biblio boost + MPI
Boost MPI n'est pas == à MPI, c'est une surcouche à un MPI qui doit avoir été installé. Dans mon cas j'ai utilisé openMPI
Ce n'est pas forcément simple ... j'ai un peu sué pour y arriver, mais c'était peut-être parce que je découvrais.

Voici ce qui a fonctionné pour moi:

- installation de openMPI à partir des sources  (openMPI c'est une version de MPI)
    - installation de la dernière version de boost-mpi avec homebrew
       brew install boost-mpi
       qui installe la version 1.76 de boost + la partie MPI -> /usr/local/include et /usr/local/lib

Pour info, sur ma machine, voici les bibliothèques que j'utilises:

gerardrio@lg2m-2017.local% otool -L HZpp_Vn-1
HZpp_Vn-1:
/usr/local/opt/boost/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/boost/lib/libboost_serialization.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/boost/lib/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/boost-mpi/lib/libboost_mpi.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
/usr/local/lib/libmpi.40.dylib (compatibility version 71.0.0, current version 71.2.0)
/usr/local/opt/boost/lib/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)

Effectivement, une solution plus simple serait de faire un truc du genre de l'appimage, je vais regarder... car je crois que c'est possible, par contre les exécutables seront peut-être beaucoup plus gros ??? à voir

Je ne sais pas par où commencer vu le nombre de choses que j'ai essayé !!
La première chose que j'ai tentée est de mettre en place un équivalent à appimage. Sur mac je n'ai rien trouvé de réellement équivalent.
1) il existe la possibilité de créer une appli dans un sandbox pour limiter les accès en dehors du sandbox.
ok, mais le vrai pb c'est comment remplir le sandbox avec toutes les ressources nécessaires et là j'ai passé un temps abominable sur la doc XCODE, sur les posts divers et avariés ... En gros j'ai réussi à voir que plusieurs développeurs avaient des pb identiques, mais je n'ai pas trouvé de solutions simples : néanmoins il y a qq usines à gaz qui semblent fct pour certains !
2) donc que ce soit dans un sandbox ou autre container, les pb que je crois voir sont:
- comment générer automatiquement le container: là à priori c'est possible avec une sortie Archive d'xcode, mais... seul l'exécutable est mis dans l'archive: il manque toutes les lib nécessaires
- après avoir regardé comment étaient installés d'autres conteneurs d'exécutables classiques (type audacity, freecad etc.) je vois bien que la solution utilisée est de mettre dans le conteneur toutes les lib nécessaires. Se posent 2 pb:
a) comment intégrer automatiquement les lib: a priori la seule solution c'est de recopier directement les lib dans le conteneur: il faut être sûr de ne rien oublier ! car certaines lib dépendent d'autres lib ... et se pose le pb de la compatibilité des exécutables des lib avec la version de l'os
b) comment mettre à jour les liens entre l'exécutable et les lib, qui sont générés au moment de la construction de l'exécutable ? Là je n'ai pas vraiment trouvé... les liens sont a priori gravés dans l'exécutable ... peut-être qu'en générant avant exécution, la variable d'environnement ad hoc donnant le chemin des lib à consulter avant les chemins par défaut ? j'avoue que j'ai du mal à suivre les méandres liés à ces chemins !

En plus les conteneurs Apple sont très particuliers (bundle): type pkg ou dmg. Ils doivent avoir une structure précise. Là j'ai trouvé des solutions pour construire un conteneur a priori correct. Mais il me reste néanmoins des interrogations concernant: des numéros d'ID spécifiques (composé d'une partie générée automatiquement, et d'une autre que l'on peut choisir, mais... qui doit être unique !) et ...

Bref c'est compliqué à souhait, chronophage et inintéressant (enfin pour moi), et j'ai fini pas jeter l'éponge concernant la recherche d'un équivalent appimage ! pourtant c'est a priori possible ...

Deuxième voie, que j'aurais dû regarder en premier !!
- pourquoi subitement il faut les lib mpi dans les exécutables classiques qui n'utilisent pas de mpi !! et bien c'est parce que j'ai inclus les lib dans l'édition de lien pour tous les exécutables avec ou sans mpi.
J'ai donc particularisé l'édition de lien: sans lib mpi pour HZpp_Vn-1 et HZppfast_Vn-1, et avec mpi pour les versions //
Et là ça fonctionne, les exe classiques ne mentionnent plus de relation avec les nouvelles lib.

Du coup, cette solution ne fonctionnera pas pour les versions mpi pour ceux qui n'auront pas de lib mpi installée, mais ce sera ok pour ceux qui auront une version d'osx avec les lib mpi ad hoc.

Pour les premiers la solution sera d'utiliser les versions Linux, à condition que j'arrive à générer des appimages avec le lib mpi: chose que je n'ai pas encore faite ! Mais j'ai bon espoir que ce sera plus simple qu'avec les conteneurs Apple !

Conclusion: je mets à jour les exe classiques pour osX sans ref aux lib mpi: Julien, peux-tu me dire si c'est ok ?

super !
je ferme le ticket !!