Qt5 QWidget project dependencies? OpenGL? Direct3D? WTH?



  • I recall certain QML/Qt5 proponents claiming GL won't be a dependency for QWidget based project with Qt5. Yet besides the usual core and gui Qt dlls, the executable also requires the files libGLESv2.dll and D3DCompiler_46.dll

    However that is not the worst part - the worst is that even after providing all the required DLLs, the application still doesn't run, even on the very same machine, it only works when launched from Creator.

    Any "ideas"?


  • Moderators

    Someone in http://qt-project.org/forums/viewthread/23102/ found that you need libEGL.dll too, which Windows doesn't seem to report :-/

    I'm curious about your D3D dependency though; which version of Qt 5 are you using? With the official MSVC 2010 version, I needed this for a simple app (QMainWindow + QTreeView):

    • Qt5Core.dll
    • Qt5Gui.dll
    • Qt5Widgets.dll
    • icudt49.dll
    • icuin49.dll
    • icuuc49.dll
    • libEGL.dll
    • libGLESv2.dll
    • platforms\qwindows.dll

    (I know I can get rid of ICU dependencies by compiling Qt 5 myself without ICU support, which means no Qt WebKit; not sure about OpenGL)



  • [quote author="utcenter" date="1356872337"]I recall certain QML/Qt5 proponents claiming GL won't be a dependency for QWidget based project with Qt5. Yet besides the usual core and gui Qt dlls, the executable also requires the files libGLESv2.dll and D3DCompiler_46.dll[/quote]

    QtWidgets does not depend on OpenGL / DirectX, it is the "OpenGL / DirectX support":http://qt-project.org/doc/qt-5.0/qtgui/qtgui-index.html#opengl-and-opengl-es-integration in QtGui which does. If you don't want OpenGL support or a dependency on it build with <code>-no-opengl</code>.

    This rule also applies for any other dependecy (ICU and alike).

    [quote author="utcenter" date="1356872337"]However that is not the worst part - the worst is that even after providing all the required DLLs, the application still doesn't run, even on the very same machine, it only works when launched from Creator.[/quote]Elaborate "doesn't run".



  • bq. Elaborate “doesn’t run”.

    The executable just doesn't start, there is no error, no nothing. Adding libEGL.dll fixed it, even thou there was no error message about it missing, unlike the rest of the dependencies.

    I compiled Qt5 myself with MSVC2012 x64.

    So you are telling me I need to have a whole new separate build of Qt just so I can eliminate OpenGL and Direct3D as a dependency for project, which DO NOT USE IT to begin with???



  • Yes, the same way you would have to have a whole new separate build of Qt just so you can eliminate the Windows Network libraries as a dependency for a project, which does not use networking to begin with.



  • I get the feeling the Qt4 solution was more elegant - the same build can be used to develop OpenGL applications, but for those that do not use OpenGL, it is not a requirement...

    BTW shouldn't platform specific APIs be abstracted from? The logical thing would be for the same Qt APIs to be ported to work work regardless of the platform's vendor specific APIs? Wasn't the very idea of Qt to be platform agnostic?

    All this sounds very counter-intuitive, counter-productive, inefficient and a step back as a whole... Changes, made for the sake of improving modularity seem to actually make it worse. Now I need several different builds of Qt instead of one...



  • [quote author="utcenter" date="1356963333"]I get the feeling the Qt4 solution was more elegant - the same build can be used to develop OpenGL applications, but for those that do not use OpenGL, it is not a requirement...[/quote]It was a deliberate design and release decision (I don't see a reason one would not take advantage of OpenGL unless there are very specific reasons, in which case you can still remove the dependency using <code>-no-opengl</code>). Separation and abstraction does not come for free.

    In addition, deployment is a Windows issue only, a platform where Qt is usually deployed with the application anyways.

    [quote author="utcenter" date="1356963333"]BTW shouldn't platform specific APIs be abstracted from? The logical thing would be for the same Qt APIs to be ported to work work regardless of the platform's vendor specific APIs? Wasn't the very idea of Qt to be platform agnostic?[/quote]What platform-specific resp. vendor-specific APIs?



  • I just mean it shouldn't really matter what is underneath Qt, the Qt APIs are abstracted enough but the core dependencies are not optional. To me that means modularity is actually worse after the extra modularization of Qt5.

    As for a reason why not to use OpenGL - one might target an embedded platform that does not have hardware or software support for OpenGL. And while it is possible to emulate it, why even bother if you don't really need it?

    All in all, I feel like the Qt5 release announcement slogan needs a disclaimer added:

    bq. ONE FRAMEWORK* TO RULE THEM ALL
    *you will still need several instances of it

    On a side note, while adding the EGL dll fixed the app on the development platform, it still refuse to run on another machine, even after adding some more VC2012 binaries to boost the size of dependencies to 20 MB.



  • [quote author="utcenter" date="1356972989"]I just mean it shouldn't really matter what is underneath Qt, the Qt APIs are abstracted enough but the core dependencies are not optional. To me that means modularity is actually worse after the extra modularization of Qt5.[/quote]OpenGL is still optional, it is just now a compile-time choice which is enabled by default. Feel free to build Qt without OpenGL (which is by the way neither platform-specfic, nor vendor-specific).

    [quote author="utcenter" date="1356972989"]As for a reason why not to use OpenGL - one might target an embedded platform that does not have hardware or software support for OpenGL. And while it is possible to emulate it, why even bother if you don't really need it?[/quote]Apart from the fact that you will have to be after a recent SoC which does not support at least OpenGL ES to find one you still have the option to just no depend on OpenGL in the custom build of Qt you'll need anyway for an embedded platform.

    [quote author="utcenter" date="1356972989"]bq. ONE FRAMEWORK* TO RULE THEM ALL
    *you will still need several instances of it[/quote]Do you think that it is possible that the compile time choice for OpenGL is a problem for you, but not necessarily for others?

    [quote author="utcenter" date="1356972989"]On a side note, while adding the EGL dll fixed the app on the development platform, it still refuse to run on another machine, even after adding some more VC2012 binaries to boost the size of dependencies to 20 MB.[/quote]Consult the Windows Event Log.



  • Not intending to be rude, but you do exhibit the typical fanboy behavior, you remind me of those Apple or AMD fanboys that feel obligated to defend and justify each and every decision of their cult/company, no matter whether it makes sense, is productive, efficient or anything. Normally the personal opinion of normal (non-fanatically devoted fanboys) is formed by a series of pro's and con's which shape an overall shade, but with you this doesn't appear to be the case.

    So let me ask you, do you happen to find anything that has happened in Qt the last few years wrong? Or do you take each and every decision to be the right one for granted? I've never seen you criticize anything, you always justify, you always approve... I hope at least you get paid for this, but probably yes, judging by your choice of visual representation - a faceless black suit labeled Qt...



  • I just don't see the problem, but feel free to file a "bug report":https://bugreports.qt-project.org/. "Patches":https://codereview.qt-project.org/ are welcome as well.



  • LOL and that is the automated response you always resort to, even in situations where there is no bug involved, like this one.

    Happy new year!



  • You want something changed in Qt. There are two ways to achieve this, regardless whether it is a bug, a feature request or a change request: you either file a bug report so the QtProject might do the work for you or you do the changes on your own and submit them.

    Moaning here at the forums does not change anything.



  • Nope, there are no ways to achieve this, one too many times have the requests of the community been arrogantly disregarded as groundless moaning of clueless idiots while the stupid decision behind Qt are being justified with every possible means.

    How stupid is it to have a dependency on OpenGL and Direct3D in an application that doesn't use either??? Oh no, it is not stupid, it is just yet another of the brilliant decisions pushing Qt forward into a better and brighter future.

    There are many decent people that have been quick to help me out when I needed help. And then there is you, with a "helping to preaching" ratio so low I'd appreciate it if from now on you refrain from following my every post with your dedicated pimping of an illusion of greatness and concern with the developer base. So I would really appreciate it if you cut the "political agenda" BS - if you are capable of such a feat, something that sadly cannot be said for most of fanboys out there.



  • I didn't mean to infantilize you.

    I just don't see the relevance of your request in practice. This does neither mean that your requests are "...groundless..." that make you an "...clueless idiot..." and me the incarnation of ..."greatness and concern...", nor that I'm right and you are wrong - it just means that I have a different opinion on the question you've asked and the points you've raised, and that I do not find your arguments suitable enough to convince me of the contrary. That's the nature of discussions, and no reason to get into a huff.

    Granted, the granularity of modularization can be argued over, most probably for all eternity. But I don't see the current one beeing disputable relating to dependencies, because there is still the option to not depend on stuff I do not want or need to, for example OpenGL or DirectX. Officially released shared libraries will always compel you to distribute stuff your application does not depend on, be it other shared libraries or data and code in existing libraries you do not use, because they are made to support any application, not a specific one.

    It is indeed your right to think that I'm wrong and to demand changes if you think that a wrong decision has been made, by either filing a bug report or participating in development - of course at the risk that others don't find your arguments suitable enough as well. Not every decision you find "...stupid..." has to be actually stupid.

    And I again invite you to join the Qt Development Mailing List and the Qt Open Governance Code Review to find out how and why decisions are made in the Qt Project.



  • I still cannot get the Qt5 executable to run on another system... Dependency walker wasn't much help - I get no errors, no notifications, no nothing, the exe just doesn't start. I managed to make it run on the development machine outside of Creator, but that's about it...

    Those are the DLLs I added:

    D3DCompiler_46.dll
    libEGL.dll
    libGLESv2.dll
    msvcp110.dll
    msvcr110.dll
    Qt5Core.dll
    Qt5Gui.dll
    Qt5Widgets.dll
    qwindows.dll

    Haven't added icu since I built Qt5 without the webkit...



  • [quote author="Lukas Geyer" date="1356970453"][quote author="utcenter" date="1356963333"]I get the feeling the Qt4 solution was more elegant - the same build can be used to develop OpenGL applications, but for those that do not use OpenGL, it is not a requirement...[/quote]It was a deliberate design and release decision (I don't see a reason one would not take advantage of OpenGL unless there are very specific reasons, in which case you can still remove the dependency using <code>-no-opengl</code>). Separation and abstraction does not come for free.

    In addition, deployment is a Windows issue only, a platform where Qt is usually deployed with the application anyways.

    [quote author="utcenter" date="1356963333"]BTW shouldn't platform specific APIs be abstracted from? The logical thing would be for the same Qt APIs to be ported to work work regardless of the platform's vendor specific APIs? Wasn't the very idea of Qt to be platform agnostic?[/quote]What platform-specific resp. vendor-specific APIs?

    [/quote]

    Entering a configure options list like the one below:

    configure -developer-build -opensource -nomake examples -no-opengl -no-icu

    Fails miserably



  • [quote author="Lukas Geyer" date="1356970453"][quote author="utcenter" date="1356963333"]I get the feeling the Qt4 solution was more elegant - the same build can be used to develop OpenGL applications, but for those that do not use OpenGL, it is not a requirement...[/quote]It was a deliberate design and release decision (I don't see a reason one would not take advantage of OpenGL unless there are very specific reasons, in which case you can still remove the dependency using <code>-no-opengl</code>). Separation and abstraction does not come for free.

    In addition, deployment is a Windows issue only, a platform where Qt is usually deployed with the application anyways.

    [quote author="utcenter" date="1356963333"]BTW shouldn't platform specific APIs be abstracted from? The logical thing would be for the same Qt APIs to be ported to work work regardless of the platform's vendor specific APIs? Wasn't the very idea of Qt to be platform agnostic?[/quote]What platform-specific resp. vendor-specific APIs?

    [/quote]

    Entering a configure options list like the one below:

    configure -developer-build -opensource -nomake examples -no-opengl -no-icu

    Fails miserably



  • Define 'fails miserably'.

    If you are not going to autotest Qt you do not need a <code>-developer-build</code>. And never release one.



  • Use static build, you will have one .exe (about 15Mb) worked from flashdrive elsewhere.



  • Unfortunately, that is not an option for commercial applications if you don't have a commercial Qt license, which is pretty pricey, especially for startup indie developers.


  • Moderators

    [quote author="utcenter" date="1357159840"]
    Those are the DLLs I added:

    D3DCompiler_46.dll
    libEGL.dll
    libGLESv2.dll
    msvcp110.dll
    msvcr110.dll
    Qt5Core.dll
    Qt5Gui.dll
    Qt5Widgets.dll
    qwindows.dll
    [/quote]
    Should be /platforms/qwindows.dll, i.e. in a sub-directory.



  • [quote author="Lukas Geyer" date="1359052917"]Define 'fails miserably'.[/quote]

    41 linker errors beginning with failing to build Qt5PrintSupport.dll.

    That's miserable!



  • You may provide any other information than 'miserable' if you are out for decent help, like the Qt version you are trying to build, the compiler and the configuration and the actual linker errors.



  • [quote author="Lukas Geyer" date="1359061129"]You may provide any other information than 'miserable' if you are out for decent help, like the Qt version you are trying to build, the compiler and the configuration and the actual linker errors.[/quote]

    I'll try. As I said 41 linker errors are a lot to display. What would be the best way to illustrate them?

    I downloaded version 5.0 for Windows 32-bit VS2010 to a Win 7 x86 machine with Active Perl, Python, Win SDK 7.1.

    Ran configure without opengl , icu.
    Ran nmake.
    As nmake attempted to link Qt5PrintSupport.dll, Link errors.



  • [quote author="astodolski" date="1359062332"]As I said 41 linker errors are a lot to display. What would be the best way to illustrate them?[/quote]

    I think a "paste":http://pastebin.com/ of the failed compilation step including the linker errors should be sufficient.

    In addition, I do recommend to use the "source package":http://releases.qt-project.org/qt5/5.0.0/single/qt-everywhere-opensource-src-5.0.0.zip found on the Downloads page instead of the 'Source' options of the SDK (they were different at least for Qt4, don't ask me why and if this has changed for Qt5).



  • [quote author="Lukas Geyer" date="1359096095"][quote author="astodolski" date="1359062332"]As I said 41 linker errors are a lot to display. What would be the best way to illustrate them?[/quote]

    I think a "paste":http://pastebin.com/ of the failed compilation step including the linker errors should be sufficient.

    In addition, I do recommend to use the "source package":http://releases.qt-project.org/qt5/5.0.0/single/qt-everywhere-opensource-src-5.0.0.zip found on the Downloads page instead of the 'Source' options of the SDK (they were different at least for Qt4, don't ask me why and if this has changed for Qt5).[/quote]

    As per your suggestions, I did the following:

    I have been using the "source package" since the start of this issue. I copied the contents to: C:\Qt\5.0.0

    I executed in the root folder: configure -opensource -nomake tests -no-opengl -no-icu

    Output is posted "here":http://pastebin.com/Fcb2g4Tv



  • Hey Lukas, I posted my findings so as to obtain "decent help". Were you able to have a look?



  • Looks like you don't link against gdi32.lib for some reason. Do you build from a VisualStudio command line?



  • [quote author="Lukas Geyer" date="1359571502"]Looks like you don't link against gdi32.lib for some reason. Do you build from a VisualStudio command line?[/quote]

    I use the Windows SDK command line. I didn't notice any link errors relating to that lib.



  • All those unresolved symbols (__imp__StartPage@4, __imp__StartDocW@8, ...) are part of gdi32.lib which doesn't seem to be linked for some reason.

    I've never seen this problem occouring before.

    I would suggest a fresh build from a Windows SDK command line; it this doesn't work please file "bug report":https://bugreports.qt-project.org/.



  • [quote author="Lukas Geyer" date="1359574684"]All those unresolved symbols (__imp__StartPage@4, __imp__StartDocW@8, ...) are part of gdi32.lib which doesn't seem to be linked for some reason.

    I've never seen this problem occouring before.

    I would suggest a fresh build from a Windows SDK command line; it this doesn't work please file "bug report":https://bugreports.qt-project.org/.[/quote]

    I DID a fresh build from source on the Win SDK command line. I followed EVERYTHING in the notes. For what it's worth, I did file the issue as a bug linked "here":https://bugreports.qt-project.org/browse/QTBUG-29360



  • If you do not see the relevance...go and find an oculist.
    Is there any serious design advantage or technical reason to impose unused and HUGE runtime dependency (25,9 MB!!!!!) unless you recompile your version of the whole Qt Framework?!?
    This is a pain in the ass, no way to not admit it.

    I only hope is not a slow strategy to make, in the time, the LGPL alternative less attractive than the commercial one...I think I'm wrong in that, but when I read answer like yours to a more than licit objection really some doubt raise.



  • If you do not see the relevance...go and find an oculist.
    Is there any serious design advantage or technical reason to impose unused and HUGE runtime dependency (25,9 MB!!!!!) unless you recompile your version of the whole Qt Framework?!?
    This is a pain in the ass, no way to not admit it.

    I only hope is not a slow strategy to make, in the time, the LGPL alternative less attractive than the commercial one...I think I'm wrong in that, but when I read answer like yours to a more than licit objection really some doubt raise.

    [quote author="Lukas Geyer" date="1357136305"]I didn't mean to infantilize you.

    I just don't see the relevance of your request in practice. This does neither mean that your requests are "...groundless..." that make you an "...clueless idiot..." and me the incarnation of ..."greatness and concern...", nor that I'm right and you are wrong - it just means that I have a different opinion on the question you've asked and the points you've raised, and that I do not find your arguments suitable enough to convince me of the contrary. That's the nature of discussions, and no reason to get into a huff.

    Granted, the granularity of modularization can be argued over, most probably for all eternity. But I don't see the current one beeing disputable relating to dependencies, because there is still the option to not depend on stuff I do not want or need to, for example OpenGL or DirectX. Officially released shared libraries will always compel you to distribute stuff your application does not depend on, be it other shared libraries or data and code in existing libraries you do not use, because they are made to support any application, not a specific one.

    It is indeed your right to think that I'm wrong and to demand changes if you think that a wrong decision has been made, by either filing a bug report or participating in development - of course at the risk that others don't find your arguments suitable enough as well. Not every decision you find "...stupid..." has to be actually stupid.

    And I again invite you to join the Qt Development Mailing List and the Qt Open Governance Code Review to find out how and why decisions are made in the Qt Project.[/quote]



  • [quote author="nomegenerico" date="1367248622"]Is there any serious design advantage or technical reason to impose unused and HUGE runtime dependency (25,9 MB!!!!!) unless you recompile your version of the whole Qt Framework?!?[/quote]
    WebKit (commercial and open source) requires ICU, Windows as in WebGL, WinRT and (Intel) OpenGL (commercial and open source) requires DirectX and ANGLE; feel free to forward your request to WebKit.org, Microsoft and Intel.

    You'll also find a sympathetic ear at "bugreports.qt-projects.org":https://bugreports.qt-project.org/ (to be honest, I'm not so confident for the others).

    Alternatively use a Qt which does not depend on ICU or ANGLE, either downloaded or built on your own, which is work equivalent to a coffee break.

    It is licit for you to find this an unreasonable burden; it is licit for me and the oculist to find it isn't.



  • bq. Alternatively use a Qt which does not depend on ICU or ANGLE, either downloaded or built on your own, which is work equivalent to a coffee break.

    Considering on a fast modern machine building Qt takes at least 2 hours and much more for a humble system, where is that amazing workplace with 2+ hours coffee breaks? And that is provided the build doesn't fail like it often does.



  • Downloading the sources, opening a command prompt and typing in <code>configure -skip webkit -no-icu -opengl desktop && jom</code> requires less than 2 minutes.

    As the resulting binaries are (source code) compatible feel free to continue developing while Qt is building, be it 30 minutes, 2 hours or a weekend. This is a deployment question, not a development question.

    And I hope you don't mind I don't jump your fail so often train, because it is completely contrary to the perception of someone building Qt on Tier 1 platforms on a regular basis.



  • [quote author="Lukas Geyer" date="1367267319"]
    WebKit (commercial and open source) requires ICU, Windows as in WebGL, WinRT and (Intel) OpenGL (commercial and open source) requires DirectX and ANGLE; feel free to forward your request to WebKit.org, Microsoft and Intel.
    You'll also find a sympathetic ear at "bugreports.qt-projects.org":https://bugreports.qt-project.org/ (to be honest, I'm not so confident for the others).
    Alternatively use a Qt which does not depend on ICU or ANGLE, either downloaded or built on your own, which is work equivalent to a coffee break.
    It is licit for you to find this an unreasonable burden; it is licit for me and the oculist to find it isn't.
    [/quote]

    So the dependency should appear only when a project include webkit, such as:

    CONFIG += webkit

    If not, why not make always and all dependent from whatever plugins or library?? Come on!!

    And what to say about large project that can possibly mix application that needs webkit and other that do not...we need to configure a different Qt toolkit for each to obtiani executable that require the right runtime. This is fun for how much is silly.

    The "sympathetic ear" is almost deaf just like you blind eyes.

    An otolaryngologist is needed too!!

    :-DDDDD

    Bye bye.



  • [quote author="Lukas Geyer" date="1367295179"]Downloading the sources, opening a command prompt and typing in <code>configure -skip webkit -no-icu -opengl desktop && jom</code> requires less than 2 minutes.
    As the resulting binaries are (source code) compatible feel free to continue developing while Qt is building, be it 30 minutes, 2 hours or a weekend. This is a deployment question, not a development question.
    And I hope you don't mind I don't jump your fail so often train, because it is completely contrary to the perception of someone building Qt on Tier 1 platforms on a regular basis.[/quote]

    Qt is a cross platform framework: most people have more than one platform to target in the same project.
    An on a single platform you can have more than one compiler (example: mingw and msvc on windows).

    If it is not enough for you to see some little "drawback", as long as I know, is not straightforward the way you tell us to compile Qt from sources and any different platform and compiler have it's own pitfalls.

    And you have to re-do all this for each minor release you would like to upgrade to!!!!

    An oculist??



  • [quote author="Lukas Geyer" date="1367295179"]Downloading the sources, opening a command prompt and typing in <code>configure -skip webkit -no-icu -opengl desktop && jom</code> requires less than 2 minutes.

    As the resulting binaries are (source code) compatible feel free to continue developing while Qt is building, be it 30 minutes, 2 hours or a weekend. This is a deployment question, not a development question.

    And I hope you don't mind I don't jump your fail so often train, because it is completely contrary to the perception of someone building Qt on Tier 1 platforms on a regular basis.[/quote]

    I've had Qt fail to build a few times in a row, ending up costing me far more than a few hours until I get a complete and working build. And considering I do nothing but configure the build, its failure can hardly be due to me doing something wrong. Building and deploying Qt is sadly far from as effortless as you and some other people present it. I've built pretty much every minor Qt release the last couple of years, and yes, there were releases that built effortlessly the first time, but there were also those who failed over and over again until I pinpoint the faulty modules and disable them. It would appear people at what is now digia don't do anywhere close to the necessary amount of testing on different software and hardware platforms, probably because testing is focused on what you refer to as "tier 1" platforms, whatever that might be...


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.