On Fri, Jan 14, 2022 at 11:58 PM Ulf Hermann <ulf.herm...@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
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
