Domanda

Come posso aggiungere una libreria esterna in un progetto creato da Qt Creator RC1 (versione 0.9.2)?Ad esempio, la funzione win32 EnumProcesses() richiede Psapi.lib da inserire nel progetto da realizzare.

È stato utile?

Soluzione

Il modo corretto per farlo è in questo modo:

LIBS += -L/path/to -lpsapi

In questo modo funziona su tutte le piattaforme supportate da Qt. L'idea è che si deve separare la directory dal nome della libreria (senza l'estensione e senza alcun prefisso 'lib'). Naturalmente, se si include un lib specifico di Windows, questo davvero non importa.

Nel caso in cui si desidera memorizzare i file lib nella directory di progetto, è possibile farvi riferimento con la variabile $$_PRO_FILE_PWD_, per esempio:.

LIBS += -L"$$_PRO_FILE_PWD_/3rdparty/libs/" -lpsapi

Altri suggerimenti

Stai usando progetti qmake? Se è così, è possibile aggiungere una libreria esterna utilizzando la LIBS variabile. Per esempio:

win32:LIBS += path/to/Psapi.lib
  

LIBS + = C: \ Program Files \ OpenCV \ lib

non funzionerà perché si sta utilizzando bianchi spazi-in Program Files. In questo caso si deve aggiungere citazioni, quindi il risultato sarà simile a questo: LIBS + = "C: \ Program Files \ OpenCV \ lib" . Vi consiglio librerie immissione in luoghi non bianco-spazio; -)

L'errore si intende è dovuto alla mancanza ulteriore percorso di inclusione. Prova ad aggiungere con: INCLUDEPATH + = C: \ percorso \ a \ includere i file \ \ Spero funzioni. Saluti.

E per aggiungere più file di libreria è possibile scrivere come di seguito:

  

INCLUDEPATH * = E: / DebugLibrary / VTK E: / DebugLibrary / VTK / Comune   E: / DebugLibrary / VTK / Filtering E: / DebugLibrary / VTK / GenericFiltering   E: / DebugLibrary / VTK / Grafica E: / DebugLibrary / VTK / GUISupport / Qt   E: / DebugLibrary / VTK / ibrida E: / DebugLibrary / VTK / Imaging   E: / DebugLibrary / VTK / IO E: / DebugLibrary / VTK / Parallel   E: / DebugLibrary / VTK / Rendering E: / DebugLibrary / VTK / Utilità   E: / DebugLibrary / VTK / rendering volumetrico E: / DebugLibrary / VTK / Widget   E: / DebugLibrary / VTK / Wrapping

     

LIBS * = -LE: / DebugLibrary / VTKBin / bin / release -lvtkCommon -lvtksys   -lQVTK -lvtkWidgets -lvtkRendering -lvtkGraphics -lvtkImaging -lvtkIO -lvtkFiltering -lvtkDICOMParser -lvtkpng -lvtktiff -lvtkzlib -lvtkjpeg -lvtkexpat -lvtkNetCDF -lvtkexoIIc -lvtkftgl -lvtkfreetype -lvtkHybrid -lvtkVolumeRendering -lQVTKWidgetPlugin -lvtkGenericFiltering

Se desideri distribuire la tua applicazione sulle macchine dei clienti, anziché utilizzare la tua applicazione solo tu stesso, scopriamo che the LIBS+= -Lxxx -lyyy metodo può creare confusione se non problemi.

Sviluppiamo applicazioni per Linux, Mac e Windows utilizzando Qt.Forniamo applicazioni complete e autonome.Pertanto tutte le librerie non di sistema dovrebbero essere incluse nel pacchetto di distribuzione.Vogliamo che i nostri clienti possano eseguire l'applicazione dalla stessa chiavetta USB per tutti i sistemi operativi.Per motivi di compatibilità della piattaforma, la chiavetta USB deve essere formattata come FAT32, che non supporta i collegamenti simbolici (Linux).

Abbiamo trovato il LIBS+= -Lxxx -lyyy espressione troppo simile a una scatola nera:

  1. Non sappiamo esattamente quale sia il percorso della libreria (statica o dinamica) trovata dal linker.Questo è scomodo.Il nostro linker Mac trova regolarmente librerie diverse da quelle che pensavamo dovessero essere utilizzate.Ciò è accaduto più volte con le librerie OpenSSL in cui il linker Mac ha trovato e utilizzato la propria versione OpenSSL, precedente e incompatibile, anziché la versione richiesta.

  2. Non possiamo permetterci che il linker utilizzi collegamenti simbolici alle librerie poiché ciò interromperebbe il pacchetto di distribuzione.

  3. Vogliamo vedere dal nome della libreria sia che colleghiamo una libreria statica o dinamica.

Quindi per il nostro caso particolare utilizziamo solo percorsi file assoluti e controlliamo se esistono.Rimuoviamo tutti i collegamenti simbolici.

Per prima cosa scopriamo quale sistema operativo stiamo utilizzando e lo inseriamo nella variabile CONFIG.E, ad esempio per Linux a 64 bit, quindi:

linux64 {
    LIBSSL= $$OPENSSLPATH/linux64/lib/libssl.a
    !exists($$LIBSSL): error ("Not existing $$LIBSSL")
    LIBS+= $$LIBSSL
    LIBCRYPTO= $$OPENSSLPATH/linux64/lib/libcrypto.a
    !exists($$LIBCRYPTO): error ("Not existing $$LIBCRYPTO")
    LIBS+= $$LIBCRYPTO
}

Tutte le dipendenze possono essere copiate nel pacchetto di distribuzione poiché conosciamo i loro percorsi di file.

Vorrei aggiungere per amor di completezza, che è anche possibile aggiungere solo il percorso della libreria in cui cercherà una libreria dipendente (che non può essere referenziato direttamente nel codice, ma una libreria si utilizza averli bisogno).

Per fare un confronto, ciò corrisponderebbe a quello che di ambiente LIBPATH fa, ma questo tipo di oscura in Qt Creator e non ben documentato.

Il modo in cui mi è venuto intorno a questo è il seguente:

LIBS += -L"$$_PRO_FILE_PWD_/Path_to_Psapi_lib/"

In sostanza, se non si fornisce il nome della libreria vera e propria, si aggiunge il percorso in cui si cercherà librerie dipendenti. La differenza di sintassi è piccola, ma questo è molto utile per fornire solo il percorso dove cercare librerie dipendenti. Talvolta, è solo un dolore per la fornitura di ogni percorso singola libreria in cui si sa che sono tutti in certa cartella e Qt Creator li pick up.

in .pro: LIBS += Ole32.lib OleAut32.lib Psapi.lib advapi32.lib

in .h / .cpp: #pragma comment(lib,"user32.lib")

#pragma comment(lib,"psapi.lib")
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top