Как я избавляюсь от LD_LIBRARY_PATH во времени выполнения?
Я создаю приложение C++, которое пользуется библиотекой IPP Intel. Эта библиотека установлена по умолчанию в/, выбирают, и требует, чтобы Вы установили LD_LIBRARY_PATH и для компиляции и для выполнения Вашего программного обеспечения (если Вы выбираете общее соединение библиотеки, которое я сделал). Я уже изменил мой configure.ac/Makefile.am так, чтобы я не должен был устанавливать ту переменную при компиляции, но я все еще не могу найти общую библиотеку во времени выполнения; как я делаю это?
Я компилирую с -Wl, -R/path/to/libdir использование флага g++
Обновление 1: На самом деле моя программа в двоичном представлении имеет некоторые библиотеки IPP, правильно связанные, но просто каждый не:
$ ldd myprogram
linux-vdso.so.1 => (0x00007fffa93ff000)
libippacem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippacem64t.so.6.0 (0x00007f22c2fa3000)
libippsem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippsem64t.so.6.0 (0x00007f22c2d20000)
libippcoreem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippcoreem64t.so.6.0 (0x00007f22c2c14000)
[...]
libiomp5.so => not found
libiomp5.so => not found
libiomp5.so => not found
Конечно, библиотека там:
$ locate libiomp5.so
/opt/intel/ipp/6.0.2.076/em64t/sharedlib/libiomp5.so
7 ответов
Как предложил Ричард Пеннингтон, недостающая библиотека не используется непосредственно моим приложением, но используется общими библиотеками, которые я использую. Поскольку я не могу перекомпилировать IPP, решение моей проблемы состоит в добавлении -liomp5 при компиляции с использованием параметра -R для компоновщика. Это фактически добавляет rpath для libiomp5.so, устраняя проблему!
По возможности следует использовать параметр -R.
Если нет, переименуйте исполняемый файл и создайте сценарий запуска, который запускает ваш исполняемый файл, и в нем установите LD_LIBRARY_PATH только для этой области.
В зависимости от платформы, вы можете изменить ld.so.conf через /etc/ld.so.conf.d (на ум приходит Redhat / Fedora), что упрощает развертывание изменений в ld.so из сценария развертывания.
bash:
export LD_LIBRARY_PATH=/path/to/lib
tcsh:
setenv LD_LIBRARY_PATH /path/to/lib
Попробуйте настроить ldconfig через ld.so.conf , чтобы он выполнял поиск в вашем / opt / ... каталог по умолчанию.
Вы можете проверить, подбирается ли путь к библиотеке из вашего флага -R, выполнив команду ldd или readelf на вашем бинарнике. Переменная окружения LD_LIBRARY_PATH является переопределением, поэтому обычно она не нужна.
Под / path / to / lib вы имеете в виду путь к каталогу, содержащему библиотеку, или путь к фактическому файлу?
Параметр -R , заданный аргументом каталога, обрабатывается ld как -rpath , и это тот вариант, который вам действительно нужен. Он добавляет указанный каталог в путь поиска библиотеки времени выполнения. Это должно работать, если вы указываете ему каталог, а не имя файла.Я вполне уверен в этом, поскольку сделал это сам, и потому что это один из советов, данных libtool:
Библиотеки были установлены в:
/ path / to / library-directory
Если вы когда-нибудь если вы хотите связать с установленными библиотеками в данном каталоге LIBDIR, вы должны либо использовать libtool и указать полный путь к библиотеке, либо использовать `-LLIBDIR '{{1 }} во время связывания и выполните хотя бы одно из следующих действий:
- добавить LIBDIR в переменную среды `LD_LIBRARY_PATH ' во время выполнения
- добавить LIBDIR в переменную среды` LD_RUN_PATH' во время компоновки
- используйте флаг компоновщика `-Wl, -rpath -Wl, LIBDIR '
- попросите системного администратора добавить LIBDIR в` /etc/ld.so.conf'
( Я вставляю это здесь, поскольку возможно один из других вариантов может быть более желательным - например, LD_RUN_PATH может сохранить изменения вашего make-файла)
Помимо всех полезных советов, размещенных здесь... вы же не пытаетесь использовать 64-битную специфическую библиотеку на 32-битной системе (или наоборот, в зависимости от других условий)?