How to get QtCreator to use static libs for Release?

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.

jsulm

@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.

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.

karlheinzreichel

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

dynamic linking : You link the qt creator files against the Qt-Export-Libraries
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

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

jsulm

@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?

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.

jsulm

@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.

mrjj

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. :)

lonnie

@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.

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 :)

lonnie

@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.

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.

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.

lonnie

@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.

lonnie

@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.