Почему порядок, в котором указаны входные библиотеки, имеет значение? - PullRequest
1 голос
/ 03 декабря 2011

Я довольно новичок в программировании для Linux.Можно сказать, что я парень из Windows.Итак, я портировал свой проект на Linux, и это почти свело меня с ума: я уверен, что я указал все зависимости с флагом -l, и все же я получаю ошибки «неразрешенный символ».Затем я нашел эту тему, и она решила мою проблему: Повышение связи в Linux с GCC

Может кто-нибудь объяснить мне, почему порядок имеет значение, и как именно он имеет значение?Я почти уверен, что это не так с компоновщиком MSVC ...

Ответы [ 3 ]

5 голосов
/ 03 декабря 2011

Простой пример позволит вам понять, почему однопроходные линкеры Unix заботятся о порядке.

Предположим, у вас есть main.o (сгенерированный main.cpp) и библиотеки libx.a (без зависимостей) и liby.a (зависит от libx, называемого newRefX) .

Если компоновщик идет в таком порядке, все в порядке, так как компоновщик переходит от 1 к 3:

  1. main.o refX = undef, refY = undef
  2. liby.a refX = undef, refY = def, newRefX = undef
  3. libx.a refX = def, refY = def, newRefX = def

Но если компоновщик идет в таком порядке, вы сталкиваетесь с проблемами с newRefX:

  1. main.o refX = undef, refY = undef
  2. libx.a refX = def, refY = undef,
  3. liby.a refX = def, refY= def, newRefX = undef

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

5 голосов
/ 03 декабря 2011

Из " Введение в GCC - для компиляторов GNU gcc и g ++ "

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

Я полагаю, что компоновщики msvc выполняют 2 прохода по коду, поэтому они могут разрешать символы, даже если библиотеки указаны в другом порядке (ссылка отсутствует ...)

2 голосов
/ 03 декабря 2011

Так работают линкеры Unix, давным-давно ... См. Книга Левина

...