Libstdc ++ 'yı statik olarak bağlamak: var mı?

Question 1

GCC 4.7'nin libstdc ++ ile Ubuntu 12.10 üzerine kurulu bir C ++ uygulamasını, oldukça eski bir libstdc ++ sürümüyle birlikte gelen Ubuntu 10.04 çalıştıran sistemlere dağıtmam gerekiyor.

Şu anda, -static-libstdc++ -static-libgccbu blog gönderisinde önerildiği gibi, libstdc ++ ' yı statik olarak bağlama . Yazar, libstdc ++ 'yı statik olarak derlerken dinamik olarak yüklenmiş herhangi bir C ++ kodunu kullanmaya karşı uyarıyor, bu henüz kontrol etmediğim bir şey. Yine de, her şey şu ana kadar sorunsuz gidiyor gibi görünüyor: Ubuntu 10.04'te C ++ 11 özelliklerinden yararlanabiliyorum, ki bu peşindeydim.

Bu makalenin 2005 yılına ait olduğunu ve o zamandan beri belki de çok şey değiştiğini not ediyorum. Tavsiyeleri hala güncel mi? Farkında olmam gereken gizli sorunlar var mı?

Question 2

Bu blog yazısı oldukça yanlış.

Bildiğim kadarıyla C ++ ABI değişiklikleri, GCC'nin her büyük sürümünde (yani farklı birinci veya ikinci sürüm numarası bileşenlerine sahip olanlar) tanıtıldı.

Doğru değil. GCC 3.4'ten bu yana sunulan tek C ++ ABI değişiklikleri geriye dönük uyumludur, yani C ++ ABI yaklaşık dokuz yıldır kararlıdır.

Sorunları daha da kötüleştirmek için, çoğu büyük Linux dağıtımı GCC anlık görüntülerini kullanır ve / veya GCC sürümlerini yamalar, bu da ikili dosyaları dağıtırken hangi GCC sürümleriyle uğraştığınızı tam olarak bilmeyi neredeyse imkansız hale getirir.

Dağıtımların yamalı GCC sürümleri arasındaki farklar küçüktür ve ABI değişmez, örneğin Fedora'nın 4.6.3 20120306 (Red Hat 4.6.3-2) yukarı akış FSF 4.6.x sürümleriyle ABI uyumludur ve neredeyse kesin olarak herhangi bir 4.6 ile uyumludur. diğer dağıtımlardan x.

GNU / Linux'ta GCC'nin çalışma zamanı kitaplıkları ELF sembol versiyonunu kullanır, bu nedenle nesneler ve kütüphaneler için ihtiyaç duyulan sembol versiyonlarını kontrol etmek kolaydır ve eğer libstdc++.sobu sembolleri sağlayan bir şeye sahipseniz çalışır, biraz farklı bir yamalı versiyon olması fark etmez. dağıtımınızın başka bir sürümünden.

ancak C ++ kodu (veya C ++ çalışma zamanı desteğini kullanan herhangi bir kod) işe yarayacaksa dinamik olarak bağlanamaz.

Bu da doğru değil.

Bununla birlikte, statik olarak bağlantı kurmak libstdc++.asizin için bir seçenektir.

Bir kitaplığı dinamik olarak dlopenyüklerseniz (kullanarak ) işe yaramamasının nedeni, bağlı olduğu libstdc ++ sembollerine, onu bağladığınızda (statik olarak) uygulamanız tarafından ihtiyaç duyulmamış olabilir, bu nedenle bu semboller çalıştırılabilir dosyanızda bulunmayacaktır. Bu, paylaşılan kitaplığa dinamik olarak bağlanarak çözülebilir libstdc++.so(bu, buna bağlıysa yine de yapılacak doğru şeydir.) ELF simge enterpozisyonu, çalıştırılabilir dosyanızda bulunan sembollerin paylaşılan kitaplık tarafından kullanılacağı, ancak diğerlerinin kullanılmayacağı anlamına gelir. Yürütülebilir dosyanızda mevcut olan, libstdc++.sobağlantı verdiği her yerde bulunacaktır . Uygulamanız kullanmıyorsa dlopen, bunu önemsemenize gerek yoktur.

Başka bir seçenek (ve benim tercih ettiğim), libstdc++.souygulamanızın yanında yenisini dağıtmak ve varsayılan sistemden önce bulunmasını sağlamaktır; bu, libstdc++.sodinamik bağlayıcıyı doğru yere bakmaya zorlayarak, ya $LD_LIBRARY_PATHçalışma sırasında ortam değişkenini kullanarak yapılabilir . zaman veya RPATHbağlantı zamanında çalıştırılabilir bir dosya ayarlayarak . RPATHUygulamanın çalışması için doğru ayarlanan ortama bağlı olmadığı için kullanmayı tercih ediyorum . Eğer birlikte uygulama bağlantı varsa '-Wl,-rpath,$ORIGIN'(genişletmeye çalışırken kabuk önlemek için tek tırnak not $ORIGINardından yürütülebilir sahip bir olacaktır) RPATHait $ORIGINolan kendisi yürütülebilir aynı dizinde paylaşılan kütüphaneler için görünüm dinamik bağlayıcı söyler. Daha yenisini koyarsanlibstdc++.soçalıştırılabilir dosya ile aynı dizinde, çalışma zamanında bulunacaktır, sorun çözülmüştür. (Diğer bir seçenek olarak yürütülebilir koymaktır /some/path/bin/öylesine. Ve daha yeni libstdc ++ /some/path/lib/ile ve bağlantı '-Wl,-rpath,$ORIGIN/../lib'yürütülebilir için başka bir sabit konum göreli veya ve rpath göre ayarlanır $ORIGIN)

