Linker Sorun: Nasıl bir "/ DEFAULTLIB" nin

Question

'dan geldiğini belirleme Bağlantı zamanında hangi modülün belirli bir kitaplığın "/ DEFAULTLIB" olarak işlenmesini sağladığını belirlemek için iyi bir yol bulmaya çalışıyorum Visual Studio'dan ayrıntılı linker çıktı.

Durumum, bazı statik kitaplık önkoşullarım var ve her birinin bir sürümü ve bir hata ayıklama sürümü (BlahD.lib ve Blah.lib) var. Herhangi bir nedenle bağlantı süresinde * D.lib'ler, "Ek Bağımlılıklar" olarak belirtilen hata ayıklamayan lib'lerle bir sürüm oluşturmama rağmen varsayılan kitaplıklar olarak işlenir. Statik kitaplıkların hata ayıklama sürümlerini hiç oluşturmazsam, bu * D dosyaları olmaz ve bir bağlayıcı hatası olur (dosyayı açamaz).

Tüm bu rahatsız edici .lib dosyaları için/NODEFAULTLIB belirterek projemi başarılı bir şekilde oluşturmaya başlayabilirim. Tüm sürüm kütüphaneleri bağlanır ve herkes mutludur. Ama burada neler olduğunu anlamak istiyorum. Bu * D.lib dosyalarına neden linker tarafından işlenecek? Bu büyük projede ve bağımlı projelerinde (microsoft support) herşeyi dumpbins eden bir tür senaryo yazmamın tek umudum mu? O zaman bile, dumpbin çıktısında neyi arayacağımı anlamıyorum, bu .lib dosyalarının yanı sıra .obj dosyaları için de geçerli midir?

Answer 1

Kaynakta #pragma comment(lib) konusuna bakın. Belki de bir #define'a bağımlı olup olmadığına bakın - Bu, bir SDK'nın doğru lib'lerin bağlandığından emin olmasının yaygın bir yoludur ve mantığın çalışması için THESDK_DEBUG veya THESDK_RELEASE tanımlamanız gerekebilir. Ek bilgiler

: derleyici hala MYLIB.LIB ekleyen

//cpp_quote("#pragma comment(lib, \"MYLIB.lib\")") 

: ben gibi çalışmıyor bile * dosya .Idl gelen açıklama dışında yorum Visual Studio 2008 yılında keşfedilen DEFAULTLIB ve * .obj dosyasında gider. Satırı tamamen koddan çıkardığınızdan emin olun!

Answer 2

Benzer bir sorunla karşılaştım. Ben sadece önerdiğin gibi * .obj dosyalarını analiz ederek çözebiliyordum.

for /R %1 in (*.obj) do @dumpbin /directives /section:.drectve "%1" > "%1".directives.txt 

Sonra adını aramak için Notepad ++ kullandı: Bunu yapmak için, ben (* .obj dosyaları oluşturulur projenin geçici klasöründe) Visual Studio komut istemi ile aşağıdaki komutu ran Bu * .directives.txt dosyalarının hepsinde rahatsız edici kütüphane. Bu, hangi projenin yanlış lib'e başvurduğunu ortaya çıkardı.

Not: Bunu yalnızca * .obj dosyalarını değil, projenizin kullanabileceği tüm 3. taraf * .lib dosyalarını içerecek şekilde değiştirmek isteyebilirsiniz. "/ DEFAULTLIB" direktifleri de bunlardan gelebilir.

Not: * .o yerine * ait /verbose seçeneğiyle obj

Answer 3

Bağlantı kullanmak ve söz konusu kütüphanenin adını çıkışını aramak gerekebilir. Bu, hangi nesne dosyasının kütüphaneyi bağlantıya sürüklediğini söyleyecektir.