La recherche de symbole dynamique échoue avec Python statiquement incorporé sous Mac OS X

Question

Je suis en train de créer une application Mac OS X destinée à intégrer Python. Mon application est techniquement un bundle (c'est-à-dire que son exécutable principal est MH_BUNDLE); c'est un plug-in pour une autre application. Je voudrais l'intégrer statiquement, mais je veux pouvoir charger les extensions dynamiquement.

J'ai fait le texte suivant: J'inclus une bibliothèque (-force_load path/to/libpython2.7.a), aussi réexporté tous les symboles Python (-exported_symbol_list path/to/list), et a ajouté le -u _PyMac_Error, que je suis en utilisant this linking advice. Le bundle se charge très bien, tout le code Python interne semble fonctionner, mais il échoue lorsqu'il il tente d'importer une bibliothèque dynamique (time.so) avec le message suivant:

Traceback (most recent call last): 
    ... 
ImportError: dlopen(/<stripped>/time.so, 2): Symbol not found: _PyExc_OverflowError 
    Referenced from: /<stripped>/time.so 
    Expected in: dynamic lookup 

Ce symbole est une partie de l'API Python et ça doit être déjà dans mon paquet. Je peux vérifier ceci:

nm -g Build/Debug/pyfm | grep _PyExc_OverflowError 
00172884 D _PyExc_OverflowError 
0019cde0 D _PyExc_OverflowError 

(Il est énuméré deux fois parce que j'ai deux architectures, i386 et ppc).

Le time.so ne fait référence à rien, qui, comme je le comprends, est par la conception:

otool -L "/<stripped>/time.so" 
/<stripped>/time.so (architecture ppc): 
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) 
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11) 
/<stripped>/time.so (architecture i386): 
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) 
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11) 

Mon problème semble être similaire à this, mais il est l'inverse: je statiquement Python lien , alors que l'autre affiche l'a reliée dynamiquement (nos plateformes sont différentes aussi). Pour lui, la liaison statique a résolu le problème.

Pourquoi ne trouve-t-il pas le symbole?

Mise à jour. Je suppose que cela arrive parce que l'application principale charge ses plug-ins (et donc mon bundle) avec RTLD_LOCAL.

Answer 1

La « mise à jour » Je suggère que ce fait droit: le principal bundle de plug-in est chargé localement (RTLD_LOCAL), de sorte que personne ne peut voir tous les symboles là, à moins d'utiliser dlopen explicite suivie dlsym.

Si c'était Linux, je pourrais promouvoir le bundle dans l'espace de noms global en le reprenant avec l'indicateur , mais sous Mac OS X cela ne fonctionne pas. Mais Mac OS X emballe joliment les choses dans des paquets, donc je viens de faire une bibliothèque dynamique et le mettre dans le répertoire du bundle de plug-in. La bibliothèque se charge automatiquement en tant que RTLD_GLOBAL et tous les symboles Python sont disponibles.