Undefined symbols
Rocou
Membre
A partir de xcode, je n'arrive pas à obtenir une "release" que je puisse déployer.
Au link, j'obtiens l'erreur "Undefined symbols" qui concerne une bibliothèque que j'ai ajoutée (libpq).
Par contre, en utilisant l'option "zero link", j'obtiens ma "release" qui ne fonctionne bien sûr que sur ma machine.
Je ne comprends pas pourquoi l'édition des liens ne se fait pas correctement.
Au link, j'obtiens l'erreur "Undefined symbols" qui concerne une bibliothèque que j'ai ajoutée (libpq).
Par contre, en utilisant l'option "zero link", j'obtiens ma "release" qui ne fonctionne bien sûr que sur ma machine.
Je ne comprends pas pourquoi l'édition des liens ne se fait pas correctement.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tu n'a probablement pas ajouté la bibliothèque dans ton projet pour l'édition de lien...
Il faut que tu mettes le libpq.a dans les ressources du projet !
Il faut que tu mettes le libpq.a dans les ressources du projet !"
Si, le libpq.a est bien présent. Peut-être pas au bon endroit?
Je l'ai glissé dans "groups & Files", juste sous le nom du projet
Tu l'as simplement glissé ? Est-ce que tu l'as lié à la cible de ton projet ? (Targets)
Il semble l'être. Il se trouve également dans "Groups&Files/Targets/Link Binary With Library"
Sinon, juste avant mon "Undefined symbols", j'ai le warning suivant:
"/usr/bin/ld: warning /opt/lib/libpq.dylib cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded)"
Peut-être est-ce lié?
Ce fichier entête contient les fameuses définitions qui apparaissent dans mon "Undefined symbols".
Cela dit, ça fonctionne en zero link, par conséquent, je ne pense pas que le problème vienne de là . (?)
Et ce fichier d'en-tête se trouve bien dans l'un des emplacements de recherche standard ?
Ce que tu peux essayer c'est de mettre ce fichier dans ton projet et faire un #include "libpq-fe.h".
NB :ça ne marchera pas si ce fichier contient lui aussi des #include "....h"
Cela ne change rien du tout.
Et, cela ne marcherait ni en debug (zero-link) ni en release.
Par contre, où est libpq ?
Est ce une lib que tu intégres dans ton appli, où que tu mets dans OS X dans un rep standard (par exemple "/usr/lib", etc...).
.
Ah ben voilà ... La version de libqp que tu as ajouté est PPC et tu essaies de faire le lien pour i386 (Intel)
Et vu que ça fonctionne en Debug, je suppose que c'est parce que tu travailles sur une machine PPC, donc il ne fait que le lien PPC ; il n'essaie pas de faire un exécutable "Universal Binary".
libpq n'existe pas, c'est -il me semble- un abus de langage pour désigner libpq.a
Où alors, je n'ai rien compris...
J'ai essayé de compiler pour PPC uniquement (en changeant de SDK) mais j'ai toujours ce warning et la même erreur.
Oui, c'est une contraction... je n'ai pas spécifié l'extension de la lib puisque ne la connaissant pas (ce peut être .a, .dylib ou .so).
.
Ce n'est pas en changeant de SDK que tu compiles pour PPC uniquement, c'est en décochant i386 pour "architecture" dans les Build Settings de la cible ("target")
Ha ok, le link se passe bien maintenant :adios!:
Par contre, sur une autre machine, j'obtiens le message suivant à l'exécution:
y-a-t-il un moyen de créer une application complètement "standalone" qui contiendrait cette lib?
Tu n'as pas un .a ?
Quelle est la solution alternative? Copier libpq.4.dylib sur la machine cible?
Je ne comprends pas... Si tu as un libpq.a intégré au projet, pourquoi inclus tu aussi un .dylib ?
Je ne sais pas ce qu'est un .dylib.
Je constate que quand l'exécutable est lancé, l'opération échoue en raison de l'absence de ce .dylib.
Aussi, je voulais savoir comment concevoir un exécutable complètement autonome.
Pour résoudre provisoirement mon problème, j'ai copié le .dylib sur la machine qui devra exécuter ma commande. Cela fonctionne très bien.
Merci à tous pour votre précieuse aide! Si vous avez des infos supplémentaires (où trouver une libpq.a universelle, concevoir une commande autonome, etc. je suis preneur 8--) )
dylib c'est une bibliothèque dynamique... C'est à dire qu'elle n'est pas directement incluse dans l'exécutable, mais juste son chemin de référence (ici /opt/lib/libpq.4.dylib) ; donc ton application n'est plus autonome, et pour l'utiliser aussi sur une autre machine, il faudra également installer la bibliothèque au même endroit.
Alors qu'en Release il fait effectivement l'édition de liens, et là il se rend compte du problème.
Sinon normalement pour faire une appli autonôme tu n'as besoin que du ".a", qui est la version statique de la lib, qui sera intégrée en dur dans ton executable final après édition des liens : alors que les ".dylib" sont dynamiques, c'est à dire chargés à la volée lors de l'execution de l'application (et donc l'avantage c'est que si tu as plein d'applis utilisant cette lib, ça évite d'avoir 15 copies du code de la lib, mais inconvénient ton appli n'est plus autonôme)
Il me semble donc clair que contrairement à ce que je croyais, ma libpq.a n'a pas été incluse à mon exécutable. reste à comprendre pourquoi.