[Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

On Fri, Jan 14, 2022 at 11:58 PM Ulf Hermann <ulf.hermann at qt.io> wrote:

> The way we work around the issue in the generated plugin code is storing
> it in a volatile pointer. That's terrible and also not guaranteed to
> work, but it works in practice on all compilers we support. If you
> figure out a better way, please let me know.
>

I've had some "progress" with this, so I'm going to post some findings for
future reference.

It turned out that I observe this "surprising" (at least at first) behavior
as the g++ linker wrapper's  been patched upstream to implicitly pass
--as-needed, hence the library's not been marked with DT_NEEDED and
subsequently it isn't loaded.

Firstly, I've attempted to trick the linker by passing -u someSymbol, which
symbol is defined in the library to make it decide that the library was
indeed necessary, however with no success. Inspecting the symbols -
everything did appear correct, yet the linker still refused to mark it as
needed. Why that didn't work I don't know. For MSVC there's the
/INCLUDE:symbol which should work in the same way as gcc's -u according to
the documentation, but since I failed to make it work on linux I didn't
bother to test.

Secondly, I tried to set LINK_WHAT_YOU_USE in CMake, but for whatever
reason that also didn't work. Probably the reason is that I'm using ninja,
while it's supposed to be supported for Makefiles.

Thirdly, I passed --no-as-needed manually for the library, which did indeed
work correctly and marked the library for loading. Unfortunately it is
quite clumsy, especially if one wants to restore the default behavior, and
I imagine is somewhat error prone. On that note the CMake people have an
open ticket to provide decorating at link time which should cover such a
possible use case in the future[1]. Whether this gets in, remains to be
seen, but from a glance does seem somewhat advanced in the MR review.

Lastly, I provided my own dummy cpp file out of the library for the
consuming target(s) - where I do the pointer trick which Ulf mentioned.
This works, just okay, and the consumer doesn't need to care, which is the
whole point.
On that note, is there a specific reason I'm missing that qt_add_qml_module
doesn't do this, but instead requires the consuming target to ensure that a
symbol is accessed? Perhaps, provided there are no problems that I'd
missed, this could be an "improvement"; in the sense that it's not going to
be done manually anymore, and can be neatly integrated into the CMake
scripts.

Kind regards,
Konstantin.

[1]: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6769
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20220119/1925ad9a/attachment.htm>