On Fri, Jan 14, 2022 at 1:58 PM Ulf Hermann <ulf.herm...@qt.io> wrote:
> Indeed. And instead of the dummy symbol you can just use the existing > type registration function for that. As you've found out, "just store > it" is not enough. You have to "do" something with it. Sorry for being > inaccurate there. > I must've not understood the documentation then. I was left with the impression from the text that I'd put that whole store the pointer in a volatile variable inside the library itself so to prevent the linker from stripping the symbol. If that wasn't the intent then it's definitely a misunderstanding on my part. > 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. > Well, I'm by no means expert neither in QML nor in cmake, but what about putting a target property for the QML module target and checking against it from the cmake target that links against it, and if the property is set generate a dummy c++ code to load a dummy symbol (I used a dummy version tag for my experiments)? I'm not sure if that's even possible, but sounds like some sort of a "solution".
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
