Наш вычислительный кластер работает с очень старой версией CentOS со старым ядром (2.6.18) и, конечно, старыми библиотеками и двоичными файлами. Поскольку обновление всего этого требует много работы на всех узлах, это не вариант.
Я пытаюсь скомпилировать и использовать программу, которая требует C++11
и, следовательно, более новые версии gcc
(и / или clang
). Поскольку я вообще не хочу возиться с системой, я хочу сделать это как пользователь без полномочий root в некотором локальном дереве каталогов.
Проблема в том, что gcc
требуется более новый, glibc
чем тот, который присутствует на машине (ах). Следовательно, мне нужно сохранить отдельную, более новую версию glibc
в моем локальном lib/
дереве, вероятно, как описано здесь .
Где я потерял это, как я «жёстко» дорожки моей местной LIBS во все необходимых двоичных файлах, то есть gcc
, и g++
т.д.? Установка LD_LIBRARY_PATH в моё локальное lib/
дерево заставляет все системные двоичные файлы больше не работать ( ELF file OS ABI invalid
), потому что они хотят использовать мои новые libm.so
/, для libc.so
которых они не были скомпилированы.
Итак, подведем итоги: как правильно поддерживать новый локальный стек разработки (содержащий glibc
и gcc
т. Д.) Параллельно старой системе, не возиться с правами root?
В качестве дополнительного вопроса: настройка LD_LIBRARY_PATH публикуется как решение по всей SE, когда дело доходит до разделения glibc
. Для меня это вызывает ошибки выше, когда я пытаюсь выполнить любой двоичный файл системы (например ls
). Как так? Я сделал что-то не так или это намеченное поведение?