@JonB Thanks, I normally use CQTDeployer. That would mean for other projects the DLLs also need to be added under LIBS in the .pro file ?

Install a Qt message handler, set a breakpoint in there and take a look at the backtrace where it comes from.

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.

@SGaist Thank you so much for the quick reply.
I finally managed to do it.

Hi,

Can you show your class definition ?

Just use QT += module

That test is really only useful for code bases that should be built with both Qt 4 and Qt 5 since the widgets have moved to their own module in Qt 5.

Hi! I don't know if this is the recomended way, but I'd use simple C-style function callback.

@jsulm Thanks it worked..

@lindevs said:

libqxcb.so

libqxcb.so depends on these .so files:

libQt5XcbQpa.so.5 libQt5DBus.so.5

So in my case project structure looks:

myapp myapp.sh platforms\libqxcb.so libQt5Core.so.5 libQt5Gui.so.5 libQt5Widgets.so.5 libicudata.so.56 libicui18n.so.56 libicuuc.so.56 libQt5XcbQpa.so.5 libQt5DBus.so.5

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

That assumption is corrected.

AFAIK, having linking dependencies between two plugins is not a clean design.

I figured it out. I needed to set my QObject and QCore stuff properly. In the .pro file of the shared library, I added:

QT += core

In the shared library's .h file, I switched this:

class CTSCANSHARED_EXPORT ctScan { public: ...blah blah...

with this:

class CTSCANSHARED_EXPORT ctScan: public QObject { Q_OBJECT public: ...blah blah...

And then ensured the shared library's .h file had this:

#include <QObject>

And then it compiled properly.

Replace -llibstatgrab with -lstatgrab in your .pro file (lib prefix is added automatically, so you should not use it)

ACGuiApplication is a symbol that comes from that other library so it's not provided by libCommon. Have a look at the link_prl and create_prl qmake options. They should provide you with all the dependencies needed automatically.

Thanks a lot! This hint was expedient.

@SGaist said:

@sierdzio Indeed the back ticks are not mandatory, however it gives the forum engine a good hint of what is following

in the cheat sheet you can actually find:
Blocks of code are either fenced by lines with three back-ticks ```, or are indented with four spaces. I recommend only using the fenced code blocks -- they're easier and only they support syntax highlighting.

The question is what is the syntax highlighting now?