Linux'ta root olmayan ayrı (yeni) bir glibc / gcc /… yığınını nasıl koruyabilirim?

Hesaplama kümemiz, eski bir Çekirdek (2.6.18) ve tabii ki eski kütüphaneler ve ikili dosyalar ile CentOS'un çok eski bir sürümünü çalıştırır. Her şeyi güncellemek tüm düğümlerde çok fazla çalışma gerektirdiğinden, bu bir seçenek değildir.

Derleme ve (ve / veya ) C++11yeni sürümleri gerektiren ve bu nedenle yeni bir program kullanmaya çalışıyorum . Sistemle uğraşmak istemediğim için, bunu bazı yerel dizin ağacında root olmayan bir kullanıcı olarak yapmak istiyorum.gccclang

Sorun, makinelerde mevcut olandan daha gccyeni bir şey gerektirmesidir glibc. Bu nedenle, muhtemelen burada açıklandığı gibi, glibcyerel lib/ağacımda ayrı, daha yeni bir sürümünü korumam gerekiyor .

Kaybolduğum yerde, yerel kütüphanelerimin gerekli tüm ikili dosyalara, yani gcc, g++vs. yollarını nasıl "sabit kodlayacağım" ? LD_LIBRARY_PATH değerini yerel ağacıma ayarlamak lib/, tüm sistem ikili dosyalarının artık çalışmamasına ( ELF file OS ABI invalid) neden olur çünkü yeni libm.so/ dosyamı libc.soderlenmemiş olanları kullanmak istiyorlar .

Yani, bunu tamamlamayı: yeni, yerel kalkınma yığınını (içeren korumak için doğru yolu nedir glibc, gccroot olarak karıştırmasını olmadan eski sisteme paralel olarak vs.)?

Bir yan soru olarak: LD_LIBRARY_PATH ayarı ayrı olduğunda SE'nin her yerinde bir çözüm olarak yayınlanır glibc. Benim için, herhangi bir sistem ikili (gibi ls) yürütmeye çalıştığınızda yukarıdaki hatalara neden olur . Nasıl olur? Yanlış bir şey mi yaptım yoksa amaçlanan davranış bu mu?

Temel olarak üç seçeneğiniz vardır:

1. Kitaplıklarınızın etrafında, LD_LIBRARY_PATHuygun şekilde ayarlanacak ve daha sonra istenen kitaplığı çalıştıracak bir sarıcı kullanın :

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

2. ikili linke dinamik linker için arama yolu ekleyen -rpath( -Wl,rpath) ile bağlantı ( ayrıca SO cevabına bakınız - ayrıca sarmalayıcıdan da bahseder).

3. Sen bu bir okuma gibi olmaz: güncellemek için küme ( "size" vurgu dikkat edin). Bir gün ya da başka bir gün yapılması gerekecek, neden bugün olmasın. "Seçenek değil" çoğu durumda biraz güçlüdür. Diğer kullanıcılar muhtemelen aynı sorunlara sahiptir.

Sorunları olan eski ikili dosyalara gelince - ikili dosyalarda tercih edilen dinamik bağlayıcı vardır. Ve eski dinamik bağlayıcı daha yeni ABI'yı anlamıyor. Böyle ikilileri aramayı deneyin: path/to/your/ld-linux-<arch>.so binary.

Bina GCC: Her zaman CFLAGSGCC'nin yapı ortamında dışa aktarmayı deneyebilirsiniz - ancak eminim yayılırlar. Çeşitli dağıtımların yapı komut dosyaları size bazı ipuçları verebilir (örneğin: openSUSE için .spec dosyasındaki 1880 satırına bakın ).