Qt5 - CMake - SIGNAL/SLOT connections failed between library signals and executable slots

[Filippo Rusconi]

Greetings,

I am using MXE to build two artifacts using CMake (x86_64):

- a library with classes that emit Qt signals (pappso lib below);
- an executable binary that connects slots to these library-emitted signals.

Unfortunately, I receive a number of

Warning: QObject::connect: signal not found in pappso::PrecisionWidget (:0, )
Warning: QObject::connect: signal not found in pappso::BasePlotWidget (:0, )
Warning: QObject::connect: signal not found in pappso::BasePlotWidget (:0, )
Warning: QObject::connect: signal not found in pappso::BasePlotWidget (:0, )
Warning: QObject::connect: signal not found in pappso::BasePlotWidget (:0, )

First question: what is the (:0, ) string element above ?

Second question: is the dllexport art required when using the MXE/MinGW64 build
environment and using CMake to build shared libs and executable binaries ?

The program does not work as expected without the connections, understandably,
although it loads and performs well where signal/slot connections are not
required (like clicking buttons located in the executable, for example). This
makes me think that I am using MXE in an overall good manner.

I tried nonetheless to perform the equivalent build in a c:/msys64/mingw64
environmetn in Win10 to check if the behaviour is equivalent (same Qt5 version
and compiler version using C++17). Sadly, I get the same failed connections.
Then I tried building the library by specifying the following, according to the
CMake docs:

-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE -DBUILD_SHARED_LIBS=TRUE

but, although the md5 checksums of the libs are different, the sizes of the libs
(with or without this dllexport art) are identical. So, I gather that the
defines above are not essential ?

Third question: When building the library, I get systematically two dll
artifacts: the libname.dll and the libname.dll.a. What are the differences
between the two? I tried linking against one or the other, but that does not
solve my problem.

What other information should I provide to help you help me fix the problem ?

FYI, I am using -G "Unix Makefiles" and have confirmed that WIN32 is indeed
defined during the configuration of the build. What about using -G "MinGW
Makefiles". I tried, but the build seems to go the exact same way as the other
"Unix way". What is the difference between the two, in a msys64/mingw64 context?

Thank you for your patience and hoping help,
Sincerely, Filippo
Greetings,

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄⠀⠀⠀⠀  http://msxpertsuite.org
          http://www.debian.org