Jak utrzymywać osobny (nowszy) stos glibc / gcc /… jako system inny niż root w systemie Linux

W naszym klastrze obliczeniowym działa bardzo stara wersja CentOS, ze starym jądrem (2.6.18) i, oczywiście, starymi bibliotekami lib i binariami. Ponieważ aktualizacja całości wymaga dużo pracy na wszystkich węzłach, nie jest to opcja.

Próbuję skompilować i użyć programu, który wymaga, C++11a zatem nowszych wersji gcc(i / lub clang). Ponieważ nie chcę w ogóle bawić się z systemem, chcę to zrobić jako użytkownik inny niż root w lokalnym drzewie katalogów.

Problem polega na tym, że gccwymaga nowszej wersji glibcniż ta, która jest obecna na maszynie (maszynach). Dlatego muszę zachować osobną, nowszą wersję glibcw moim lokalnym lib/drzewie, prawdopodobnie tak, jak opisano tutaj .

Gdzie jestem zgubiony, to jak mogę „na sztywno” ścieżkach moich lokalnymi bibliotekami na wszystkie wymagane pliki binarne, to znaczy gcc, g++itd.? Ustawienie LD_LIBRARY_PATH dla mojego lokalnego lib/drzewa powoduje, że wszystkie systemowe pliki binarne przestają działać ( ELF file OS ABI invalid), ponieważ chcą użyć mojego nowego libm.so/, libc.sodla którego nie zostały skompilowane.

Tak więc, aby owinąć go: Co to jest właściwy sposób, aby utrzymać nowszą, lokalny stos rozwoju (zawierający glibc, gccitp) Równolegle do starego systemu bez aprowizacji jako root?

Jako pytanie poboczne: ustawienie LD_LIBRARY_PATH jest publikowane jako rozwiązanie w całej SE, jeśli chodzi o oddzielne glibc. Dla mnie powoduje powyższe błędy, gdy próbuję wykonać dowolny systemowy plik binarny (jak ls). Dlaczego? Czy zrobiłem coś złego, czy jest to zamierzone zachowanie?

Masz w zasadzie trzy opcje:

1. Użyj opakowania wokół bibliotek, które LD_LIBRARY_PATHodpowiednio skonfiguruje, a następnie uruchom żądaną bibliotekę - coś takiego:

   #!/bin/sh
   export LD_LIBRARY_PATH="path/goes/here"
   exec "$@"
   

2. link with -rpath( -Wl,rpath), który dodaje ścieżkę wyszukiwania dynamicznego linkera do pliku binarnego (patrz także odpowiedź SO - wspomina również o opakowaniu).

3. Nie będzie jak czytanie tego jednego: aktualizować swój klaster (nota nacisk na „Twój”). Będzie to musiało być zrobione pewnego dnia, więc dlaczego nie dzisiaj. „Brak opcji” jest w większości przypadków nieco mocny. Inni użytkownicy prawdopodobnie mają te same problemy.

Co do starych problemów z plikami binarnymi - pliki binarne mają swój preferowany dynamiczny linker. Stary dynamiczny linker nie rozumie nowszego ABI. Spróbuj zadzwonić binaria jak to: path/to/your/ld-linux-<arch>.so binary.

Budowanie GCC: zawsze możesz spróbować eksportować CFLAGSw środowisku kompilacji GCC - ale jestem pewien, że zostaną rozpowszechnione. Skrypty kompilacji różnych dystrybucji mogą dać ci pewne wskazówki (np .: dla openSUSE rozejrzyj się po linii 1880 w pliku .spec ).