Зачем исправлять неопределенный символ времени выполнения, добавляя / usr / lib в ld.so.conf?

Question

У меня есть случай в Linux, где gcc и ld собирают вещи корректно, но во время выполнения я получаю неопределенный символ (для чего-то в libxerces-c.so.28), сообщаемый одной из моих собственных общих библиотек, когда запустить мою программу.

Сначала предполагалось, что кэш был сломан, недавно установлены xerces или что-то подобное, поэтому я запустил ldconfig. Не исправить это. Но добавление / usr / lib к ld.so.conf и последующий запуск ldconfig это исправили.

Насколько я понимаю, / lib, / usr / lib и, возможно, один или два других места всегда ищутся динамическим компоновщиком во время выполнения.

??

(Единственное, что необычно, - это Java-программа, использующая jni для доступа к разделяемым библиотекам приложения. Опять же, если бы это было что-то рациональное, я бы видел эту ошибку в любое время за последние N лет этого приложения). .)

Answer 1

В данном конкретном случае библиотека находилась в / usr / lib, но также и в другом проекте (и компоновщик сначала нашел этот). И, должно быть, он был плохим / неполным, поскольку в нем явно отсутствовал символ.

Я понял это, запустив мою программу как

LD_DEBUG=libs ./a.out

Это позволило мне посмотреть, как компоновщик копается в разных путях поиска, и я увидел, что он захватил не тот.

О - а явно добавить / usr / lib в конфигурацию ld? Это просто поместило / usr / lib в путь поиска раньше, чем обычно, и (удача?) Заставило ld найти хорошую библиотеку перед плохой.