Правильный способ связывания статической библиотеки с использованием GCC

Почему некоторые связанные библиотеки (lib *.a) могут быть связаны таким же образом, что и связанные библиотеки (lib *.so) связаны (ld -l switch), но некоторые не могут?

Мне всегда учили, что все библиотеки, статические или нет, могут быть связаны с -l..., однако я уже работал в одной библиотеке (GLFW), которая ничего не делает, кроме spew "undefined reference" свяжите ошибки, если я попытаюсь связать его таким образом.

В соответствии с ответом на этот вопрос, "правильный" способ связывания статических библиотек состоит в том, чтобы включать их непосредственно вместе с моими собственными объектными файлами, а не использовать -l. И, в случае библиотеки GLFW, это, безусловно, решает проблему. Но всякая статическая библиотека, которую я использую, отлично работает при соединении с -l.

Итак:

Что может привести к тому, что эта библиотека не будет работать, если она связана, а не включена напрямую? Если бы я знал причину, возможно, я мог бы редактировать и перекомпилировать библиотеку, чтобы исправить эту проблему.
Правда ли, что вы не должны связывать статические библиотеки так же, как вы связываете общие библиотеки? (А если нет, почему бы и нет?)
Является ли компоновщик все еще способным устранить неиспользуемые библиотечные функции из исполняемого файла, когда библиотека напрямую включена таким образом?

Ответ 1

Спасибо за ответы! Оказывается, проблема связана с порядком привязки. По-видимому, если вы используете библиотеку, которая, в свою очередь, имеет другие зависимости от библиотеки, эти другие зависимости должны быть перечислены после библиотеки, а не раньше, чем я делал. Узнал что-то новое!

Ответ 2

Вам не хотелось указывать GCC путь вашей библиотеки (используя -L)? Используя только -l, GCC сможет связывать библиотеки, доступные только в стандартных каталогах.

-L[path] -l[lib]

Ответ 3

Правильный способ связывания статической библиотеки использует -l, но это работает только в том случае, если библиотеку можно найти на пути поиска. Если это не так, вы можете добавить каталог в список с помощью -L или назвать файл по имени, как вы говорите.

То же самое справедливо и для разделяемых библиотек, хотя, вероятно, их скорее всего найдут.

Ответ 4

Причина историческая. Инструмент "ar" был оригинальным инструментом архивирования файлов на unix PDP11, хотя впоследствии он был полностью заменен "tar" для этой цели. Он хранит файлы (объектные файлы, в данном случае) в пакете. И есть отдельное расширение, содержащее таблицу символов для использования компоновщика. Это возможно, если вы вручную управляете файлами в архиве, чтобы таблица символов могла устареть.

Короткий ответ заключается в том, что вы можете использовать инструмент "ranlib" в любом архиве для воссоздания таблицы символов. Попробуй это. В более широком смысле попытайтесь выяснить, откуда берутся коррумпированные библиотеки и исправить это.