Compatibilità * .dll * .a * lib * .def tra VisualStudio e gcc

Question

questo è molto confusa. Ho passato molto tempo a leggere post su questo in pila, ecc. Ancora confusi.

Sto usando Qt e C++ per la codifica. In Qt, sto usando l'opzione gcc per un compilatore.
Il problema è che molte librerie di terze parti che ho provato non sembrano funzionare.

Sono nuovo a file .dll, .a, .lib, .def e schemi di libreria.

Domanda 1:

Nella mia limitata esperienza (ho provato 7 o 9 librerie finora), i fornitori di biblioteche raramente ti dicono se la DLL è stata fatta con VisualStudio o gcc. Ciò aggiunge molta confusione. Non rendono quasi mai chiaro a quale compilatore la libreria è compatibile. Quindi apprezzerei alcuni consigli di vita reale su come affrontare questo incubo. Quasi tutte le librerie che ho provato sono progetti OpenSource. Non chiamerò i nomi qui, ma questi sono progetti ben noti. Sono sicuro che il problema è la mia mancanza di conoscenza ...

MinGW e gcc mondo

Question2:
Per quanto posso dire, dinamico C++ librerie per MinGW gcc universo richiedono questi, giusto ?
* .h
* .dll
* .a

Domanda 3:
Purtroppo, il file .a è spesso manca e la biblioteca non funziona. Questo è molto confuso. Se manca il file .a, sono sfortunato?

Domanda 4:
Posso generare il file .a per MinGW/GCC se la * .dll è stata fatta con gcc?

Domanda 5: Posso generare il file .a per MinGW/gcc se il file * .dll è stato creato con VisualStudio?

Domanda 6:
È possibile che un * .dll (realizzato con MinGW/gcc) sia troppo vecchio e non più compatibile con MinGW/gcc più recenti?

Domanda 7:
I progetti Qt che utilizzano MinGW/gcc non necessitano mai di file * .lib, giusto? Questa è solo una cosa di VisualStudio, giusto?

Domanda 8:
Non ho bisogno di un file * .def per usare un file * .dll in un progetto Qt usando MinGW/gcc, giusto?

VisualStudio mondo

Domanda 9:
Per quanto posso dire, dinamico C++ librerie per VisualStudio richiedono questi:
* .h
* .dll
* .lib

Giusto? Ancora, il problema è che il file * .lib è quasi sempre mancante. Inoltre, nessuna chiara istruzione su quale compilatore è compatibile con la libreria. Quindi, come posso sapere che è solo per VisualStudio o no?

Domanda 10:
Se il file .lib è mancante, sono sfortunato?

Domanda 11:
È possibile generare il file .lib per VisualStudio se * .dll è stato creato con VisualStudio? Come?

Domanda 12:
Posso generare il file .lib per VisualStudio se * .dll è stato creato con MinGW/gcc? Come?

Domanda 13:
È possibile che un * .dll (realizzato con VisualStudio) sia troppo vecchio e non sia più compatibile con VisualStudio più recente?

Domanda 14:
Se in QtCreator seleziono il compilatore VisualStudio, è compatibile al 100% con le librerie dinamiche compilate con REAL VisualStudio da qualcun altro? Credo che l'opzione del compilatore VisualStudio in Qt Creator sia un compilatore falso di VisualStudio.

Domanda 15:
Se in QtCreator seleziono il compilatore MinGW/gcc, posso utilizzare le librerie dinamiche Qt compilate con REAL VisualStudio da qualcun altro?

Domanda 16:
Non ho bisogno di un file * .def per utilizzare un file * .dll in un progetto Qt utilizzando MinGW/gcc, giusto?

Domanda 17: Posso convertire un * lib (che funziona con un file * .dll e * .h) fatto con REAL VisualStudio in un file * .a in modo da poter usare il file * .a con il non modificato * .dll e * .h file in un progetto gt Qt?

Answer 1

Una DLL è essenzialmente un'applicazione compilata, solo sotto forma di una libreria di funzioni anziché di un file EXE. Qualsiasi altra applicazione può utilizzare le funzioni all'interno di quella DLL semplicemente dichiarando la funzione, la dll contenente la funzione, i parametri e i valori restituiti e così via.

Le DLL devono già esistere su un sistema se un'applicazione viene compilata utilizzando "librerie collegate dinamicamente", quindi è necessario includere le DLL necessarie nel proprio programma di installazione o sperare che siano già presenti nel computer di destinazione. L'uso delle DLL rende le dimensioni della tua app più piccole in generale.

Creare le DLL è come creare qualsiasi altra applicazione: è sufficiente indirizzare la build come DLL anziché come EXE o altro.

Per creare qualsiasi applicazione (DLL, EXE o altro), è necessario il codice sorgente e le intestazioni necessarie. .h file contengono dichiarazioni per funzioni e tipi di dati e classi e quant'altro - raramente contengono codice. A .def è molto simile a un .h, ma di solito un insieme di istruzioni per un linker.

Quando si compila, un file .h o .c o qualsiasi cosa si trasforma in un oggetto .obj, un file oggetto. Più file oggetto sono collegati tra loro per creare la tua DLL o EXE.

Un file .lib è una libreria statica, essenzialmente un gruppo di file .obj (o un file .obj) che sono stati combinati per la fase di collegamento.

