C statik kütüphaneleri kaşlarını çattı mı? [kapalı]

Paylaşılan kitaplıklara sahip olmanın 2 argümanı vardır:

1. Disk alanının azaltılmasına yardımcı olur.
2. Paylaşılan bir kitaplık güncellendiğinde, ona bağlı olan tüm ikili dosyalar güncelleştirmeyi alır.

Paylaşılan kitaplıklar için temel olarak bir dezavantaj vardır:

• Bağımlılık cehennemi getirebilirler.

Masaüstü bilgisayarlarda, ilk avantaj artık geçerli değildir. Disk alanını boşa harcamak bu günlerde pek sorun değil.

Statik ikili dosyalara sahip olmak daha iyi paket yöneticileri elde etmemizi sağlayacaktır - yani bağımlılık cehennemi geçmişte kaldı. Bir program eklemek sadece bir ikili dosya eklemek olacaktır; nihayetinde dosyalarını işlemesine izin veren bir klasör. Bir programı silmek, bu dosyayı silmek olacaktır. Bağımlılıklar? Gone.

İkinci avantaj hala duruyor, ancak masaüstü bilgisayarlardaki statik ikili programların avantajından daha ağır basıyor. Yani, Go gibi yeni diller bile, kolaylık nedeniyle paylaşılan kütüphanelerin avantajlarına rağmen tüm ikili dosyalarını derler.

Paylaşılan kütüphanelerin ana avantajlarından biri artık büyük bir şey olmadığından, C statik kütüphaneleri hala kaşlarını çattı mı? Öyleyse neden?

Sorunuzun temeli kusurlu. Üzerinde kaşlarını çatmış olan şey, onların arkasındaki temeli anlamadan doktrinerlere ve mutlaklara bağlı kalmaktır (Cargo Cult Programming?).

