Как компоновщик выбирает динамическую библиотеку среди компилируемых с разными компиляторами
У меня есть проект на C ++, который в настоящее время не связан с какой-либо внешней динамической библиотекой. Я подумываю об использовании некоторых библиотек наддува в будущем, которые должны быть собраны (не только для заголовков). На данный момент, на стадии разработки, я строю свой проект с тремя различными цепями инструментов: g++, LLVM/Clang++ а также Intel C++Платформа Linux, Эти компиляторы, AFAIK, двоично совместимы друг с другом, например, g ++ — скомпилированное приложение может использовать Intel C ++ — скомпилированную динамическую библиотеку.
Я собрал бинарные бусты и установил их в разные папки. например build_gcc, build_icc, Затем я добавил пути к этим папкам в системе LIBRARY_PATH, Вопрос в том, смогу ли я сейчас построить свой проект с g++ или же Intel C++ и связать некоторую динамическую библиотеку, например записывать
-lboost_math_tr1
в makefileКак компоновщик решает, с каким именно библиотечным файлом ссылаться, если двоичные файлы разных компиляторов совместимы друг с другом?
Мотивация вопроса проста: Intel C++ оптимизирующий компилятор, поэтому, если я собираю что-то с его помощью, я ожидаю, что они будут связаны с динамической библиотекой, скомпилированной с Intel C++ компилятор, а не тот, который скомпилирован с g++, Конечно, я знаю, что могу просто использовать несколько условных выражений в makefile установить точные каталоги с библиотеками для каждой используемой цепочки инструментов, но это немного неудобно. Я странствую, достаточно ли умен компоновщик, чтобы распознать, какой именно файл общей библиотеки он должен использовать, или он просто использует первое вхождение, найденное в системе LIBRARY_PATH?
Решение
компоновщик не будет знать. если первая найденная библиотека несовместима, она даже выручит, вместо того, чтобы искать все библиотеки, пока не найдет совместимую.
подтвердить что-то вроде:
$ cat foo.c
int main() {
return 0;
}
$ mkdir bar
$ touch bar/libm.so
$ gcc foo.c -o foo -Lbar -lm
/usr/bin/ld: error: b/libm.so: file is empty
collect2: error: ld returned 1 exit status
Ото, красота динамического связывания заключается в том, что он способен обменивать Dlib с лучшим без необходимости перекомпиляции.
так что вы можете ссылаться на версию g ++, но если производительность низкая, установите версию icc на целевом хосте (в месте, которое будет искать до версии g ++), и ваше приложение волшебным образом будет использовать ее (пока они совместимый).
Вы также можете использовать LD_LIBRARY_PATH переменная для поиска библиотек в нестандартном месте при запуске приложения:
LD_LIBRARY_PATH=/path/to/super/libs/ ./app-dylinked-with-generic-libs
Другие решения
Переменная среды PATH используется для поиска исполняемых файлов, а не для поиска библиотек. Каждый компилятор имеет набор стандартных мест, в которых он ищет библиотеки, плюс места, которые явно указаны с помощью -L. Это не будет заботиться о том, какой компилятор создал библиотеку.
Вам нужно добавить эти библиотеки в $LIBRARY_PATH (связывание) и $LD_LIBRARY_PATH (время выполнения) не $PATH, Я чувствую, что вы можете установить эти переменные в вашем Makefile по одному, чтобы решить, с каким двоичным файлом связать.
detector