Nominate our 2022 Qt Champions!

Unresolved external symbol while building a DLL

  • Hi,

    I am modifying qml-box2d library to bind it with a QML particle systems. For that I am using a custom c++ handler for the QQuickParticleSystem. The problem is that I have a QObject class which gets the Particle System from QML via property and uses it through the private headers (qquickparticlessystem_p.h). The problem is that I can only modify the public member variables of the QQuickParticleSystem via the property pointer, but if I try to call the public functions it results in LNK2019 Unresolved external symbol when trying to build the dll.

    If I understood correctly the linker doesn't need to resolve the external symbols when building the dll, but still it does. Working usage of the public members variables also makes it look like I am doing everything right.

    Any ideas?

    I am using MSVC2010. And static/dynamic linking of Qt5QuickParticles.lib/Qt5QuickParticles.dll doesn't change a thing. Also I have QT += qml-private in .pro-file if it has anything to do with this.

  • Okay, I found out that this has something to do with MOC. I can call member functions that are not wrapped in moc macros like signals: or slots: just fine. So I would guess that the moc needs more than just the headers to get the correct function address while linking.

    For how to solve this, I have no idea.

  • Lifetime Qt Champion


    Do you have that code accessible somewhere ?

  • Hi,

    I think I got this figured out. As the Qt5QuickParticles library is for QML it doesn't actually export any of the symbols. Including the private headers makes it possible to refer to the public variables, but not the functions. I guess it must be possible to hack a custom function pointers to those also or something, but I've decided to venture other route.

    The magic words were Q_AUTOTEST_EXPORT in front of the class name instead of Q_DECL_EXPORT used in Qt libraries. The linker knows that there will not be any symbols for the functions and thus doesn't link successfully. So Qml only libraries are almost useless for c++ tinkering purposes as you can't inherit or use them in any reasonable way. The loading times are quicker tho, so there's a reason to define them that way.

    I'll change this to solved later.

Log in to reply