How properly add external libs to Qt .pro?

Engelard

I searching in google and can't find the solution which would work. For the moment, i add to simple includes in my .h file and it gave me 146 errors.

#include <tchar.h>
#include <psapi.h>

First, i add in to my .pro file this:

LIBS     +=  -lpsapi

It wont work, still same errors. Next suggestions from google i did'nt get at all, it suggests:

The proper way to do this is like this:

LIBS += -L/path/to -lpsapi

In case you want to store your lib files in the project directory, you can reference them with the $$PRO_FILE_PWD variable, e.g.:

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

That i dont get at all, what should i do? download proper .lib files of psapi, place it in that directory and then add proper path in my .pro file?

But the hardest suggestion was from Microsoft, and it was'nt even for Qt project, but they said:

// To ensure correct resolution of symbols, add Psapi.lib to TARGETLIBS
// and compile with -DPSAPI_VERSION=1

I simple C++ programmer, i never was curious about that linking creepy stuff. Help me.

sierdzio

What errors are you getting? Are they linker errors or compiler errors?

You definitely need to add library headers to INCLUDEPATH. That should solve compiler errors.

Then if you get errors from your linker, post them here. It can be that linker can't find the library (it will simply say so then), but it can also fail to find symbols inside the library (then it will print many errors).

Engelard

@sierdzio said in How properly add external libs to Qt .pro?:

INCLUDEPATH

Well, i tried includepath(i found about 15 psapi.lib files on my Disk C):

QT       += core gui
LIBS     += -luser32
INCLUDEPATH += C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x64
LIBS     += -lpsapi

And still same errors:

alt text

koahnig

@Engelard

Your INCLUDEPATH is not properly defined. Backslahses are interpret as end of lines with continuation in next line. The spaces are inpret as separators.

Try

INCLUDEPATH += "C:/Program Files (x86)/Windows Kits/10/Lib/10.0.16299.0/um/x64"

In LIBS you specify library but not the path to where to find it. See here: https://doc.qt.io/qt-5/qmake-variable-reference.html#libs

Engelard

@koahnig Still not working(even worse, 282 errors now)

QT       += core gui
INCLUDEPATH += "C:/Program Files (x86)/Windows Kits/10/Lib/10.0.16299.0/um/x64"
LIBS     += -luser32
LIBS     += "C:/Program Files (x86)/Windows Kits/10/Lib/10.0.16299.0/um/x64/Psapi.Lib"

mrjj

@Engelard
Hi
Are you using visual studio compiler and not mingw ?

update:
you need
#include <windows.h>
#include <psapi.h>

and .pro syntax is
INCLUDEPATH += "C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10240.0/um/x64"
LIBS += -lPsapi

then it links here.

NOTE: my path is slightly different from yours.

Engelard

@mrjj said in How properly add external libs to Qt .pro?:

@Engelard
Hi
Are you using visual studio compiler and not mingw ?

update:
you need
#include <windows.h>
#include <psapi.h>

Your order of including trigger in me some memory what i had months before(had same issue but with includes for Opengl).

What i now did.

Just replace windows include before psapi and others and it now compile with no errors, perfectly as it should. Also i tested, now no additional lines in .pro file needed. so my .pro section looks like this:

QT       += core gui
LIBS     += -luser32

So the solution: Windows.h should be included BEFORE libs which depends on it.

aha_1980

@Engelard

So the solution: Windows.h should be included BEFORE libs which depends on it.

... and sane include files include everything they need, so they don't depend on any order. which seems not the case here.

Engelard

@aha_1980 not always, as i said, i already saw such cases before when some libraries need inclusion of other libraries, like glfw.h and glew.h, one depends on another.

JKSH

@Engelard said in How properly add external libs to Qt .pro?:

@aha_1980 not always, as i said, i already saw such cases before when some libraries need inclusion of other libraries, like glfw.h and glew.h, one depends on another.

Yes, we know these scenarios exist. @aha_1980 is just pointing out that such headers are not "sane" :)

Engelard

Yes, we know these scenarios exist.

Oh, now i understand.

@aha_1980 is just pointing out that such headers are not "sane" :)

Well, maybe thats because it were made by microsoft.