The PKG_CONFIG_PATH is an environment variable so you need to add it before running qmake.
So set it through Projects > Build Settings > Build Environment in QtCreator or set it through terminal before running qmake manually in terminal.

Screen Shot 1401-02-05 at 13.30.41.png

Then add following lines in your .pro file:

mac { #if you need to specify PKG_CONFIG = /usr/local/bin/pkg-config } #someone says this need in some Qt versions but not need in my Qt 5.12.12 QT_CONFIG -= no-pkg-config CONFIG += link_pkgconfig PKGCONFIG += protobuf \ grpc \ grpc++

I can't find a way to set environment variable in .pro file. Can you do it?

I don't understand this well:

From looking at the documentation, it seems that the QAndroidJniObject constructor and methods have to be attaching and detaching the current thread to and from the JVM, which isn't going to work in a JNI thread that's already attached to the JVM.

Does this mean that, if I call C++ function(that uses QAndroidJniObject) from java JNI class, it is not going to work?
Because as I understand, QAndroidJniObject is attaching and detaching the current thread to and from the JVM, and the JNI java object that is calling native functions, is already attached to the JVM.
Please correct me if I am wrong.

Hi,

Did you just clone the curl sources ? If so the you have to build it before you can use it.

It does not work with qmake and I would rather search the bug in the lib you link against.

The only drawback is that 3rd-party modules cannot depend on one another unless they are submitted for inclusion in the core pool of modules. But it seems like this is just the price to pay for this kind of system?

Sorry for the long delay, I was traveling and had no time to actually look at the forum.
Yes, I would say that your summary is correct, and in that light I'd say what @VRonin had suggested as a way to build up the dependencies is probably best. That is - you have a set of core libraries that provide whatever they provide (which was what @SGaist mentioned in passing) and you stick to runtime loaded plugins being self-contained units that can't and/or won't depend on one another.

@RekTekk249 said in Importing libraries and including them still gives undefined references:

Also, I heard of Qt::mkdir, but apparently it's doesn't have good performances

micro-optimization - you call it once... it's just not worth the trouble.

Hi,

If you copy the files over your target respecting the same folders as your desktop machine, then you won't have anything special to do.

@Maikie130 If you have many tools, you can toss them all in the bin dir of one big AppDir made by linuxdeploy. For example, /opt/maiki/usr/bin and everything in that bin dir will get set with rpath by linuxdeploy to look for libraries in /opt/maikie/usr/lib, but nothing else on the system will get impacted by those libraries, so you don't have to duplicate but you can easily accumulate stuff in that appdir that is easy to move to your server.

The qt plugin has binarties published, so you can just use that rather than building it from source. They use the same appdir style of bundling everything into an image, so you can just grab the binary, chmod it +x and use it.

@wilke18

please see here: http://doc.qt.io/qtcreator/creator-project-wizards.html

@JonB I think i won't be able to understand something more detailled and that answer the whole questions =)

Thanks a lot, you ma real expert ! ;D

Thanks !

Yes, i have some stuff that doesnt quite need to be there, but it doesnt hurt. I removed all possible linkings and made them "hardcoded". If i add blackflycam.cpp to the sources, therefore it is compiled, i get those errors. If i dont, all runs smooth. The thing is, the code that i replaced with that file, has the exact same includes and non of them are qt-related, so i dont know what the hell is going on here !

thanks :)

I guess I'll just use the Qt's implementations then. Thanks for the explanation though.

@AlvaroS Please post your pro file. Nad is this lib built using the same compiler and for same architecture?

By the way, in QApplication's detailed documentation, you have an example of how start an application in "no-gui" mode.

This blog article might be of interest. Basically, you'll have to add the missing include path to the universal CRT.

@Ni.Sumi
It's no hassle at all. I've corrected a grammar mistake in the post, but the meaning should remain the same. :)

Kind regards.

@SGaist thank you so much.I solved problem by changing setup file

Hi and welcome to devnet,

In addition to @mrjj, can you show the exact error you have ?