Bağlantılı SO yanıtı , bu konuda ilginç bir çalışma- Soru, -static seçeneği ile bir derlemenin neden çalışmadığıyla ilgiliydi, bağlandığınız yanıt statik bağlantı kullanmama konusundan başka bir şey değildi. Neden kötü olduğunu tartışmaz ve OP dinamik bağlantı kullanır talep. Onun talihsizliği doğru cevap olarak işaretlenmiştir (aşağıdaki cevap iki kat daha fazla oy içerir ve OP'nin sorusuna doğru cevaptır) çünkü doğru cevap orada olmasına rağmen, dogmatik bir görüş arasında derinden gizlenmiştir.

Asıl soru, statik vs dinamik bağlamanın artıları ve eksileri nelerdir ve ne zaman diğerine tercih edilir.

Bir geliştirici bakış açısından, dinamik bağlantı genellikle derleme / bağlantı / test döngünüzü önemli ölçüde hızlandırabilir.

Paket yönetimi açısından, örneğin libGL'yi ele alalım. Paket yöneticimde yaklaşık bir düzine farklı uygulama var, bazıları genel ve bazıları da belirli grafik kartlarını hedefliyor. Dinamik olarak bağlı olmasaydı, libGL ile bağlantı kuran her programın bir düzine versiyonunun olması gerekirdi, yoksa bir işlev çağrısı kadar verimli olmayan ek bir soyutlama katmanı tasarlamanız gerekirdi.

Qt gibi popüler bir kütüphanede bir güvenlik sorunu düşünün. Dinamik bağlantı ile, Qt ile bağlantı kuran her paketi tanımlamak, yeniden derlemek ve dağıtmak yerine bu paketi güncelleyebilirim.

Statik bağlamanın bağımsız olarak kurulan kapalı kaynak uygulamalarında avantajları olabilir, ancak açık kaynak paket yönetiminde yardımcı olduğundan daha fazla acıyor.

Paylaşılan kütüphaneler temelde 2. nedenden ötürü Linux dağıtım sahipleri tarafından şiddetle tercih edilir . Örneğin, birisi zlib'de bir güvenlik hatası bulduğunda , zlib kullanan programların her birini yeniden derlemek zorunda olmamaları gerçekten önemlidir - sadece onlara daha fazla CPU döngüsüne mal olmakla kalmaz. yeniden derlerken, dağıtımı kullanan herkesin tüm bu programları yeniden indirmesi gerekir . Bu arada, bir dağıtım tarafından sağlanan paketler kümesinde, bağımlılık cehennemi bir sorun değildir, çünkü her şey bu kütüphane kümesiyle çalışacak şekilde test edilir.

Dağıtımınızda olmayan kütüphanelere ihtiyaç duyan üçüncü taraf yazılımlar oluşturuyorsanız, bu kütüphaneleri statik olarak bağlamak alternatiften daha az güç olabilir ve bu iyi.

Bilmeniz gereken diğer önemli şey, GNU libcve GCC'lerin libstdc++her ikisinin de kütüphane statik olarak bağlıysa güvenilir çalışmayan bileşenlere sahip olmasıdır. En yaygın sorun dlopen, çünkü yüklediğiniz modülün dlopenkendisi dinamik olarak bağlantılıdır libc.so.6. Bu, artık adres alanınızda C kütüphanesinin iki kopyasına sahip olduğunuz anlamına gelir ve iç mallocveri yapısının (örneğin) hangi kopyasının yetkili olduğunu kabul etmediklerinde komiklik sağlanır . Bu da kötüleşiyor: görünmüyor fonksiyonları bir sürü ile ilgisi var dlopengibi gethostbynameve iconv, kullanımdlopendahili olarak (davranışlarının çalışma zamanı tarafından yapılandırılabilmesi için). Neyse ki, libc ve libstdc ++ için ABI çok kararlıdır, bu nedenle dinamik olarak bunları bağlayan sorunlarla karşılaşmanız olası değildir.

Mattnz'in son noktasına katılıyorum: bu soru yüklü bir soru. Statik bağlamanın kötü olduğunu varsayar. Bunun neden böyle olmadığının iki sebebini düşünebilirim:

• Statik bağlantı güvenlidir: paylaşılan bir kitaplık, bir uygulama yenisini kullanacak şekilde güncelleştirilirse (belki yeni, eskisinin üzerine yazılır veya eski kitap kaldırılır), yeni sürümün uygulamayı bozma riski oluşturabilir. Bu, uygulama için resmi bir güncelleme kapsamı dışında yapılan bir kod değişikliğidir. Test edilmemiş olabilir. Statik bağlantı, kütüphaneleri harici olarak paylaşmayarak bunu engeller. Bu risk nedeniyle bu paylaşılan kütüphaneler için bir dezavantaj olduğunu düşünüyorum. Paylaşılan bir kütüphanenin yeni bir sürümü belirli eski uygulamaları bozan yeni bir hata getirirse ne olur?

• Statik bağlantı bir uygulamanın daha bağımsız olmasını sağlar. Paylaşılan kitaplıklar birincil yürütülebilir dosya ile birlikte konumlandırılabilse de, genellikle paylaşılan konumlarda depolanırlar. Statik bağlantılı uygulamaların "işletim sistemi tarafından sahip olunan dosyalarda, dizinlerde veya ayarlarda değişiklik gerektirmemesi" anlamında "taşınabilir" olmasını sağlamak daha kolaydır (Windows dizini, kayıt defteri, vb.).

Statik ve dinamik kütüphanelerin her birinin kendi kullanımları vardır. Kapsamdaki tek bir uygulamaya baktığımızda, neyin gerekli ve neyin olmadığı hakkında farklı bir fikir ediniriz.

Statik bağlantı, uygulama dağıtımını büyük ölçüde basitleştirir. Farklı sürümleri tespit etmek ve bunlarla uğraşmak zorunda kalmamak. Sadece pişirin ve konuşlandırın.

Dinamik kütüphanelerle bariz avantaj, güncellemeleri bağımsız olarak uygulama yeteneğidir.

Javen ve diğer benzer dinamik bağlantı proje oluşturucularını java için nefret etmemin nedenlerinden biri budur. Belirli bir url'de sonsuza dek ve her zaman tek bir kütüphane sürümünün mevcut olmasını beklerler. Tüm kaynak ve kavanozlar gittiğinden, kimsenin uygulamayı derleyemediği 10 yıl içinde meydana gelen problemi anlamamak.