2010-07-08 2 views
5

Quando si collega il mio dll nella build di rilascio ottengo -VC++/DEFAULTLIB problema

1> LINK: LNK4098 avvertimento: defaultlib conflitti 'mfc80d.lib' con utilizzo di altre librerie; uso/NODEFAULTLIB: biblioteca

1> LINK: LNK4098 avvertimento: defaultlib conflitti 'mfcs80d.lib' con utilizzo di altre librerie; uso/NODEFAULTLIB: biblioteca

1> LINK: LNK4098 avvertimento: defaultlib conflitti 'MSVCRTD.LIB' con utilizzo di altre librerie; uso/NODEFAULTLIB: biblioteca

aggiungendo/verbose, vedo il seguente (snippet): ...

1> Ricerca D: \ Microsoft Visual Studio 8 \ VC \ atlmfc \ lib \ mfc80d.lib:

1> Trovato "pubblica: __thiscall virtuale AFX_MODULE_STATE :: ~ AFX_MODULE_STATE (void)" (?? 1AFX_MODULE_STATE @@ UAE @ XZ) 1>
Citato in mfcs80.lib (dllmodul obj) 1> Loaded mfc80d.lib (MFC80D.DLL)

1> Trovato "lungo stdcall AfxWndProc (struct HWND__ *, unsigned int , unsigned int, long)" (? AfxWndProc @@ YGJPAUHWND __ @@ IIJ @ Z)

1> Citato in mfcs80.lib (dllmodul.obj) 1> Loaded mfc80d.lib (MFC80D.DLL)

...

Se sto interpretando correttamente, significa che il linker risolve in qualche modo le chiamate dalla libreria (ottimizzata) mfcs80, come chiamate nella libreria (non ottimizzata) mfc80D. Come può essere ??

Quando aggiungo /NODEFAULTLIB:mfc80d.lib gli avvisi sono spariti, ma non sono ancora tranquillo. Per inciso, il modulo in effetti soffre di sporadici crash inesplicabili sui collegamenti incrementali, che vengono risolti solo da una ricostruzione. Sto usando VS2005.

[Modifica:] Modificato il titolo per includere DEFAULTLIB, con la speranza di focalizzare meglio l'argomento. Io faccio vedere una linea esplicita dicendo

elaborati /DEFAULTLIB:mfc80d.lib

nell'output/verbose, tra molti altri movimenti di liberazione (non di debug) di default. Da dove proviene? come posso risolvere questo?

Grazie!

risposta

2

Il problema è stato risolto molto più tardi - lo invio qui nel caso in cui aiuti qualcuno un giorno.

Si è rivelato essere un percorso di intestazione precompilata errato: la configurazione di rilascio ha indicato il percorso PCH di debug predefinito. Quindi, durante la transizione da debug a release, una build dovrebbe trascinare in tutti i contenuti di debug PCH - apparentemente includendo alcune versioni di debug di MFC#pragma (commenta "lib ..") (incluso nelle intestazioni afx). Una compilazione pulita ricostruirà correttamente il PCH, ma di nuovo nella cartella di debug, causando quindi problemi identici nella transizione al debug build.

2

Controllare le impostazioni della libreria di runtime per i progetti, sembra che si sia verificato un disallineamento.Nelle impostazioni di progetto in C/C++> Generazione codice> Libreria di runtime, avete le scelte:

  • Multi-Threaded
  • Multi-Threaded debug
  • Multi-Threaded DLL
  • Debug Multi-Threaded DLL

Sembra che alcuni dei progetti nella soluzione possano utilizzare una versione di debug mentre altri utilizzano la versione non debug. In alternativa, alcuni progetti potrebbero utilizzare la versione di debug mentre altri utilizzano la versione di debug della DLL. Per una determinata configurazione della soluzione, si desidera che tutti i progetti utilizzino la stessa impostazione.

+0

Grazie - ma ho controllato tutti i progetti (e tutti i singoli file), e sono tutti compilati con/MD. Ho pochissime dipendenze esterne: version.dll, shlwapi.dll e un componente di terze parti che ho ispezionato con dependency-walker e sembra collegarsi con le versioni CRT appropriate (non-debug). L'interruttore/MD è infatti l'unico accesso all'interruttore/DEFAULTLIB? Non c'è un altro input che potrebbe averlo incasinato? –

0

Significa che una delle dll dipendenti è compilata con un diverso run-time library.

Progetto -> Proprietà -> C/C++ -> Codice generaion -> Runtime Library

Vai su tutte le librerie e vedere che sono compilati nello stesso modo.

di più su questo errore in questo link:

warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs

+0

Come ho commentato la risposta @bshields (identica), l'ho verificata prima di postare qui. Vedi la mia risposta (~ 1 anno dopo) per l'eventuale fonte di problemi. –