.dylib fait avec Delphi XE2 ne peut pas être utilisé par l'application Xcode

Question

J'ai construit un dylib 32 bits pour OS X avec Delphi XE2 Upd. 3. Son nom d'installation utilise @rpath. Toutes les exportations commencent par un trait de soulignement, vérifié avec otool. Les exportations utilisent la convention d'appel "cdecl" dans Delphi.

Je n'arrive pas à faire fonctionner ce dylib avec une application hôte 32 bits dans Xcode 4.3 fonctionnant sous OS X 10.7.3. Lorsque j'exécute le projet de test depuis Xcode, il s'arrête avec l'appel de lib et dyld_start dans la pile d'appels.

Quand je lance cette application à partir du Finder (à partir du dossier Xcode au sein de la bibliothèque de l'utilisateur), je reçois l'image non trouvé erreur de dyld.

J'ai déjà ajouté une phase de construction de copie, qui copie le dylib (et libcgunwind.1.0.dylib dont il a besoin) dans le répertoire Products. J'ai également défini Runpath Search Paths à @executable_path ou @loader_path, mais en vain.

La méthode est importée via

extern int TestLib(int AInt); 

La bibliothèque est aussi minime qu'il peut obtenir et ne contient que cette unité:

unit LibTestExports; 

uses 
    System.Classes, 
    System.SysUtils; 

function _TestLib(AInt: Integer): Integer; export; cdecl; 
begin 
    Result:= AInt + 2; 
end; 

exports 
    _TestLib; 

end. 

Je suis d'idées sur ce qui en est la cause et comment je peux faire fonctionner ça.

Le projet Xcode et les libs se trouvent ici: http://dl.dropbox.com/u/17403534/CAS4LibTest.zip

MISE À JOUR: Ce problème semble être Lion spécifique! Cela fonctionne très bien dans Snow Leopard 10.6.4 avec Xcode 4.2. (Xcode 4.2 sur Lion entraîne le même problème)

Le même dylib fonctionne également très bien sous Lion lorsqu'il est utilisé par une application FireMonkey (les méthodes sont importées statiquement en utilisant external 'libName').

L'exécution de la même application sous Lion, qui fonctionne très bien sous SnowLeopard, je reçois un rapport de plantage contenant la pile d'appel suivant:

0 ???        0x0013317c 0 + 1257852 
1 libCAS4.dylib     0x00010b5c @DbgEvalFrame + 1648 
2 libCAS4.dylib     0x00010e1a @DbgEvalFrame + 2350 
3 dyld       0x8fe55203 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 251 
4 dyld       0x8fe54d68 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 64 
5 dyld       0x8fe522c8 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 256 
6 dyld       0x8fe5225e ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 150 
7 dyld       0x8fe53268 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 62 
8 dyld       0x8fe47694 dyld::initializeMainExecutable() + 214 
9 dyld       0x8fe4bf99 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**) + 2238 
10 dyld       0x8fe452ef dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*) + 637 
11 dyld       0x8fe45063 _dyld_start + 51 

Solution: soutien Embarcadero est venu maintenant de retour avec une solution de contournement, qui fixe le problème pour moi: dans une copie locale de System.Classes, modifiez la déclaration de GlobalNameSpace: IReadWriteSync à la classe appropriée utilisée dans la section d'initialisation.

Answer 1

La bibliothèque que vous créez a une dépendance implicite sur bplrtl160.dylib, que vous devrez regrouper avec l'application - Vous devez vous assurer que la bibliothèque est créée à l'aide de packages d'exécution.

Il existe une forme de magie d'initialisation qui se produit lorsque vous créez un exécutable avec Delphi XE2 qui ne se produit pas lorsque vous générez l'application sous xcode, ce qui cause le problème; probablement un code d'initialisation qui est lié à l'application qui n'est pas liée lorsqu'elle est créée en tant que bibliothèque.

L'exception réelle que vous obtenez est en:

@$xp$30System@Sysutils@IReadWriteSync 

qui se passe à bplrtl160.dylibcharge temps (à savoirvous n'avez même pas à interagir avec la bibliothèque à ce stade). C'est une classe d'interface qui devrait être initialisée au moment du chargement de l'application.

Si vous supprimez les entrées System.SysUtils, System.Classes de la clause uses du fichier de bibliothèque, la bibliothèque sera chargée; mais cela signifie que toute bibliothèque que vous construisez à partir de XE2 ne peut pas utiliser le code classes et sysutils; ce qui le rend un peu moins adapté à l'utilisation.

Comme pour le correctif; Je ne sais pas. Il n'y a peut-être pas de solution du tout.