Вы смогли войти в систему, а затем это произошло, или это произошло после входа в систему и запуска systemctl isolate graphical.target
команда?
Возможно, лучше всего запустить проверку/восстановление файловой системы из живой среды (liveDVD ). Если вы можете и все еще имеете liveDVD под рукой легко и достаточно быстро сделать, чтобы исключить проблемы с файловой системой.
Ответ, на который вы ссылаетесь, верен. Как говорится,ld
использует кеш для отслеживания установленных библиотек.
Как поясняется в ответе, LD_LIBRARY_PATH
по умолчанию пуст и является лишь частью того, как ld
ищет библиотеки.
LD_LIBRARY_PATH
полезен в таких ситуациях, когда вам нужно переопределить, какую библиотеку ld
выбирает, или если библиотека даже не находится в кеше (, например, если вы разрабатываете общую библиотеку и не установили ее. и обновил кэш ). Кроме того, как уже упоминалось в комментариях, форматирование этой переменной среды имеет значение, и вы должны быть осторожны, чтобы не ввести какие-либо непреднамеренные символы.
Хотя установка по умолчанию не устанавливает LD_LIBRARY_PATH
, вы, возможно, установили его в сценарии запуска оболочки, и в этом случае вы можете либо повторно -получить сценарий (, если вы перезаписываете, а не изменив путь )или просто запустив новую оболочку. Если вы ничего не делаете с переменной по умолчанию, подойдет простой unset LD_LIBRARY_PATH
.
Наконец, нет конфликта между пустым LD_LIBRARY_PATH
и непустым -возвратом из strings /etc/ld.so.cache
.
Вы можете получить (большую часть времени )исходное значение переменной окружения в Linux с помощью:
grep -z ^LD_LIBRARY_PATH= /proc/$$/environ | tr '\0' '\n'
Замените $$
на какой-нибудь другой pid, отличный от оболочки, и LD_LIBRARY_PATH
на какую-нибудь другую переменную среды, если это необходимо.
Процесс мог, конечно, просто перезаписать его; но и ENVVAR=foo
в оболочке, и setenv(3)
в библиотеке C просто выделяют новую строку где-то еще.
В обычной системе LD_LIBRARY_PATH
считается пустым и может устанавливаться только сценариями-оболочками и т.п.