Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Unresolved external symbol while building a DLL
QtWS25 Last Chance

Unresolved external symbol while building a DLL

Scheduled Pinned Locked Moved General and Desktop
4 Posts 2 Posters 1.4k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V Offline
    V Offline
    vmatikainen
    wrote on last edited by
    #1

    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.

    1 Reply Last reply
    0
    • V Offline
      V Offline
      vmatikainen
      wrote on last edited by
      #2

      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.

      1 Reply Last reply
      0
      • SGaistS Offline
        SGaistS Offline
        SGaist
        Lifetime Qt Champion
        wrote on last edited by
        #3

        Hi,

        Do you have that code accessible somewhere ?

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        1 Reply Last reply
        0
        • V Offline
          V Offline
          vmatikainen
          wrote on last edited by vmatikainen
          #4

          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.

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved