Я видел это много, некоторые из наших модулей связывают более 100 библиотек нашего кода плюс система & amp; Сторонние библиотеки.

В зависимости от разных компоновщиков HP / Intel / GCC / SUN / SGI / IBM / etc вы можете получить нерешенные функции / переменные и т. д., на некоторых платформах вам нужно дважды перечислить библиотеки.

По большей части мы используем структурированную иерархию библиотек, ядро, платформу, разные уровни абстракции, но для некоторых систем вам все равно придется играть с порядком в команде link.

Как только вы нажмете на документ решения, чтобы следующий разработчик не смог его снова обработать.

Мой старый лектор говорил: « высокая степень сцепления и низкая связь », это по-прежнему актуально и сегодня.

Порядок ссылок определенно имеет значение, по крайней мере на некоторых платформах. Я видел сбои для приложений, связанных с библиотеками в неправильном порядке (где неправильные средства A связаны до B, но B зависит от A).

Другой альтернативой было бы указать список библиотек дважды:

gcc prog.o libA.a libB.a libA.a libB.a -o prog.x

Выполняя это, вам не нужно беспокоиться о правильной последовательности, так как эта ссылка будет разрешена во втором блоке.

Вот пример, чтобы прояснить, как все работает с GCC при использовании статических библиотек. Итак, предположим, что мы имеем следующий сценарий:

• myprog.o - содержащий функцию main(), зависящую от libmysqlclient
• libmysqlclient - статично, ради примера (вы предпочтете разделяемую библиотеку, конечно, поскольку libmysqlclient огромен); в /usr/local/lib; и зависит от материала из libz
• libz (dynamic)

Как мы это связываем? (Примечание: примеры компиляции на Cygwin с использованием gcc 4.3.4)

gcc -L/usr/local/lib -lmysqlclient myprog.o
# undefined reference to `_mysql_init'
# myprog depends on libmysqlclient
# so myprog has to come earlier on the command line

gcc myprog.o -L/usr/local/lib -lmysqlclient
# undefined reference to `_uncompress'
# we have to link with libz, too

gcc myprog.o -lz -L/usr/local/lib -lmysqlclient
# undefined reference to `_uncompress'
# libz is needed by libmysqlclient
# so it has to appear *after* it on the command line

gcc myprog.o -L/usr/local/lib -lmysqlclient -lz
# this works

Быстрый совет, который меня опрокинул: если вы ссылаетесь на компоновщик как «gcc» или «g ++», то использование «--start-group» и «--end-group» не будет передавать эти параметры до линкера - и не будет отмечена ошибка.

Вам нужно записать их как «-Wl, - start-group» и т. Д., Чтобы сообщить GCC передать аргумент через к компоновщику.

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

Общие файлы, общие для всех команд ниже

$ cat a.cpp
extern int a;
int main() {
  return a;
}

$ cat b.cpp
extern int b;
int a = b;

$ cat d.cpp
int b;

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

$ g++ -c b.cpp -o b.o
$ ar cr libb.a b.o
$ g++ -c d.cpp -o d.o
$ ar cr libd.a d.o

$ g++ -L. -ld -lb a.cpp # wrong order
$ g++ -L. -lb -ld a.cpp # wrong order
$ g++ a.cpp -L. -ld -lb # wrong order
$ g++ a.cpp -L. -lb -ld # right order

Компонент выполняет поиск слева направо и отмечает неразрешенные символы. Если библиотека разрешает символ, он принимает объектные файлы этой библиотеки для разрешения символа (b.o из libb.a в этом случае).

Зависимости статических библиотек друг от друга работают одинаково - библиотека, которая нуждается в символах, должна быть первой, а затем библиотекой, которая разрешает символ.

Если статическая библиотека зависит от другой библиотеки , но другая библиотека снова зависит от прежней библиотеки, есть цикл. Вы можете разрешить это, включив циклически зависимые библиотеки с помощью -( и -), например -( -la -lb -) (вам может понадобиться избежать появления парсеров, таких как -\( и -\)). Затем компоновщик выполняет поиск вложенных библиотек несколько раз, чтобы гарантировать, что зависания на велосипеде разрешены. Кроме того, вы можете указывать библиотеки несколько раз, поэтому каждый из них находится друг перед другом: -la -lb -la.

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

$ export LD_LIBRARY_PATH=. # not needed if libs go to /usr/lib etc
$ g++ -fpic -shared d.cpp -o libd.so
$ g++ -fpic -shared b.cpp -L. -ld -o libb.so # specifies its dependency!

$ g++ -L. -lb a.cpp # wrong order (works on some distributions)
$ g++ -Wl,--as-needed -L. -lb a.cpp # wrong order
$ g++ -Wl,--as-needed a.cpp -L. -lb # right order

Здесь то же самое - библиотеки должны следуйте объектным файлам программы. Разница здесь в статических библиотеках заключается в том, что вы не должны заботиться о зависимостях библиотек друг от друга, потому что динамические библиотеки сами сортируют свои зависимости .

Некоторые недавние дистрибутивы, по-видимому, по умолчанию используют флаг компоновщика --as-needed, который обеспечивает, чтобы объектные файлы программы приходили перед динамическими библиотеками. Если этот флаг передан, компоновщик не будет ссылаться на библиотеки, которые фактически не нужны исполняемому файлу (и он обнаруживает это слева направо). Мой недавний дистрибутив archlinux по умолчанию не использует этот флаг, поэтому он не дал ошибку, чтобы не следовать правильному порядку.

Неправильно пропустить зависимость b.so от d.so при создании первого. При связывании a вам потребуется указать библиотеку, но a действительно не нуждается в самом целочисленном b, поэтому не следует заботиться о собственных зависимостях b.

Вот пример последствий, если вы пропустили определение зависимостей для libb.so

$ export LD_LIBRARY_PATH=. # not needed if libs go to /usr/lib etc
$ g++ -fpic -shared d.cpp -o libd.so
$ g++ -fpic -shared b.cpp -o libb.so # wrong (but links)

$ g++ -L. -lb a.cpp # wrong, as above
$ g++ -Wl,--as-needed -L. -lb a.cpp # wrong, as above
$ g++ a.cpp -L. -lb # wrong, missing libd.so
$ g++ a.cpp -L. -ld -lb # wrong order (works on some distributions)
$ g++ -Wl,--as-needed a.cpp -L. -ld -lb # wrong order (like static libs)
$ g++ -Wl,--as-needed a.cpp -L. -lb -ld # "right"

. Если теперь вы посмотрите на зависимости, которые имеет двоичный файл, вы заметите сам бинарный файл зависит также от libd, а не только от libb. Бинарный файл нужно будет перемотать, если позже libb зависит от другой библиотеки, если вы сделаете это так. И если кто-то загружает libb, используя dlopen во время выполнения (подумайте о загрузке плагинов динамически), вызов также не удастся. Поэтому "right" действительно должен быть wrong.