Сделайте так, чтобы ld игнорировал каталог из /etc/ld.so.conf

Question

TL, DR:

Есть ли способ для меня (без корневого доступа) сделать так, чтобы компоновщик (вызываемый gcc) не знал о содержимом каталога, содержащегося в /etc/ld.so.conf, после того как онбыл кэширован через ldconfig?

Подробно:

Я пытаюсь (и не могу) скомпилировать HTCondor в пользовательском дистрибутиве Linux без доступа root.По разным причинам (см. Ниже) я считаю, что проблемы, с которыми я сталкиваюсь, связаны с тем, что на этом компьютере установлены две версии libssl и две версии libcrypto.Более новая версия (1.0.0) каждого из них расположена на /usr/lib64, а более старая версия (0.9.8) на /usr/local/lib64 по соображениям совместимости./etc/ld.so.conf содержит оба этих пути, поэтому компоновщик знает об обоих.

Во время компиляции я получаю ошибку

../condor_utils/libcondor_utils_8_7_9.so: undefined reference to `ERR_remove_thread_state'

, поскольку по какой-то причине libcondor_utils_8_7_9.so связан с libcrypto.so.0.9.8, а ERR_remove_thread_state была введена в 1.0.0.В исходном коде он встречается ровно один раз:

#if OPENSSL_VERSION_NUMBER < 0x10000000L
    ERR_remove_state( 0 );
#elif OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
    ERR_remove_thread_state( 0 );
#endif

, поэтому препроцессор, похоже, принимает решение на основе версии 1.0.0.

Этот вопрос заставил меня осознатьиз этого сообщения в блоге, поэтому я попытался заменить cpp следующим скриптом:

#!/bin/bash
/usr/bin/gcc -Wl,-rpath-link="/usr/lib64",-rpath="/usr/lib64" "$@"

безрезультатно, к сожалению.

Просто, черт возьмиЯ также попытался прокомментировать директивы препроцессора в приведенном выше фрагменте исходного кода для принудительного выбора ERR_remove_state.Это приводит к тому, что компоновщик предупреждает меня о том, что libssl.so.1.0.0 может конфликтовать с libssl.so.0.9.8 и, что неудивительно, приводит к другой ошибке «неопределенная ссылка».

РЕДАКТИРОВАТЬ:

Проблема оказалась несвязаны с компоновщиком вообще.Смотри мой ответ.Однако из любопытства я оставлю вопрос открытым, чтобы посмотреть, есть ли у кого-нибудь решение для него в его первоначальной формулировке.

Answer 1

Комментарии @ user463035818 и @jww указали мне правильное направление для решения моей конкретной проблемы, которая, как оказалось, не связана напрямую с компоновщиком.

Кондор использует cmake в качестве системы сборки, поэтому очевидно, что этоимеет смысл попытаться решить эту проблему на уровне cmake (здесь n00b).Где-то в глубине всех вещей, которые делает cmake, он находит обе версии библиотек и почему-то смешивает их.Вызов find_library с определенной версией в соответствии с этот ответ в основном CMakeLists.txt решает эту проблему, хотя и оставляет неприятный вкус грязного обходного пути во рту.

Заставить cmake игнорироватьопределенный каталог при поиске библиотек не должен быть сложным, согласно документам .Впрочем, я не пробовал.