Visual C++ - Collegamento di plugin DLL contro EXE?

Question

Sono in procinto di eseguire il porting di una grande applicazione C++ da Linux (gcc) a Windows (Visual C++ 2008) e sto avendo problemi di linker con i plugin. Su Linux questo non era un problema, dato che .so supporta la ricerca dei simboli di runtime, ma dll non sembra supportarlo.

Alcune informazioni di base: L'applicazione (l'host), che ospita un ambiente di scripting, fornisce interfacce per i plugin (librerie condivise che vengono caricati in fase di esecuzione da chiamate API per gli script), permettendo l'host e l'API di scripting per essere esteso senza ricompilare l'applicazione host. Su Linux questo è solo questione di includere le intestazioni dell'applicazione host nel sorgente del plugin, ma su Windows sto ricevendo errori del linker. Non sono esattamente ciò di cui ho bisogno per collegare Visual C++ per risolvere questi simboli.

Una delle nostre dipendenze (open source, LGPL) ha dichiarazioni di preprocessore che utilizza per inserire __declspec (dllexport) e __declspec (dllimport) nelle intestazioni. Alcune ricerche precedenti indicano che potrei doverlo fare anch'io, ma vorrei essere sicuro prima di modificare un intero gruppo di intestazioni principali. (In precedenza ero in grado di farlo funzionare su MinGW, ma abbiamo deciso che supportare Visual Studio è un requisito per questo tipo di progetto commerciale.)

La mia domanda, in poche parole: Come collego runtime- dll caricati contro un exe host in Visual C++?

Modifica: Per chiarire il problema con un esempio, ho una classe nella mia applicazione host, oggetto, che rappresenta il tipo di base di un oggetto che si può accedere da uno script. Nei miei plugin ho un certo numero di classi che estendono lo oggetto per eseguire altre funzioni, come l'integrazione del supporto di rete o di nuovi elementi visivi. Ciò significa che la mia DLL deve essere collegata con i simboli dell'host host e non sono sicuro di come farlo.

Answer 1

Cosa intendi per "runtime symbol lookup"? Intendi dire caricare dinamicamente le librerie usando dlopen e dlsym e so on? I numeri equivalents in Windows sono chiamati LoadLibrary e GetProcAddress.

In Windows, non esportare simboli da un file eseguibile. Dovresti esportarli solo da una DLL. Il modo giusto per risolvere il tuo problema è rearchitect in modo che i simboli esportati siano in una dll a cui è possibile collegare l'eseguibile e altre DLL di plugin.

Answer 2

Non è possibile, facilmente. Il caricatore di windows non è progettato per esportare simboli da un EXE e associarli a simboli in una DLL.

Uno schema che ho visto è la DLL che esporta una determinata funzione chiamata da EXE. Assume come parametro una struttura che contiene gli indirizzi delle funzioni nell'EXE per la DLL da chiamare.

Answer 3

Come dice 1800 INFORMAZIONI, non farlo così. Sposta Oggetto fuori dall'eseguibile e in una "terza" DLL. Collega i plugin e l'eseguibile con quello.

Answer 4

Ho implementato lo stesso, costruendo una libreria di plugin per costruire sotto Linux e Windows.

La soluzione sotto Linux consiste nell'utilizzare l'opzione -rdinamica nella riga di comando gcc. Questo esporta tutti i simboli nell'eseguibile principale, in modo che un plugin possa trovarli al caricamento.

In Windows, la soluzione è aggiungere __declspec (dllexport) davanti alla definizione di quelle funzioni nell'exe che si desidera vengano utilizzate dalle DLL.Compilation creerà un file .lib per le DLL da collegare. Certamente funziona sotto Visual Studio 2008. Articolo correlato: https://stackoverflow.com/a/3756083/1486836