Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Installation and Deployment
  4. Windows 8/10 deployed program will (sometimes) only detect plugin dlls from C:\Qt\5.5
Forum Updated to NodeBB v4.3 + New Features

Windows 8/10 deployed program will (sometimes) only detect plugin dlls from C:\Qt\5.5

Scheduled Pinned Locked Moved Solved Installation and Deployment
6 Posts 3 Posters 1.8k Views 2 Watching
  • 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.
  • T Offline
    T Offline
    tom10000
    wrote on last edited by
    #1

    Hi,
    I have intermittantly been seeing a lot of the error: "this app has failed to start due to platform plugin windows" and (via NtTrace) and some hacking, I see that the problem is with the deployment. [I'm working on Windows 10 with Qt 5.5/MSVC 2013 and deploying on Windows 8.1 for some reason.]

    Strangely, everything works fine sometimes. But when it doesn't, what seems to be happening is that the plugin dlls (eg for qsqlite) are being hard-wired only to load from C:\Qt\5.5\etc. If this is not present, then having the plugins in the deployment directory does not help. The (q)application fails before I have chance to investigate or use setLibraryPath() or addLibraryPath() so that's no help.

    Occasionally, copying all the dlls into the appropriate places after running windeployqt seems to help, but not always and the the only true rememdy seems to be to install the Qt dlls to the standard place.

    Is there some switch or rune or should be casting?

    cheers,

    A 1 Reply Last reply
    0
    • mrjjM Offline
      mrjjM Offline
      mrjj
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi
      Runes and spell casting always helps ;)
      As far as I understand it - windeployqt does some path fixup on some of the dlls.
      https://forum.qt.io/topic/72372/why-patching-qt5cored-dll-when-building-the-project/5
      On linux they seems to have rpath to change and set such paths.
      So I suspect the dog be buried somewhere in this info but I'm purely speculating.

      Note that @hskoglund posting in the link, has site http://www.tripleboot.org/?p=138
      which been my source of deplyment.

      1 Reply Last reply
      2
      • T tom10000

        Hi,
        I have intermittantly been seeing a lot of the error: "this app has failed to start due to platform plugin windows" and (via NtTrace) and some hacking, I see that the problem is with the deployment. [I'm working on Windows 10 with Qt 5.5/MSVC 2013 and deploying on Windows 8.1 for some reason.]

        Strangely, everything works fine sometimes. But when it doesn't, what seems to be happening is that the plugin dlls (eg for qsqlite) are being hard-wired only to load from C:\Qt\5.5\etc. If this is not present, then having the plugins in the deployment directory does not help. The (q)application fails before I have chance to investigate or use setLibraryPath() or addLibraryPath() so that's no help.

        Occasionally, copying all the dlls into the appropriate places after running windeployqt seems to help, but not always and the the only true rememdy seems to be to install the Qt dlls to the standard place.

        Is there some switch or rune or should be casting?

        cheers,

        A Offline
        A Offline
        ambershark
        wrote on last edited by
        #3

        @tom10000 You could always use a qt.conf file in your binary directory to set your path. This should absolutely stop any other Qt plugin path from being used no matter what.

        Example (qt.conf):

        [Paths]
        Plugins = ./plugins
        

        That will look for plugins only in the plugins folder in the current directory.

        My L-GPL'd C++ Logger github.com/ambershark-mike/sharklog

        1 Reply Last reply
        3
        • T Offline
          T Offline
          tom10000
          wrote on last edited by
          #4

          Thanks for your comments.... I'm finding that 'qt.conf' is not really making any difference though it seems it should. Copying the plugins to a "plugins" subfolder, however, does seem to help, so presumably this is being hard-wired too....

          The best way of proceeding seems to be :-

          • to copy all the dlls from C:\Qt\5.5 into my deploy directory (as windeploy would do it)
          • run windeployqt over the top
          • if that doesn't work, move the plugin dlls to a plugins subfolder.
          • if that fails too, copy C:\Qt\5.5\msvc2013 to the target machine.
          • cast more runes (or start reinstalling everything)

          Presumably the deploy/path-setting is a bit buggy in this version. Not a complete answer, but at least it makes a bit more sense

          regards,

          A T 2 Replies Last reply
          1
          • T tom10000

            Thanks for your comments.... I'm finding that 'qt.conf' is not really making any difference though it seems it should. Copying the plugins to a "plugins" subfolder, however, does seem to help, so presumably this is being hard-wired too....

            The best way of proceeding seems to be :-

            • to copy all the dlls from C:\Qt\5.5 into my deploy directory (as windeploy would do it)
            • run windeployqt over the top
            • if that doesn't work, move the plugin dlls to a plugins subfolder.
            • if that fails too, copy C:\Qt\5.5\msvc2013 to the target machine.
            • cast more runes (or start reinstalling everything)

            Presumably the deploy/path-setting is a bit buggy in this version. Not a complete answer, but at least it makes a bit more sense

            regards,

            A Offline
            A Offline
            ambershark
            wrote on last edited by
            #5

            Thanks for your comments.... I'm finding that 'qt.conf' is not really making any difference though it seems it should. Copying the plugins to a "plugins" subfolder, however, does seem to help, so presumably this is being hard-wired too....

            That is weird. That qt.conf file should be honored above everything else.

            All plugin dlls should always be in specific folders. I.e. yourapp/plugins/imageformats and so forth. It's easy to figure out where they should be based on where they are located in the plugins folder in your Qt install.

            For reference, here's a deployment structure for an app of mine:

            ./bin
            ./bin/myapp
            ./bin/qt.conf
            ./myapp
            ./INSTALL
            ./README
            ./libs
            ./libs/libstdc++.so.6
            ./libs/libQt5Core.so.5
            ./libs/libQt5Xml.so.5
            ./libs/libQt5Widgets.so.5
            ./libs/libsharkcore.so
            ./libs/libQt5XcbQpa.so.5
            ./libs/libQt5DBus.so.5
            ./libs/libgcc_s.so.1
            ./libs/libquazip.so
            ./libs/libsharkcore.so.1.7.3
            ./libs/libQt5Network.so.5
            ./libs/libquazip.so.1.0.0
            ./libs/libQt5XmlPatterns.so.5
            ./libs/plugins
            ./libs/plugins/platforms
            ./libs/plugins/platforms/libqxcb.so
            ./libs/libQt5Gui.so.5
            ./libs/libQt5SerialPort.so.5
            ./libs/libquazip.so.1
            

            You'll notice that I have a libs dir that has most of my shared objects (dlls), and inside that I have plugins/platforms which holds my platform plugin. This could also have imageformats, sql stuff, whatever type of plugins you need.

            My L-GPL'd C++ Logger github.com/ambershark-mike/sharklog

            1 Reply Last reply
            1
            • T tom10000

              Thanks for your comments.... I'm finding that 'qt.conf' is not really making any difference though it seems it should. Copying the plugins to a "plugins" subfolder, however, does seem to help, so presumably this is being hard-wired too....

              The best way of proceeding seems to be :-

              • to copy all the dlls from C:\Qt\5.5 into my deploy directory (as windeploy would do it)
              • run windeployqt over the top
              • if that doesn't work, move the plugin dlls to a plugins subfolder.
              • if that fails too, copy C:\Qt\5.5\msvc2013 to the target machine.
              • cast more runes (or start reinstalling everything)

              Presumably the deploy/path-setting is a bit buggy in this version. Not a complete answer, but at least it makes a bit more sense

              regards,

              T Offline
              T Offline
              tom10000
              wrote on last edited by
              #6

              @ambershark said in Windows 8/10 deployed program will (sometimes) only detect plugin dlls from C:\Qt\5.5:

              That is weird. That qt.conf file should be honored above everything else.

              Hi - thanks....
              actually your qt.conf does work, so long as I only use the windeployqt'd dlls..... I just have to remember to copy over the icu*.dlls which windeploy seems to miss, and then move all sub-folders (apart from 'translations' which I guess should be separate) into a "plugins" directory....

              ... least ways that's what's working today
              cheers,

              1 Reply Last reply
              1

              • Login

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