Liaison statique d'une bibliothèque sous Linux

Question

J'essaie de créer un composant XPCOM pour Firefox 3.6. *. Il utilise la version 3.7.4 de libsqlite3 compilée statiquement (avec une génération de code indépendante du programme - option du compilateur -fPIC). Le problème auquel je suis confronté est qu'une fois que Firefox charge le composant et qu'il commence à s'exécuter, le sqlite3_libversion_number() renvoie 3007001 tandis que la macro SQLITE_LIBVERSION_NUMBER est définie sur 3007004. Je suis à peu près sûr que je suis lié à la bibliothèque statique sqlite3 correcte ... Mais comment puis-je vérifier cela? ldd La sortie de l'objet partagé généré ne répertorie pas libsqlite3.so en tant que dépendance (bien que libxul.so, utilisé pour créer le composant XPCOM, utilise libsqlite3.so). Comment tous les appels de fonction sqlite3 sont-ils résolus vers une version différente de SQLite? PS: Est-ce parce que les bibliothèques sont compilées avec -fPIC et que Firefox les charge ensuite en utilisant dlopen?

Answer 1

Je regarde la commande d'inclusion. J'ai aussi passé toute une journée ou quelque chose de similaire à me demander pourquoi le fseek() a échoué, pas directement sur Linux mais sur Bada, et en utilisant Eclipse IDE. Le hic était que la même fonction ayant la même signature était exportée par un fichier .a "beta" de Bada SDK. Et j'ai d'abord importé le mauvais fichier .a par accident.

Answer 2

En linux, il effectuera une résolution récursive des symboles - c'est-à-dire si libxul utilise libsqlite3 alors firefox résoudra indirectement le symbole en incluant libsqlite3 de libxul.

Ce n'est pas le cas sur une machine AIX où la résolution de symboles récursifs (basée sur des bibliothèques dépendantes) ne sera pas effectuée.

Cela peut ne pas être le problème réel - mais il vaut la peine de vérifier.

Vérifiez également si sqlite3 est rétrocompatible (ce que je suppose), alors vous pouvez lier libxul et d'autres bibliothèques à la dernière version de sqlite3.