Question 3

Jonathan Wakely'nin mükemmel cevabına bir ekleme, neden dlopen () sorunludur:

GCC 5'teki yeni istisna işleme havuzu nedeniyle ( PR 64535 ve PR 65434'e bakın ), libstdc ++ ile statik olarak bağlantılı bir kitaplığı dlopen ve dlclose ederseniz, her seferinde bir bellek sızıntısı (havuz nesnesi için) alırsınız. Dolayısıyla, dlopen kullanma şansınız varsa, libstdc ++ 'yı statik olarak bağlamak gerçekten kötü bir fikir gibi görünüyor. PR 65434'te belirtilen zararsız olanın aksine bunun gerçek bir sızıntı olduğunu unutmayın .

Question 4

Jonathan Wakely'nin RPATH ile ilgili cevabına bir eklenti:

RPATH yalnızca söz konusu RPATH, çalışan uygulamanın RPATH'si ise çalışacaktır . Kendi RPATH'si aracılığıyla herhangi bir kitaplığa dinamik olarak bağlanan bir kitaplığınız varsa, kitaplığın RPATH'ı, onu yükleyen uygulamanın RPATH'ı tarafından üzerine yazılacaktır. Bu, uygulamanın RPATH değerinin kitaplığınızın RPATH değeriyle aynı olduğunu garanti edemediğinizde, örneğin bağımlılıklarınızın belirli bir dizinde olmasını bekliyorsanız, ancak bu dizin uygulamanın RPATH'sinin bir parçası değilse bir sorundur.

Örneğin, GCC 4.9 için libstdc ++. So.x'e dinamik olarak bağlı bağımlılığı olan bir App.exe uygulamanız olduğunu varsayalım. App.exe, RPATH aracılığıyla bu bağımlılığı çözmüştür, yani

App.exe (RPATH=.:./gcc4_9/libstdc++.so.x)

Şimdi diyelim ki, GCC 5.5 için libstdc ++. So.y'ye dinamik olarak bağlı bağımlılığı olan başka bir Dependency.so kütüphanesi daha var. Buradaki bağımlılık, kütüphanenin RPATH'si aracılığıyla çözülür, yani

Dependency.so (RPATH=.:./gcc5_5/libstdc++.so.y)

App.exe Dependency.so yüklediğinde , kitaplığın RPATH'sini ne ekler ne de önüne ekler . Ona hiç danışmıyor. Dikkate alınan tek RPATH, çalışan uygulamanınki veya bu örnekte App.exe olacaktır. Bu, eğer kütüphane gcc5_5 / libstdc ++. So.y'de bulunan ancak gcc4_9 / libstdc ++. So.x'te olmayan sembollere dayanıyorsa, kütüphane yüklenemeyecek demektir.

Geçmişte bu sorunlarla bizzat kendim karşılaştığım için, bu sadece bir uyarı kelimesi. RPATH çok kullanışlı bir araçtır ancak uygulamasının hala bazı sorunları vardır.

Question 5

Dinamik glibc'ye bağlı olmadığınızdan da emin olmanız gerekebilir. Run lddsonuçta belirlenen çalıştırılabilir ve herhangi bir dinamik bağımlılıkları not (libc / libm / başka libpthread evre usal şüpheliler).

Ek alıştırma, bu metodolojiyi kullanarak bir dizi C ++ 11 örneği oluşturmak ve sonuçta ortaya çıkan ikili dosyaları gerçek bir 10.04 sisteminde denemek olacaktır. Çoğu durumda, dinamik yüklemeyle garip bir şey yapmazsanız, programın çalışıp çalışmadığını hemen anlarsınız.

Question 6

Jonathan Wakely'nin cevabına aşağıdakileri eklemek istiyorum.

-static-libstdc++Linux üzerinde oynarken sorunla karşılaştım dlclose(). Diyelim ki statik olarak bağlantılı bir 'A' uygulamamız var ve çalışma zamanında 'P' eklentisine libstdc++dinamik olarak bağlı libstdc++yükleniyor. Bu iyi. Ancak "A", "P" yi kaldırdığında, segmentasyon hatası oluşur. Benim varsayımıma göre, boşaltma işleminden sonra libstdc++.so, 'A' artık ilgili sembolleri kullanamaz libstdc++. Hem 'A' hem de 'P' statik olarak libstdc++bağlıysa veya 'A' dinamik ve 'P' statik olarak bağlantılıysa, sorunun oluşmayacağını unutmayın.

Özet: Uygulamanız dinamik libstdc++olarak bağlanabilecek eklentileri yüklüyor / kaldırıyorsa , uygulamanın da ona dinamik olarak bağlanması gerekir. Bu sadece benim gözlemim ve yorumlarınızı almak istiyorum.