Il formato dei file .obj e .lib può essere specifico per un compilatore e raramente sono compatibili tra i compilatori. Devi avere il codice sorgente originale o un .obj o .lib creato appositamente per il tuo compilatore.

Quando si sceglie di creare un EXE con "librerie collegate dinamicamente", sarà in attesa di DLL che può utilizzare. Quando scegli "librerie collegate staticamente", il linker localizzerà i file .lib di cui ha bisogno prima di produrre l'EXE, e non avrai bisogno di quelle DLL.

Answer 2

Forse vale la pena iniziare all'inizio e non saltare davanti a noi stessi e descrivere il problema principale. Da questa risposta a molte delle domande possono essere derivate.

L'avvio è l'ABI (interfaccia binaria dell'applicazione). Definisce cose come

• come viene chiamata una funzione, ad es. quali parametri vanno inseriti in quali registri o quale posizione sulla pila hanno inserito
• come vengono generate le eccezioni
• come vengono disposti gli oggetti, ad es. dove il "puntatore vtable" va, cosa imbottitura è utilizzato
• quanto grande sia il build-in tipi di dati sono
• come i nomi delle funzioni sono "straziati" in simboli
• come le informazioni di tipo è spiegate
• la il layout delle classi della libreria standard
• ecc

maggior parte delle piattaforme definire un C ABI ma non definiscono un C++ ABI. Di conseguenza il compilatore definisce il proprio ABI (per tutto tranne la roba C che di solito è lì). Questo produce file oggetto che sono incompatibili tra diversi compilatori (a volte anche tra versioni dello stesso compilatore).

In genere, questo si manifesta in nomi dall'aspetto strano in qualche modo indefiniti: diversi ABI utilizzano deliberatamente un diverso nome per manomissione per impedire accidentalmente il collegamento di un eseguibile che non funzionerà comunque. Per risolvere il problema, la soluzione migliore è creare tutti i componenti utilizzando lo stesso compilatore.

Se si desidera determinare con quale compilatore viene costruita una libreria, è possibile dare un'occhiata ai relativi contenuti utilizzando gli strumenti appropriati. Mi rendo conto che hai chiesto per Windows, ma so solo gli strumenti UNIX (che possono essere disponibili con MinGW):

• nm a guardare i nomi dei simboli (in genere insieme con meno o grep)
• ar per costruire o ispezionare le librerie
• ident per trovare stringhe speciali incorporate nell'oggetto
• stringhe per appassionati tutte le stringhe
• C++ filt di decodifica i simboli nella loro dichiarazione C++

Guardando i simboli si ottengono tipicamente identificazioni di ciò che il compilatore li ha prodotti. Se li hai visti con sufficienza spesso, puoi persino dire all'ABI i simboli stessi.

C'è molto di più in questa zona ma ho esaurito la resistenza ... :-) In ogni caso, penso che questo risponda a molte delle domande di cui sopra.

Answer 3

Mi sono imbattuto in questa domanda durante la ricerca dello strumento da utilizzare per creare il file .a utilizzando il compilatore Code :: Blocks C++ per Windows. Codice: Blocks utilizza il compilatore gcc MinGW.Era abbastanza su google per convalidare la mia necromanzia, credo.

Le librerie di collegamento dinamico (dll) sono un gruppo misto. Alcuni possono essere compilati in un modo che li rende molto difficili da usare al di fuori del linguaggio di programmazione e del compilatore con cui sono stati creati.

Spesso però la dll viene creata con un'interfaccia C pulita. Quando questo è il caso, le risposte alle tue domande a cui penso di poter rispondere sono:

1: non è una domanda.

2, 9: sì

3, 10: nessuna

4, 11: sì. MinGW include uno strumento (dlltool.exe) che accetta un file .dll e .def e crea un file .a MS VisualStudio include anche uno strumento (che penso sia chiamato lib.exe) per fare la stessa cosa. E se inizi a utilizzare un altro compilatore, probabilmente troverai che hanno anche uno strumento. I compilatori di Borland avevano lo strumento implib.exe.

5, 12: sì (uguale a 4)

6, 13: pew ... Io non credo che ci sia una data di scadenza sul dll, ma deve essere compilato per il sistema operativo giusto.

8, 16: è necessario il DEF di rendere il .ao lib, se non lo avete, in realtà è posible per creare che dal dll

Answer 4

domanda 1: si dovrebbe importare il file .h e il file .a con il comando linker e copiare .dll vicino all'uscita .exe.

domanda 2: si può fare .a file .def lima

set PATH=C:\Program Files\CodeBlocks\MinGW\bin;%PATH% 

dlltool.exe -d libfftw3-3.def -l libfftw3-3.a 

domanda 3: no. puoi fare manualmente il file .def e dopo aver fatto il file .a.

domanda 4,5: sì

domanda 6: Penso che è dipende dal vostro sistema hardware e il funzionamento non sul vostro compilatore.

domanda 7: non lo so.

domanda 8: è necessario solo .h.a.dll non DEF

domanda 9: .lib file è per Visual Studio.

domanda 10: non è necessario .def e .dll per rendere .lib e si può fare . def voi stessi se non ce l'hai.

set PATH=C:\Program Files\Microsoft Visual Studio 12.0\VC\bin;%PATH% 

lib /machine:x86 /def:libfftw3-3.def 

o

lib /machine:x64 /def:libfftw3-3.def 

Domanda 11: sì ti ho detto sopra.

domanda 12: sì

domanda 13: n.