Posté par Gabbro .
En réponse au journal pythran 0.9.12 - heskenn.
Évalué à 4.
Dernière modification le 14 juillet 2021 à 17:02.
À mon tour de me montrer curieux : quel genre de galère rencontres-tu ?
L'export des symboles avant toute chose. Ce n'est pas systématique (heureusement), mais c'est tellement la galère quand ça arrive.
Le principe est simple : sous Linux, tous les symboles sont exportés par défaut, donc toutes les fonctions sont accessibles de n'importe où ; sous AIX, non. En pratique, ça se rencontre avec tous logiciels qui a un système de plugin, et qui va chercher des fonctions d'une bibliothèque via l’exécutable. Ce qui est le cas en Python. C'est-à-dire pythran.so est chargé par python, qui charge aussi libpython.so, et pythran.so tente d'utiliser des fonctions de libpython.
Comme tu as pu le constater, on a fait le boulot pour que tout marche bien par défaut avec python, mais on n'est jamais sûr que tout marche vraiment bien dans les cas limites (et pythran peut rentrer dedans).
Les autres blagues habituelles sont que par défaut, le ld d'AIX cherche des .a qui contiennent des .so pour les bibliothèques dynamiques et pas des .so directement. Soit on tripatouille la compilation (configure / libtool, cmake, voir les Makefile) pour que tout soit propre, soit on utilise des options magiques qui font le travail à notre place, et qui ont des effets de bords catastrophiques.
Ensuite, concernant le C++, on a des soucis récurrents avec les exceptions avec GCC. Mon collègue connait ça mieux que moi, mais la première fois qu'on a tenté de compiler Boost, GCC n'a pas aimé...
Dans le détail, on a des fonctions manquantes, parfois des fonctions POSIX standard mal codées, une couche réseau pas tout à fait comme les autres, etc... Bref, le standard du portage. Et pour une raison que l'on a jamais comprise, lorsqu'un bug est reproductible 1 fois sur 100 sous Linux, on est plus à 1 fois sur 2 sous AIX. On a eu le coup plusieurs fois...
Ensuite je n'ai pas testé moi même, ni même lancé la suite de test. C'est juste un retour d'utilisateur satisfait une fois ces deux changements appliqués !
Je manque de temps en ce moment, mais je vais essayer de glisser ça dans un coin. Si ça explose, je ne pourrai pas regarder en détail, mais dans tous les cas j'essayerai de te faire un retour.
[^] # Re: AIX
Posté par Gabbro . En réponse au journal pythran 0.9.12 - heskenn. Évalué à 4. Dernière modification le 14 juillet 2021 à 17:02.
L'export des symboles avant toute chose. Ce n'est pas systématique (heureusement), mais c'est tellement la galère quand ça arrive.
Le principe est simple : sous Linux, tous les symboles sont exportés par défaut, donc toutes les fonctions sont accessibles de n'importe où ; sous AIX, non. En pratique, ça se rencontre avec tous logiciels qui a un système de plugin, et qui va chercher des fonctions d'une bibliothèque via l’exécutable. Ce qui est le cas en Python. C'est-à-dire pythran.so est chargé par python, qui charge aussi libpython.so, et pythran.so tente d'utiliser des fonctions de libpython.
Comme tu as pu le constater, on a fait le boulot pour que tout marche bien par défaut avec python, mais on n'est jamais sûr que tout marche vraiment bien dans les cas limites (et pythran peut rentrer dedans).
Les autres blagues habituelles sont que par défaut, le ld d'AIX cherche des .a qui contiennent des .so pour les bibliothèques dynamiques et pas des .so directement. Soit on tripatouille la compilation (configure / libtool, cmake, voir les Makefile) pour que tout soit propre, soit on utilise des options magiques qui font le travail à notre place, et qui ont des effets de bords catastrophiques.
Ensuite, concernant le C++, on a des soucis récurrents avec les exceptions avec GCC. Mon collègue connait ça mieux que moi, mais la première fois qu'on a tenté de compiler Boost, GCC n'a pas aimé...
Dans le détail, on a des fonctions manquantes, parfois des fonctions POSIX standard mal codées, une couche réseau pas tout à fait comme les autres, etc... Bref, le standard du portage. Et pour une raison que l'on a jamais comprise, lorsqu'un bug est reproductible 1 fois sur 100 sous Linux, on est plus à 1 fois sur 2 sous AIX. On a eu le coup plusieurs fois...
Je manque de temps en ce moment, mais je vais essayer de glisser ça dans un coin. Si ça explose, je ne pourrai pas regarder en détail, mais dans tous les cas j'essayerai de te faire un retour.