Статическое связывание библиотеки в Linux

Question

Я пытаюсь сделать компонент XPCOM для Firefox 3.6. *. Он использует libsqlite3 версии 3.7.4, скомпилированную статически (с программно-независимой генерацией кода - опция компилятора -FPIC). Проблема, с которой я сталкиваюсь, заключается в том, что как только Firefox загружает компонент и он начинает выполняться, sqlite3_libversion_number() возвращает 3007001, в то время как макрос SQLITE_LIBVERSION_NUMBER определен как 3007004. Я уверен, что я ссылаюсь на правильный статический sqlite3 библиотека ... Но как я могу проверить это дважды? ldd вывод сгенерированного общего объекта не перечисляет libsqlite3.so как зависимость (хотя libxul.so, используемый для создания компонента XPCOM, использует libsqlite3.so). Как все вызовы функций sqlite3 разрешаются в другой версии SQLite?

PS: Это потому, что библиотеки скомпилированы с -fPIC, и Firefox позже загружает их, используя dlopen?

Answer 1

В linux он будет выполнять рекурсивное разрешение символов - то есть, если libxul использует libsqlite3, то firefox косвенно разрешит символ, включив libsqlite3 из libxul.

Это не относится к машине AIX, где рекурсивное разрешение символов (на основе зависимых библиотек) не будет выполнено.

Возможно, это не настоящая проблема, но ее стоит проверить.

Также проверьте, совместим ли sqlite3 с обратной совместимостью (что, я полагаю, является), затем вы можете связать libxul и другие библиотеки с последней версией sqlite3.

Answer 2

Я смотрю на порядок включения.Я тоже потратил целый день или что-то подобное, размышляя о том, почему fseek () потерпел неудачу не непосредственно в Linux, а в Bada и при использовании Eclipse IDE.Подвох заключался в том, что одна и та же функция, имеющая одну и ту же сигнатуру, была экспортирована с помощью некоторого «бета» -процесса .a из Bada SDK.И я случайно импортировал неправильный файл .a.