Мне было бы любопытно понять, существуют ли какие-либо существенные различия в определении библиотек (и совместно использованы и статичны) к gcc/g ++ в двух после путей (CC может быть g ++ или gcc),
CC -o output_executable /path/to/my/libstatic.a /path/to/my/libshared.so source1.cpp source2.cpp ... sourceN.cpp
по сравнению с
CC -o output_executable -L/path/to/my/libs -lstatic -lshared source1.cpp source2.cpp ... sourceN.cpp
Я могу только видеть, что существенное различие, что передача непосредственно полностью указанного названия библиотеки сделала бы для большего управления в выборе статических или динамических версий, но я подозреваю, что существует что-то еще продолжающееся, который может иметь побочные эффекты о том, как исполняемый файл создается или будет вести себя во времени выполнения, действительно ли я прав?
Andrea.
Хорошо, я могу ответить себе, основываясь на некоторых экспериментах и более глубоком чтении документации gcc:
Из документации gcc: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
[...] Компоновщик обрабатывает файл архива, сканируя его на предмет элементов, которые определяют символы с таким упоминалось, но не определено. Но если найденный файл является обычным объектным файлом, он связывается обычным образом. Единственное различие между использованием параметра -l и указанием имени файла заключается в том, что -l окружает библиотеку
lib 'и
.a' и выполняет поиск в нескольких каталогах
. Это фактически отвечает также на связанные сомнения по поводу 3-й вариант прямого указания объектных файлов в командной строке gcc (т.е. в этом случае весь код в объектных файлах станет частью окончательного исполняемого файла, а при использовании архивов будут извлечены только действительно необходимые объектные файлы).