Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2017:05_19

This is an old revision of the document!


Commit 2017-05-19

Portage MinGW

Je reconstruit une version x86 de Metafor pour anticiper la rentrée prochaine et conserver la compatibilité MinGW (pour rappel, la version x86 est compilée avec gcc sous Windows pour pouvoir tourner sur n'importe quelle machine, meme Vista, voire XP ; ce que ne permet pas le Visual Studio).

La compatibilité du code MinGW avait été perdue. Le problème récurent provient de l'exportation de templates instanciés explicitement. Autrement dit, il s'agit de classes templates compilées dans une DLL et qui doivent être appelés dans une autre. J'ai par exemple dû ajouter une instanciation explicite des StickingElements. Ces éléments sont instanciés dans mtElements et utilisés dans mtDrawables. Si on ne gère pas correctement l'instancation explicite, le mot clef __declspec(dllexport) est ignoré lors de la création de la première DLL, ce qui provoque un “unresolved” lors du link de la seconde. Evidemment, pour compliquer les choses, chaque compilateur gère ça différemment. certains permettent une instanciation explicite même si le template n'est pas encore tout à fait défini (c'est le cas de gcc); et d'autres pas (clang).

Concernant les libs, j'ai recompilé mes libs avec MinGW. Il existe 2 versions de MinGW. Une vieille (MinGW) et une “nouvelle” (MinGW-W64). Toutes les 2 fonctionnent en 32 bits mais seule la seconde permet une compilation 64 bits (qui ne nous intéresse pas ici). J'ai fait le choix d'utiliser la version de MinGW utilisée par les binaires officiels de Qt. Il s'agit de MinGW-W64 avec un gcc 5.3.0. Ceci permet de ne pas recompiler Qt.

Pour python, on pourrait utiliser le python fourni par MinGW-W64 (oui, il y en a un!) mais j'ai finalement décidé d'utiliser le python officiel (qui, pour rappel, est compilé avec le Visual Studio 2008). Cette solution marche bien et a l'avantage de permettre plus tard l'utilisation de “pip” pour installer des packages (mumpy, mpi4py, matplotlib). L'inconvénient est qu'il devient difficile de produire un exe “debug” vu l'absence de Python Debug dans les binaires officiels. Ici, je m'en fous vu que seule une version Release m'intéresse.

Pour VTK, j'ai recompilé la toute dernière version presque sans problème (j'ai dû légèrement modifier le code source mais rien de terrible). Pareil pour PyQt (une légère modif de code source). MUMPS est compilé avec OpenBLAS. TBB ne pose pas de problème.

Suite à ce commit, je remarque que compiler les libs devient de plus en plus simple. Le support MinGW me semble bien répendu parmi les libs qu'on utilise et MinGW m'a semblé cette fois-ci beaucoup plus robuste. En particulier la compilation parallèle fonctionne (mingw32-make -j X) et je n'ai pas eu besoin de MSYS (une sorte de mini système cygwin fourni avec MinGW et que j'avais utilisé la dernière fois pour pouvoir compiler certaines libs).

Divers

Depuis l'utilisation de version debian plus récentes sur gaston et thorgal, certains tests CGAL ne passent pas. Luc avait investigué et avait conclu qu'il devait y avoir un bug depuis le début quelque part. Il suffit de s'acharger (lancer, relancer, relancer, jusqu'à ce que ça marche…).

  • mtExactDataTransfer_CGAL.tests.disk3D_LocMort_2
  • mtExactDataTransfer_CGAL.tests.disk3D_LocMort_3
Je ne l'ai pas fait et j'ai donc commité ces 2 tests en FAILED

boman 2017/05/19 07:54

commit/2017/05_19.1495174779.txt.gz · Last modified: 2017/05/19 08:19 by boman

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki