Linux dinamik bağlayıcıdan gelen "sürüm bilgisi yok" hatası ne anlama geliyor?

Ürünümüzde, "libpam" gibi sistem kitaplıklarına dinamik olarak bağlanan bazı Linux ikili dosyaları gönderiyoruz. Bazı müşteri sistemlerinde, program çalıştığında stderr'de aşağıdaki hatayı alıyoruz:

./authpam: /lib/libpam.so.0: no version information available (required by authpam)

Uygulama iyi çalışır ve dinamik kitaplıktan kod yürütür. Yani bu ölümcül bir hata değil, gerçekten sadece bir uyarı.

Sistem kurulu kitaplığında yürütülebilir dosyamızın beklediği bir şey eksik olduğunda, bu hatanın dinamik bağlayıcıdan geldiğini anladım. Dinamik bağlantı sürecinin içsel unsurları hakkında pek bir şey bilmiyorum ... ve konuyu araştırmak pek yardımcı olmuyor. :(

Bu hataya neyin sebep olduğunu bilen var mı? ... nedenini nasıl teşhis edebilirim? ... ve bu sorunu önlemek için çalıştırılabilir dosyalarımızı nasıl değiştirebiliriz?

Güncelleme: Müşteri, debian "testinin" en son sürümüne yükseltti ve aynı hata oluştu. Yani güncel olmayan bir libpam kitaplığı değil. Sanırım bağlayıcının neyden şikayet ettiğini anlamak istiyorum? Altta yatan nedeni vb. Nasıl araştırabilirim?

"Sürüm bilgisi yok", kitaplık sürüm numarasının paylaşılan nesnede daha düşük olduğu anlamına gelir. Örneğin, binary'yi oluşturduğunuz makinede major.minor.patch numaranız 7.15.5 ve kurulum makinesinde major.minor.patch numarası 7.12.1 ise, ld uyarıyı yazdıracaktır.

Hedef işletim sisteminizle birlikte gönderilen paylaşılan nesne sürümüyle eşleşen bir kitaplıkla (başlıklar ve paylaşılan nesneler) derleyerek bunu düzeltebilirsiniz. Örneğin, RedHat 3.4.6-9'a kuracaksanız Debian 4.1.1-21'de derlemek istemezsiniz. Bu, çoğu dağıtımın belirli linux dağıtım numaraları için gönderilmesinin nedenlerinden biridir.

Aksi takdirde, statik olarak bağlanabilirsiniz. Ancak, bunu PAM gibi bir şeyle yapmak istemezsiniz, bu nedenle gerçekten müşterinizin üretim ortamına uygun bir geliştirme ortamı kurmak istersiniz (veya en azından kurup doğru kitaplık sürümlerine bağlantı kurarsınız.

.So dosyalarını yeniden adlandırmanız için alacağınız tavsiyeler (bunları sürüm numaralarıyla doldurmak), paylaşılan nesne kitaplıklarının sürümlü semboller kullanmadığı bir zamandan kaynaklanır. Bu nedenle, .so.nnn adlandırma düzeniyle oynamanın yardımcı olacağını beklemeyin (çok - sisteminizin çöpe atılması yardımcı olabilir.)

Son seçeneğiniz, özel bir bağlama komut dosyası kullanarak farklı bir alt sürüm numarasına sahip bir kitaplıkla derleme yapacaksınız: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts. html

Bunu yapmak için, özel bir komut dosyası yazmanız ve müşterinizin paylaşılan nesnelerine karşı özel komut dosyasını kullanarak ld çalıştıran özel bir yükleyiciye ihtiyacınız olacak. Bu, müşterinizin üretim sisteminde gcc veya ld'ye sahip olmasını gerektirir.

Glibc dinamik bağlayıcısından gelen bu mesajın anlamı, bahsedilen kitaplığın ( /lib/libpam.so.0sizin durumunuzda) VERDEFELF bölümüne sahip olmadığı ve ikili dosyanın ( authpamsizin durumunuzda) VERNEEDbu kitaplık için bölümünde bazı sürüm tanımlarına sahip olduğudur (muhtemelen libpam.so.0). İle kolayca görebilirsiniz readelf, sadece .gnu.version_dve .gnu.version_rbölümlerine (veya eksikliklerine) bakın.

İkili aracılığıyla bazı özel sürümü almak istiyorsa, çünkü bir sembol sürüm uyuşmazlığı değil Yani VERNEEDve kütüphane gerçek bunu vermedi VERDEF, o sert bağlayıcı hatası olacağını ve ikili hiç aday olmayacağını gibi ( bu kıyasla bu ya da bu ). İkili programın bazı sürümleri istemesidir, ancak kütüphane sürümleri hakkında herhangi bir bilgi sağlamaz.

Pratikte ne anlama geliyor? Genellikle, bu örnekte tam olarak görüldüğü gibi - hiçbir şey, işler sadece sürüm oluşturmayı göz ardı ederek çalışır. İşler bozulabilir mi? Tabii ki, evet, bu nedenle diğer cevaplar, birinin çalışma zamanında, binary'nin derleme zamanında bağlantılı olduğu kitaplıklarla aynı kitaplıkları kullanması gerektiği konusunda doğrudur.

Ulrich Dreppers "ELF Symbol Versioning" bölümünde daha fazla bilgi bulunabilir .

Fwiw, zenoss izleme sisteminin kurulu olduğu bir sistemde check_nrpe'yi çalıştırırken bu sorunu yaşadım. Karışıklığa ek olarak, root kullanıcısı olarak iyi çalıştı ancak zenoss kullanıcısı olarak işe yaramadı.

Zenoss kullanıcısının zenoss kitaplıklarını kullanmasına neden olan ve bu uyarıları veren bir LD_LIBRARY_PATH'ye sahip olduğunu öğrendim. Yani:

root@monitoring:$ echo $LD_LIBRARY_PATH

su - zenoss
zenoss@monitoring:/root$ echo $LD_LIBRARY_PATH
/usr/local/zenoss/python/lib:/usr/local/zenoss/mysql/lib:/usr/local/zenoss/zenoss/lib:/usr/local/zenoss/common/lib::
zenoss@monitoring:/root$ /usr/lib/nagios/plugins/check_nrpe -H 192.168.61.61 -p 6969 -c check_mq
/usr/lib/nagios/plugins/check_nrpe: /usr/local/zenoss/common/lib/libcrypto.so.0.9.8: no version information available (required by /usr/lib/libssl.so.0.9.8)
(...)
zenoss@monitoring:/root$ LD_LIBRARY_PATH= /usr/lib/nagios/plugins/check_nrpe -H 192.168.61.61 -p 6969 -c check_mq
(...)

Her neyse, söylemeye çalıştığım şey: LD_LIBRARY_PATH, LD_PRELOAD vb. Değişkenlerinizi de kontrol edin.

Uygulamanızı nasıl derliyorsunuz? Hangi derleyici bayrakları?

Deneyimlerime göre, geniş Linux sistemleri alanını hedeflerken, paketlerinizi desteklemek istediğiniz en eski sürümde oluşturun ve daha fazla sistem geriye dönük uyumlu olma eğiliminde olduğundan, uygulamanız çalışmaya devam edecektir. Aslında kitaplık sürümlemesinin tüm nedeni budur - geriye dönük uyumluluk sağlamak.

Gördüğünüz bu zaten? Nedeni, taraflardan birinde, muhtemelen o müşteride çok eski bir libpam gibi görünüyor.

Veya sürüme ilişkin bağlantılar eksik olabilir: http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html