›

[Résolu]Xcode Incompatible library version libexpat

mybofymybofy Membre
décembre 2017 modifié dans Xcode et Developer Tools #1

Bonjour


macOS 10.13 - Xccode 9.1


 


Dans mon projet j'utilise le port "wxWidgets-3.2 @3.1.0-git-20171103" de MacPorts, qui nécessite la  librairie "libexpat.1.dylib". Pour être cohérent j'ai installé le port "expat @2.2.5", qui me donne cette librairie.


  


Après avoir ajouté des @rpath là  où il faut afin d'embarquer les libraries nécessaires dans l'application, je lance Xcode : après la fin du build sans erreurs ni avertissements, j'obtiens le message 




dyld: Library not loaded: @rpath/libexpat.1.dylib

Referenced from: /Users/rn/Apps/AppWx/Wherbarium/DerivedData/Wherbarium/Build/Products/Release/Wherbarium.app/Contents/MacOS/Wherbarium

Reason: Incompatible library version: Wherbarium requires version 8.0.0 or later, but libexpat.1.dylib provides version 7.0.0

Or ma librarie libexpat a bien la version 8000 :




/opt/local/lib >> otool -L libexpat.1.6.7.dylib

libexpat.1.6.7.dylib:

@rpath/libexpat.1.dylib (compatibility version 8.0.0, current version 8.7.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

Il y a une grosse incohérence, mais je ne trouve rien qui cloche.


 


Merci de l'aide.


Mots clés:

Réponses

  • CéroceCéroce Membre, Modérateur
    #2

    Je suppute que comme libexpat.dylib n'est pas trouvée, il élargit la recherche dans les répertoires standard et finit par la trouver, mais dans une version antérieure.


     


    Est-ce que libexpat est bien copiée dans le bundle de l'appli avec une Copy phase ?


  • mybofymybofy Membre
    #3

    Bien supputé ! et oui il y a bien une Copy Phase.


     


    D'abord petite nouveauté de macOS 10.13 :


    Dans l'onglet "General" de "TARGETS" il y a "Linked Frameworks and Libraries" équivalent au "Linked Binary With Libraries" de "Build Phases"


    Il y a aussi "Embedded Binaries" qui se retrouve dans "Build Phases" s'il est rempli, équivalent à  la création d'un "Copy Files">Frameworks


    Le fonctionnement semble strictemnt le même, un peu plus pratique peut-être. Dommage qu'il ne gère pas implicitement les" install names". Quite à  parler d'"embed" autant aller jusqu'au bout...


     


    En ce qui concerne la librairie "libexpat", MacPorts inclut "/opt/local/lib/libexpat.1.dylib", qui est un lien vers "/opt/local/lib/libexpat.1.6.7.dylib". Xcode  ne voit donc rien "en dur" dans "/opt/local/lib" et va chercher dans les librairies système, où il y a bien "/usr/lib/libexpat.1.dylib" en dur qui n'a pas la bonne version d'où l'erreur. Apparemment Xcode ne gère pas ou mal les liens. Il suffit de le savoir.


     


    Deux questions :


    1. Est-il possible de forcer le suivi des liens le cas échéant, avant de passer aux répertoires par défaut (sytèmes en l'occurence), voire de supprimer cette recherche ? Le message d'erreur serait sans doute plus clair.


    2. Supposons la descendance de librairies :


             L0 -> L0.2 -> L0.2.19


    Il faut modifier, avec install_name_tool, les chemins avec @rpath au lieu des chemins en dur, dans L0 bien sûr, mais aussi dans L0.2. Faut-il aller plus loin et le faire au niveau L.0.2.19, jusqu'à  la fin des branches ? J'ai essayé des scripts trouvé ici ou là  sur le net, mais ils m'ont mis une pagaille noire...


     


    Merci


  • CéroceCéroce Membre, Modérateur
    #4

    1. Est-il possible de forcer le suivi des liens le cas échéant, avant de passer aux répertoires par défaut (sytèmes en l'occurence), voire de supprimer cette recherche ? Le message d'erreur serait sans doute plus clair.

    Je n'en sais rien, parce que je n'ai jamais procédé ainsi. En général, on incorpore la dylib dans l'appli qui l'utilise, autrement ça impose à  l'utilisateur de passer par un installateur. D'où l'utilisation d'une Copy phase pour placer dans la dylib dans l'application.

    2. Supposons la descendance de librairies :
             L0 -> L0.2 -> L0.2.19
    Il faut modifier, avec install_name_tool, les chemins avec @rpath au lieu des chemins en dur, dans L0 bien sûr, mais aussi dans L0.2. Faut-il aller plus loin et le faire au niveau L.0.2.19, jusqu'à  la fin des branches ? J'ai essayé des scripts trouvé ici ou là  sur le net, mais ils m'ont mis une pagaille noire...

    Tu t'aventures en terrain dangereux. Je ne me souviens pas des détails (ça remonte à  au moins 7 ans!), mais l'install path est fixé au build de la dylib. Dans mon souvenir, le @rpath permettait justement de s'affranchir des install paths.
  • mybofymybofy Membre
    #5

    Avec une gestion fine des @rpath dans les dylib externes, j'ai réussi à  faire fonctionner correctement l'ensemble.


     


    Merci


Connectez-vous ou Inscrivez-vous pour répondre.