Réponses:
La bonne façon de procéder est la suivante:
LIBS += -L/path/to -lpsapi
De cette façon, il fonctionnera sur toutes les plates-formes prises en charge par Qt. L'idée est que vous devez séparer le répertoire du nom de la bibliothèque (sans l'extension et sans préfixe «lib»). Bien sûr, si vous incluez une bibliothèque spécifique à Windows, cela n'a pas vraiment d'importance.
Si vous souhaitez stocker vos fichiers lib dans le répertoire du projet, vous pouvez les référencer avec la $$_PRO_FILE_PWD_
variable, par exemple:
LIBS += -L"$$_PRO_FILE_PWD_/3rdparty/libs/" -lpsapi
qmake -tp vc
, je ne trouve aucun nom de bibliothèque dans Additional Dependencies
le projet, mais le projet vs fonctionne bien. Cela signifie-t-il qu'il existe d'autres méthodes pour ajouter Additional Dependencies
vs?
LIBS += -lGdi32
.
Utilisez-vous des qmake
projets? Si tel est le cas, vous pouvez ajouter une bibliothèque externe à l'aide de la LIBS
variable. Par exemple:
win32:LIBS += path/to/Psapi.lib
LIBS + = C: \ Program Files \ OpenCV \ lib
ne fonctionnera pas car vous utilisez des espaces blancs dans Program Files. Dans ce cas, vous devez ajouter des guillemets, le résultat ressemblera donc à ceci: LIBS + = "C: \ Program Files \ OpenCV \ lib" . Je recommande de placer les bibliothèques dans des emplacements sans espace blanc ;-)
WINDIR = $$DIR
,WINDIR ~=s,/,\\,g
L'erreur que vous voulez dire est due à l'absence de chemin d'inclusion supplémentaire. Essayez de l'ajouter avec: INCLUDEPATH + = C: \ chemin \ vers \ include \ files \ J'espère que cela fonctionne. Cordialement.
Et pour ajouter plusieurs fichiers de bibliothèque, vous pouvez écrire comme ci-dessous:
INCLUDEPATH * = E: / DebugLibrary / VTK E: / DebugLibrary / VTK / Common E: / DebugLibrary / VTK / Filtering E: / DebugLibrary / VTK / GenericFiltering E: / DebugLibrary / VTK / Graphics E: / DebugLibrary / VTK / GUIDE Qt E: / DebugLibrary / VTK / Hybrid E: / DebugLibrary / VTK / Imaging E: / DebugLibrary / VTK / IO E: / DebugLibrary / VTK / Parallel E: / DebugLibrary / VTK / Rendu E: / DebugLibrary / VTK / Utilities E : / DebugLibrary / VTK / VolumeRendering E: / DebugLibrary / VTK / Widgets 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
Si vous souhaitez déployer votre application sur les machines des clients, plutôt que de n'utiliser votre application que vous-même, nous constatons que la LIBS+= -Lxxx -lyyy
méthode peut prêter à confusion sinon à des problèmes.
Nous développons des applications pour Linux, Mac et Windows en utilisant Qt. Nous expédions des applications complètes et autonomes. Toutes les bibliothèques non système doivent donc être incluses dans le package de déploiement. Nous voulons que nos clients puissent exécuter l'application à partir de la même clé USB pour tous les systèmes d'exploitation. Pour des raisons de compatibilité de plate-forme, la clé USB doit alors être formatée en FAT32, qui ne prend pas en charge les liens symboliques (Linux).
Nous avons trouvé l' LIBS+= -Lxxx -lyyy
idiome trop d'une boîte noire:
Nous ne savons pas exactement quel est le chemin du fichier de la bibliothèque (statique ou dynamique) qui a été trouvée par l'éditeur de liens. Cela n'est pas pratique. Notre éditeur de liens Mac a régulièrement trouvé des bibliothèques différentes de celles que nous pensions devoir utiliser. Cela s'est produit plusieurs fois avec les bibliothèques OpenSSL où l'éditeur de liens Mac a trouvé et utilisé sa propre version - plus ancienne et incompatible - d'OpenSSL plutôt que notre version demandée.
Nous ne pouvons pas nous permettre que l'éditeur de liens utilise des liens symboliques vers des bibliothèques car cela briserait le package de déploiement.
Nous voulons voir à partir du nom de la bibliothèque si nous lions une bibliothèque statique ou dynamique.
Donc, pour notre cas particulier, nous n'utilisons que des chemins de fichiers absolus et vérifions s'ils existent. Nous supprimons tous les liens symboliques.
Nous découvrons d'abord quel système d'exploitation nous utilisons et le mettons dans la variable CONFIG. Et, par exemple pour Linux 64 bits, alors:
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
}
Toutes les dépendances peuvent être copiées dans le package de déploiement car nous connaissons leurs chemins de fichiers.
Je voudrais ajouter par souci d'exhaustivité que vous pouvez également ajouter uniquement le CHEMIN DE BIBLIOTHÈQUE où il recherchera une bibliothèque dépendante (qui peut ne pas être directement référencée dans votre code, mais une bibliothèque que vous utilisez peut en avoir besoin).
A titre de comparaison, cela correspondrait à ce que fait l'environnement LIBPATH mais son genre d'obscur dans Qt Creator et pas bien documenté.
La façon dont je suis arrivé à ce sujet est la suivante:
LIBS += -L"$$_PRO_FILE_PWD_/Path_to_Psapi_lib/"
Essentiellement, si vous ne fournissez pas le nom réel de la bibliothèque, il ajoute le chemin vers lequel il recherchera les bibliothèques dépendantes. La différence de syntaxe est faible mais c'est très utile pour fournir uniquement le PATH où chercher les bibliothèques dépendantes. Il est parfois difficile de fournir chaque chemin de bibliothèque individuelle où vous savez qu'ils sont tous dans un certain dossier et Qt Creator les récupérera.
dans .pro: LIBS += Ole32.lib OleAut32.lib Psapi.lib advapi32.lib
dans .h / .cpp: #pragma comment(lib,"user32.lib")
#pragma comment(lib,"psapi.lib")