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. How to get QtCreator to use static libs for Release?
Forum Updated to NodeBB v4.3 + New Features

How to get QtCreator to use static libs for Release?

Scheduled Pinned Locked Moved Unsolved Installation and Deployment
16 Posts 5 Posters 7.2k Views 3 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.
  • lonnieL Offline
    lonnieL Offline
    lonnie
    wrote on last edited by
    #1

    I recently started my trial of the Commercial version, primarily to be able generate statically linked programs. They are much easier to deploy and there is no nightmare of DLL versions getting changed.

    I see all of the QT DLL files in C:\Qt\5.9.1\msvc2017_64\bin and all of the lib files seem to be in C:\Qt\5.9.1\msvc2017_64\lib which I understand to mean the static libs are available and do not require me to rebuild QT with -static.

    For the life of me I cannot see how to get QtCreator to use static libs. Maybe it cannot, but one would assume that to be a standard task for an IDE.

    So, a simple question, and likely a forehead slapper for me, but after I have done the Debug development process and am satisfied with it, how do I generate a statically linked Release?

    BTW, the IDE is quite nice and for the most part I got used to it very easily. It is easy to customise and once I forget my VS ways, I find it very natural.

    jsulmJ 1 Reply Last reply
    0
    • lonnieL lonnie

      I recently started my trial of the Commercial version, primarily to be able generate statically linked programs. They are much easier to deploy and there is no nightmare of DLL versions getting changed.

      I see all of the QT DLL files in C:\Qt\5.9.1\msvc2017_64\bin and all of the lib files seem to be in C:\Qt\5.9.1\msvc2017_64\lib which I understand to mean the static libs are available and do not require me to rebuild QT with -static.

      For the life of me I cannot see how to get QtCreator to use static libs. Maybe it cannot, but one would assume that to be a standard task for an IDE.

      So, a simple question, and likely a forehead slapper for me, but after I have done the Debug development process and am satisfied with it, how do I generate a statically linked Release?

      BTW, the IDE is quite nice and for the most part I got used to it very easily. It is easy to customise and once I forget my VS ways, I find it very natural.

      jsulmJ Offline
      jsulmJ Offline
      jsulm
      Lifetime Qt Champion
      wrote on last edited by
      #2

      @lonnie said in How to get QtCreator to use static libs for Release?:

      They are much easier to deploy and there is no nightmare of DLL versions getting changed

      Well, if you deploy your app properly there will be no DLL nightmare. Usually you deploy your Qt app with all needed DLLs in one package. Those DLLs are then installed in the same directory where your app is installed - no DLL nightmare. DLL nightmare is if you install DLL inside system directories (C:\Windows...) or if you add the directory containing the DLLs to the PATH variable.

      QtCreator does not care about static/shared libs as it is not building anything. Instead it uses qmake or CMake to build the project.

      https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • lonnieL Offline
        lonnieL Offline
        lonnie
        wrote on last edited by lonnie
        #3

        Understood about the installation of the DLL's to the app directory. And thanks for the reply.

        The other issue is one of security. I am primarily working on password encryption. If the program is statically linked it is fairly secure. It can be decompiled but they would be dealing with a larger program, and you have the tree in the forest issue. If you dynamically link then the DLL can easily be changed to something that will snoop the calls and report the password. Decompiling is much easier because you have a very small program and thus a tree in the yard issue.

        Surely they could have built the makefile handling into their IDE? So now I have to jump back 15 years and deal with a makefile? I guess the QT wizards have never used Visual Studio, where you can tweak every aspect of the compiling task.

        It is not a deal breaker, but is a HUGE disappointment and takes the edge off the initial euphoria of working with it.

        jsulmJ 1 Reply Last reply
        0
        • K Offline
          K Offline
          karlheinzreichel
          wrote on last edited by
          #4

          I do not get your point regarding the libraries.
          For windows you have to cases:

          1. dynamic linking : You link the qt creator files against the Qt-Export-Libraries
          2. static linking: You link the qt creator files against the static Qt-Libraries

          both, the Qt-Export-Libraries AND the QT-Libraries have the same name.
          The only thing you have to support is the library path for the static Qt-Libaries.

          regards
          Karl-Heinz

          1 Reply Last reply
          1
          • mrjjM Offline
            mrjjM Offline
            mrjj
            Lifetime Qt Champion
            wrote on last edited by
            #5
            • Surely they could have built the makefile handling into their IDE? So now I have to jump back 15 years and deal with a makefile? I - guess the QT wizards have never used Visual Studio, where you can tweak every aspect of the compiling task.

            QtCreator is build with visual studio :)
            Also, the .pro file can used to control the "makefile" and the Projects tab allows
            tweaking of the compiling.
            http://doc.qt.io/qt-5/qmake-overview.html

            Anyway, static build of Qt is like another kit. You must build it and "install" to the IDE.
            Then its simply a matter of selecting static version and rebuild to get static version of app.

            https://github.com/alberthdev/alberthdev-misc/wiki/Building-Qt-v5.6-Statically-on-Windows

            lonnieL 1 Reply Last reply
            1
            • lonnieL lonnie

              Understood about the installation of the DLL's to the app directory. And thanks for the reply.

              The other issue is one of security. I am primarily working on password encryption. If the program is statically linked it is fairly secure. It can be decompiled but they would be dealing with a larger program, and you have the tree in the forest issue. If you dynamically link then the DLL can easily be changed to something that will snoop the calls and report the password. Decompiling is much easier because you have a very small program and thus a tree in the yard issue.

              Surely they could have built the makefile handling into their IDE? So now I have to jump back 15 years and deal with a makefile? I guess the QT wizards have never used Visual Studio, where you can tweak every aspect of the compiling task.

              It is not a deal breaker, but is a HUGE disappointment and takes the edge off the initial euphoria of working with it.

              jsulmJ Offline
              jsulmJ Offline
              jsulm
              Lifetime Qt Champion
              wrote on last edited by
              #6

              @lonnie said in How to get QtCreator to use static libs for Release?:

              So now I have to jump back 15 years and deal with a makefile?

              Sorry, but did anybody say you have to do this?!
              No need to deal with Makefiles.
              All I said is that QtCreator (like any other modern IDE) does not handle the build process directly. Instead it uses qmake or CMake (like VisualStudio uses MSBuild).
              For detailes take a look at what @mrjj wrote.

              "guess the QT wizards have never used Visual Studio" - do you know any?

              https://forum.qt.io/topic/113070/qt-code-of-conduct

              1 Reply Last reply
              1
              • lonnieL Offline
                lonnieL Offline
                lonnie
                wrote on last edited by
                #7

                Sorry to be offending everyone. I am just getting frustrated.

                QtCreator is awesome, so it has me baffled why there is not simply an option to select static linking. It is not as if anyone has been asking how to do this (for many, many years). Why would the QT people not do it once, the correct way, rather than having hundreds or maybe even thousands of people doing it and potentially missing a step or two?

                I guess I don't get how you "install" the static libs to the IDE. I snooped around and found a whole bunch of .libs in C:\Qt\5.9.1\msvc2017_64\lib. In my limited world these are the wonderful static libs, so now the process becomes "how to tell the linker to link them in".

                I am missing something, and it has to be simple. Like anything new, I simply do not know enough to ask the right question. And that is frustrating when it should be so easy to accomplish what I need.

                I am packing it in for tonight. It is 1:30 AM and time to relax. In my youth it would just be starting to get interesting, but can't do it anymore.

                jsulmJ 1 Reply Last reply
                0
                • lonnieL lonnie

                  Sorry to be offending everyone. I am just getting frustrated.

                  QtCreator is awesome, so it has me baffled why there is not simply an option to select static linking. It is not as if anyone has been asking how to do this (for many, many years). Why would the QT people not do it once, the correct way, rather than having hundreds or maybe even thousands of people doing it and potentially missing a step or two?

                  I guess I don't get how you "install" the static libs to the IDE. I snooped around and found a whole bunch of .libs in C:\Qt\5.9.1\msvc2017_64\lib. In my limited world these are the wonderful static libs, so now the process becomes "how to tell the linker to link them in".

                  I am missing something, and it has to be simple. Like anything new, I simply do not know enough to ask the right question. And that is frustrating when it should be so easy to accomplish what I need.

                  I am packing it in for tonight. It is 1:30 AM and time to relax. In my youth it would just be starting to get interesting, but can't do it anymore.

                  jsulmJ Offline
                  jsulmJ Offline
                  jsulm
                  Lifetime Qt Champion
                  wrote on last edited by
                  #8

                  @lonnie If you want to use static libs you need to build Qt by yourself. This static build will have its own qmake.exe. Then in QtCreator you set-up a new Kit where you select this qmake.exe from your static Qt build. That's it. Run qmake on your project and build.

                  https://forum.qt.io/topic/113070/qt-code-of-conduct

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

                    Hi
                    There is not an option to select static linking as those DLLS are not include for the very reason that
                    there exists many versions of Qt and to create & test static version of all combinations would cost
                    a lot of time and efforts.

                    Like
                    Qt 5.9 -> for Mac, Linux, Window , for windows mingw and Visual studio
                    and then for 4.8, 5.6, 5.7, 5.8 etc

                    So its NOT possible to do static linking out of the box.
                    Its not premade.
                    You must do it. :)

                    1 Reply Last reply
                    1
                    • mrjjM mrjj
                      • Surely they could have built the makefile handling into their IDE? So now I have to jump back 15 years and deal with a makefile? I - guess the QT wizards have never used Visual Studio, where you can tweak every aspect of the compiling task.

                      QtCreator is build with visual studio :)
                      Also, the .pro file can used to control the "makefile" and the Projects tab allows
                      tweaking of the compiling.
                      http://doc.qt.io/qt-5/qmake-overview.html

                      Anyway, static build of Qt is like another kit. You must build it and "install" to the IDE.
                      Then its simply a matter of selecting static version and rebuild to get static version of app.

                      https://github.com/alberthdev/alberthdev-misc/wiki/Building-Qt-v5.6-Statically-on-Windows

                      lonnieL Offline
                      lonnieL Offline
                      lonnie
                      wrote on last edited by lonnie
                      #10

                      @mrjj This is for 5.6 and we are at 5.9. The article even says that 5.8 crashed MSVC. It then says it is as easy as 1-2-3 except that each one has substeps. It details the build tools and you are supposed to download and install them. Apparently OpenSSL is a bear so be careful. To me this look like a project that will take a week, with more than a few attempts, especially since it is all new territory with 5.9, compounded by the fact I am coming at this with no QT history.

                      Sorry, but QT experts should be doing this so guys like me can do what we do. It is just such a waste of time. I want to use it, not build it. The experts have many years of low level tinkering and they know what they are doing, and probably enjoy. I say they enjoy it because otherwise they would have done an automated system years ago.

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

                        Sorry, but QT experts should be doing this so guys like me can do what we do.

                        Well, yes it would be nice if the money was endless and such solutions could be a click away.
                        Also for all the ARM boards. Cross compiling is hard for beginners too.

                        But there is no money in it. So hence its not that interesting as its not a open source project with people
                        spending some free time making it. No - its a real job and there must be money for wages etc.

                        And yes, static compile is not always very fun but its also same
                        procedure to customize modules etc in Qt so its good learning process.

                        If you buy a Qt license , they will gladly help you compile Qt as static.

                        But we could as a community make some static versions available.
                        Its possible to copy around if Qt is installed in same place.
                        But here is the kicker, to use static linking, you app must be open source or
                        you must own Qt license. Hence for all us freeloaders, static is not that exciting :)

                        lonnieL 1 Reply Last reply
                        1
                        • mrjjM mrjj

                          Sorry, but QT experts should be doing this so guys like me can do what we do.

                          Well, yes it would be nice if the money was endless and such solutions could be a click away.
                          Also for all the ARM boards. Cross compiling is hard for beginners too.

                          But there is no money in it. So hence its not that interesting as its not a open source project with people
                          spending some free time making it. No - its a real job and there must be money for wages etc.

                          And yes, static compile is not always very fun but its also same
                          procedure to customize modules etc in Qt so its good learning process.

                          If you buy a Qt license , they will gladly help you compile Qt as static.

                          But we could as a community make some static versions available.
                          Its possible to copy around if Qt is installed in same place.
                          But here is the kicker, to use static linking, you app must be open source or
                          you must own Qt license. Hence for all us freeloaders, static is not that exciting :)

                          lonnieL Offline
                          lonnieL Offline
                          lonnie
                          wrote on last edited by
                          #12

                          @mrjj You have identified the deal breaker. Not only would I have to generate statics for Windows, but each and every platform.

                          I am an application developer who is willing to pay money to the tools developers for their work, but in essence all I get is what they give freely to everyone. They seem unwilling to develop the tools that commercial developers need. They simply want the money.

                          If I want that Holy Grail of static linking I have to become a QT Tools developer and do their job for them, while paying for the privilege of doing it. That is time where "my" project sits and has no progress.

                          As I said QtCreator is an awesome tool. While it is different than Visual Studio, I feel it is superior in many ways. Someone has spent a LOT of time on the Documentation and you can find the nitty gritty on any class or procedure with the click of a button. That is such a good thing while the main development is happening, BUT, and this is a big but, they are sadly lacking for the actual deployment. That, in short, is a waste of my time (and money). The sheer volume of GUI controls is exciting, although most projects will use the basic 4 or 5. They provide a huge assortment of examples, ad all will build and run and serve as an education. Let us not forget the real goal here, though, and that is to provide a product that I can earn a living from. I am not independently wealthy and do not do this just for fun. I have bills to pay. I like to eat.

                          As it stands QT is interesting, but it cannot be the way forward for me. I have done the research and this topic has been front and center for 7+ years, with no solution except the advice to build QT for static, from ancient instruction which in effect say that from version to version the building process breaks down. How can a newcomer be expected to handle that?

                          I will likely keep a copy of QT installed, for fun. I am, however, evaluating JUCE, and talk about a stark contrast. It lacks all of the spit and polish, BUT the final build process is merely a few mouse clicks and I can choose which environments to support and it builds the projects files for them all. It even gives a choice of which IDE to support if there are choices.

                          QT could have this and more, but they are ignoring this one important issue. I apologize for the length and rant nature, but I felt it important to try and present my reasons, rather than simply throwing my hands up. I am a newcomer to QT but have been programming since the 1970's, so I have a fair idea what I want.

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

                            Hi
                            Well if static linking cross platform is a must have, then Qt might not be the right tool for the job.
                            Most/many of us use DLLS/so files anyway to shared features etc so static linking is not important as
                            the exe size gets MASSIVE and loads slowly as all features are loaded at once
                            and not on a need to use basic. (dynamic loading).

                            I agree for small tools etc. static linking is a super convenience.

                            i hope JUCE does what you need.

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

                              Hi,

                              While I understand your reasons and respect your long career in the field, let me bring some points to the pile that might not be obvious at first sight:

                              Fist one is related to the activity you mention you have: encryption. Some country imposes restrictions on development/importation of software using or implementing such stuff. That's why Qt only dlopens OpenSSL by default. So you can still build application using OpenSSL but if not, you don't have to worry about distribution.

                              Just for that use case, you would need two different static Qt builds per platform/compiler combo and one of them should only be distributed to country not imposing these restrictions.

                              Then let's take a Windows specific issue: static vs dynamic runtime, which one do you chose ? If you say both, then you have to again double the number of packages.

                              One detail that you also don't take into account is that each package released is also tested by human beings. If you ignore the OpenSSL issue, select only one runtime and thus only build one static package per platform/compiler combo, then you "only" double the time they have to spend to test them. That also ignores the CI system that does the integration of all the patches provided which also means it runs all the tests several times a day. With all the platforms currently supported, there's already a lot of stress on the system.

                              Then for embedded systems running Linux, one simple example: the Raspberry Pi -> 3 generations (lets keep the Zero on the side), they all have a different hardware stack with a different CPU-GPU combo, thus it would mean again different builds. And that's only for one brand. Also, what distribution should be targeted ? Raspberry Pi can run several different distributions.

                              Developing for embedded is a world of its own with requirements that can't really be generalised.

                              Let's go back to Windows, up until Visual Studio 2017, there was no backward compatibility hence the numerous package provided for all the supported version of VS. Most of the libraries available on that platform are neither static nor built against the static runtime because it would be way to complicated for the developers to "just use them" because you can't mix the two types of runtime and also because you have to build the complete software stack with the same compiler.

                              On a side note, .lib files on Windows are used for static libraries as well as import libraries when using .dlls. Usually you can spot the difference with the size of the file.

                              One last point: Qt Creator, people tend to forget that this a pretty young project, it's not even half as old as Qt itself which originally was build using Visual Studio and Xcode for macOS. From the start there's been the Visual Studio AddIn to manage Qt projects directly within Visual Studio. Thus yes, the "Qt Wizards" know about Visual Studio which required several version of the plugin to support new releases.

                              All of this and we didn't even scratch an import part: licensing. Take a good look at what your dependencies are using and what it imposes you.

                              That said, I'm joining @mrjj and hope you'll find the framework suiting your needs best.

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

                              lonnieL 1 Reply Last reply
                              3
                              • mrjjM mrjj

                                Hi
                                Well if static linking cross platform is a must have, then Qt might not be the right tool for the job.
                                Most/many of us use DLLS/so files anyway to shared features etc so static linking is not important as
                                the exe size gets MASSIVE and loads slowly as all features are loaded at once
                                and not on a need to use basic. (dynamic loading).

                                I agree for small tools etc. static linking is a super convenience.

                                i hope JUCE does what you need.

                                lonnieL Offline
                                lonnieL Offline
                                lonnie
                                wrote on last edited by
                                #15

                                @mrjj ARRRGGGHHH.

                                That was short lived. JUCE does indeed generate static projects and it is super easy to also have Makefiles built for each and every platform you wish to target, and they actually build and run.

                                Apparently the head JUCE honcho has dictated a certain way to generate the MSVC project files and although it can be compiled it totally breaks Intellisense and ReSharper. He says it is a problem that Intellisense has to fix, and has said this for quite some time. The majority of items are shown as undefined and therefore cannot be inspected. Can you imagine working with someone Else's code and not being to see where and what a function/variable is defined and used? Talk about taking me back to the 1970's, except programs then were TINY and an average person could study and understand them. I hate it when politics and ego enter into development. We need to do the very best we can for the end user and not force our preferences on them. I think we all need to read the book "Programming as If People Mattered". Really, without the end user we truly are wasting our time and money.

                                I just might have to bite the bullet and generate the static files I will need. QtCreator has pretty much everything else I need. Almost certainly, the help system is a HUGE reason, at least for the learning phase.

                                1 Reply Last reply
                                0
                                • SGaistS SGaist

                                  Hi,

                                  While I understand your reasons and respect your long career in the field, let me bring some points to the pile that might not be obvious at first sight:

                                  Fist one is related to the activity you mention you have: encryption. Some country imposes restrictions on development/importation of software using or implementing such stuff. That's why Qt only dlopens OpenSSL by default. So you can still build application using OpenSSL but if not, you don't have to worry about distribution.

                                  Just for that use case, you would need two different static Qt builds per platform/compiler combo and one of them should only be distributed to country not imposing these restrictions.

                                  Then let's take a Windows specific issue: static vs dynamic runtime, which one do you chose ? If you say both, then you have to again double the number of packages.

                                  One detail that you also don't take into account is that each package released is also tested by human beings. If you ignore the OpenSSL issue, select only one runtime and thus only build one static package per platform/compiler combo, then you "only" double the time they have to spend to test them. That also ignores the CI system that does the integration of all the patches provided which also means it runs all the tests several times a day. With all the platforms currently supported, there's already a lot of stress on the system.

                                  Then for embedded systems running Linux, one simple example: the Raspberry Pi -> 3 generations (lets keep the Zero on the side), they all have a different hardware stack with a different CPU-GPU combo, thus it would mean again different builds. And that's only for one brand. Also, what distribution should be targeted ? Raspberry Pi can run several different distributions.

                                  Developing for embedded is a world of its own with requirements that can't really be generalised.

                                  Let's go back to Windows, up until Visual Studio 2017, there was no backward compatibility hence the numerous package provided for all the supported version of VS. Most of the libraries available on that platform are neither static nor built against the static runtime because it would be way to complicated for the developers to "just use them" because you can't mix the two types of runtime and also because you have to build the complete software stack with the same compiler.

                                  On a side note, .lib files on Windows are used for static libraries as well as import libraries when using .dlls. Usually you can spot the difference with the size of the file.

                                  One last point: Qt Creator, people tend to forget that this a pretty young project, it's not even half as old as Qt itself which originally was build using Visual Studio and Xcode for macOS. From the start there's been the Visual Studio AddIn to manage Qt projects directly within Visual Studio. Thus yes, the "Qt Wizards" know about Visual Studio which required several version of the plugin to support new releases.

                                  All of this and we didn't even scratch an import part: licensing. Take a good look at what your dependencies are using and what it imposes you.

                                  That said, I'm joining @mrjj and hope you'll find the framework suiting your needs best.

                                  lonnieL Offline
                                  lonnieL Offline
                                  lonnie
                                  wrote on last edited by
                                  #16

                                  @SGaist said in How to get QtCreator to use static libs for Release?:

                                  On a side note, .lib files on Windows are used for static libraries as well as import libraries when using .dlls. Usually you can spot the difference with the size of the file.

                                  I did NOT know that and always assumed that a .lib was for static linking. I never generate dll files so really only have ever encountered .lib files.

                                  Thanks for cluing me in.

                                  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