[Interest] mingw64: can't compile a lib such that a Qt signal can connect successfully to a binary slot

[Thiago Macieira]

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