Anomalie #329
librairie libboost_system-mt non trouvée (version mac OS open source)
Ajouté par Julien Troufflard il y a presque 2 ans. Mis à jour il y a presque 2 ans.
Description
Gérard,
je reçois ce message d'erreur avec HZpp_Vn-1 (dernière version 7.004) :
dyld: Library not loaded: /usr/local/opt/boost/lib/libboost_system-mt.dylib
Referenced from: /Users/troufflard/bin/herezh/HZpp_Vn-1
Reason: image not found
j'ai le même message avec la denière version fast HZppfast_Vn-1 (version 7.003).
Qu'est-ce qui a changé dans la compilation par rapport à avant ? C'est peut-être bizarre que la librairie soit demandée en chemin absolu. Déjà à la base, je n'ai même pas de répertoire /usr/local/opt
a+
Julien
Mis à jour par Gérard Rio il y a presque 2 ans
- Statut changé de Nouveau à En cours
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 ???
Mis à jour par Julien Troufflard il y a presque 2 ans
je pense qu'il y a eu du changement en ce qui concerne le répertoire d'install de boost. Je pense que je peux facilement faire des liens symboliques pour reconnecter certaines librairies boost qui sont chez moi sur /opt.
Par contre, il y a des nouveautés liées, je pense, à la partie parallélisation de Herezh++ (libboost_serialization.dylib, libmpi.40.dylib, etc...). Certaines install nécessitent maintenant python 3.9 sur mon mac. Et ça fait un moment que je ne peux plus suivre. Je n'ai que python 3.7 et j'ai de sérieux problèmes pour mettre à jour (port broken). Mon ordi demanderait une sérieuse remise à jour que je ne ferai pas dans l'immédiat.
Il me reste à passer sur linux désormais pour Herezh++. Ou alors, est-ce qu'il est possible de déployer quelque chose du genre app_image pour les macs qui ne sont pas à la page ?
a+
Julien
Mis à jour par Julien Troufflard il y a presque 2 ans
je suis en train de tenter quand même un upgrade de mes ports (un truc du genre : port selfupdate; port upgrade outdated). Mais j'y crois peu...
néanmoins, si je liste les librairies sur un HZppfast_Vn-1 qui marchait, j'ai :
/opt/local/libexec/boost/1.76/lib/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/libexec/boost/1.76/lib/libboost_system-mt.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/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.6.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
et si je le fais sur le dernier HZpp_Vn-1, j'ai (j'ai mis OK devant celles que j'ai déjà par comparaison avec la version fast) :
OK ===> /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)
OK ===> /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)
OK ===> /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)
OK ===> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)
OK ===> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
Ce qui donne les librairies manquantes :
/usr/local/opt/boost/lib/libboost_serialization.dylib
/usr/local/opt/boost-mpi/lib/libboost_mpi.dylib
/usr/local/lib/libmpi.40.dylib
/usr/local/opt/boost/lib/libboost_system.dylib
est-ce qu'une mise à jour de boost suffit ? ou bien est-ce que tu as installé de nouveaux macports pour ces librairies ? et si oui, quoi ?
Mis à jour par Gérard Rio il y a presque 2 ans
- % réalisé changé de 0 à 10
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/libPour 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
Mis à jour par Julien Troufflard il y a presque 2 ans
bon, sans surprise pour mon ordi, mon actualisation des macports ne va pas jusqu'au bout. Pour l'instant, j'ai un méli-mélo de ports qui ont besoin de python 3.9, d'autres qui veulent du 3.11 et mon mac n'arrive pas à mettre tout le monde d'accord.
Il me faudrait peut-être repartir de 0 sur mes macports. C'est très long à installer (notamment gcc qui prend 3h) et il faut être devant son ordi pour mettre "Yes" de temps en temps. Donc à voir plus tard.
je suis très intéressé par une solution app_image. ça reste la solution la plus simple pour tout le monde. La taille de l'exécutable ne devrait pas être un problème (la version linux app_image ne fait que 20 Mo par exemple).
Mis à jour par Gérard Rio il y a presque 2 ans
- % réalisé changé de 10 à 60
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 ?
Mis à jour par Julien Troufflard il y a presque 2 ans
oui pas de problème. Merci d'avoir essayé (et désolé pour le temps passé). Je serais content d'avoir accès à une nouvelle version herezh pour poursuivre la partie contact et frottement.
ps :
en terme de conteneur, j'ai vu que Aster utilisait quelque chose appelé singularity (avec des fichiers .sif). Je le mentionne juste comme ça (pour la culture gé sur les conteneurs :) ). Je dis pas qu'il faut aller creuser car :
1) je sens que je vais avoir de toute façon des difficultés à installer le nécessaire pour faire fonctionner singularity sur mon mac
(néanmoins je mets ici un lien pour mémoire : https://wiki.ucar.edu/display/JEDI/Install+Singularity+on+Mac+OS+X )
2) même si installé sur macos, ça n'a pas l'air toujours probant (voir par exemple les 3 premiers messages de ce sujet concernant code aster : https://code-aster.org/forum2/viewtopic.php?id=26240)
Mis à jour par Gérard Rio il y a presque 2 ans
j'ai l'impression que singularity est un peu comme appimage ? mais étendue à osX via une virtual box: dans mon cas lorsque j'utilise une virtual box c'est pour faire tourner linux donc a priori (si j'arrive à y intégrer mpi) appimage me semble convernir.
Code aster + salome : c'est une sacré usine. C'est gros car beaucoup de choses y sont agloméré. La doc d'aster est intéressante, pour les runtime je n'ai pas d'expérience en la matière mais cela me semble un peu comme castem avec en plus du pré et post style freecad+gmsh : intéressant dans l'idée, à voir en pratique ...
Peux-tu me dire si la dernière version que j'ai déposé ce matin : 7.005 fonctionne sur ton mac ?
J'ai hâte de changer de sujet !
Mis à jour par Julien Troufflard il y a presque 2 ans
oui, la version 7.005 fonctionne. merci!
note pour d'autres utilisateurs :
à noter que pour faire fonctionner, il m'a été nécessaire de faire des liens symboliques pour les librairies boost. Anciennement, Herezh++ les cherchaient dans /opt/local. Désormais, il les cherche dans /usr/local/opt.
Mis à jour par Gérard Rio il y a presque 2 ans
- Statut changé de En cours à Résolu
- % réalisé changé de 60 à 100
super !
je ferme le ticket !!