On Saturday, 11 April 2020 05:51:50 -03 Filippo Rusconi via Interest wrote:
> Warning: QObject::connect: signal not found in pappso::PrecisionWidget (:0,
> )
>
> Note that the pappso::PrecisionWidget class emits a signal that is very
> simple: it just has a conventional pointer as its argument:
>
> 8<~~~~~~
> typedef const PrecisionBase *PrecisionPtr;
>
> signals:
> void precisionChanged(pappso::PrecisionPtr precision) const;
> ~~~~~~>8
>
> I hope somebody can answer the following questions:
>
> First question:
> ----------------
>
> What is the (:0, ) string element above ?
Probably part of the problem. That comes from:
if (!senderMetaObject) {
qWarning("QObject::connect: signal not found in %s", sender-
>metaObject()->className());
slotObj->destroyIfLastRef();
return QMetaObject::Connection(nullptr);
}
It's trying to print the class name. There's no reason for more junk to be
printed in the line. So either there's something else also wrong with
debugging or something is wrong with the meta object. Since it can't find the
signal (which is related to the meta object), there's a good chance the two
problems are connected.
> Second question:
> ----------------
>
> Is the windows-specific dllexport macro art required when using the MinGW64
> build environment and using CMake to build shared libs and executable
> binaries ?
Yes. Each class must be either:
a) be a template instantiation (absolutely everything inline and doesn't take
addresses of any static variables)
b) used exclusively inside one single DLL
c) be exported from exactly one DLL and imported from all others
> 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
That accomplishes exporting.
You also need to *import* it from all the other libraries.
> 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. I thought the dll.a file was a static library, which indeed seems
> to be (I could extract *.o files out of it using ar). However, when I link
> against the dll.a file, the dll is still required at run time.
The .dll file is the DLL that is used by the Windows OS to load the code at
runtime.
The .dll.a file is the "import library". It's not a static library. It's how
the linker on Windows links to a DLL: it links to a very small .a file that
simply has "imports" for the DLL. That's different from all Unix systems,
where you link directly to the .so file and the linker takes care of writing
the correct output.
However, I think the GNU linker for Windows is smart enough to link to the
.dll file correctly, as you've seen. The MSVC link.exe is not: it still needs
to link to the import .lib file. So MinGW keeps this legacy. A simple
advantage of the import lib is that the .dll must live in the bin directory
for it to be useful at runtime, so you won't need to have a copy in the lib
dir too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
