From wiki we know
“Support for static Qt builds making it possible to address those use cases that cannot use dynamic linking”
I have tired adding CONFIG += static , but not gonna work .
How to compile code staticaly without compile the whole qt project ?
before Qt5.1.0 we all can compile the code statically after build the qt project
but this time ,qt 5.1.0 wiki said new features include “Support for static Qt”
You need to do a static build of Qt before you can build statically linked applications with it. You have to specify -static when you configure it prior to building. None of the existing pre-built packages supports static linking out of the box.
Keep in mind there is a restriction - you cannot use static linking in commercial applications unless you have a commercial license. But it is ok for testing purposes and open source stuff.
As far as I know this was always possible with Qt?!
Related
I'm using premake5 to build a complex application on multiple platforms. My application links against both static and shared/dynamic external libraries.
There seems to be significant build chain dependencies that break premake generated 'gmake' make files in this case.
Case in Point:
If you mix shared and static libraries in premake 'link' statements, GCC seems to get confused and expect your shared library references to actually be static libraries. When it can't find them the link stage fails. This is normally handled by prefixing your shared libs with '-Bdynamic'. Unfortunately there is no way to tell premake5 that an external link lib is static or dynamic, so you have to manually fixup the make files, which defeats the purpose of a build utility.
This is kind of a showstopper. I don't think you can just feed "-Bdynamic" into the linkoptions because it must be followed by the list of shared libraries.
Seems like a bug in gmake action (or at least a missing functionality)
For those, the best approach is to go to the Premake page on Github (https://github.com/premake/premake-core) and create a new issue.
And if you have the time to provide a small reproductible project (a static lib project, a dynamic one, and an application using both, each with only 1 cpp or some simple stuff + the premake script) and attach it to the issue, it would also be really appreciated (and much easier to treat this issue ^^)
I'm developing a closed source application and to do so in accordance with the LGPL I have to dynamically link Qt's libraries to my application. Does Qt do this by default or do I have to take steps to do so? If that's the case how would I go about doing it?
Qt uses dynamic linking by default.
You'll notice this immediately during deployment to a non-developer machine, because your code will not run without the Qt libraries.
If your concern is the LGPL, just be careful when compiling Qt itself. Most LGPL violations with Qt are not because of static linking (since dynamic is the default), but for compiling Qt with non-default parameters.
LGPL is not just that the library must be provided along your binaries, but also that you specify how your users can build themselves the LGPL part. If you compile Qt yourself and do not use the pre-compiled binaries from the website, you must document that part of your build configuration in your release!
As soon as you get something running on your program, start preparing a release version for a non-developer environment without Qt installed. Your program should fail as soon as you delete the DLLs that you must copy along your program (or whatever format your OS uses).
It does it by default, statically linking seems to be quite involved judging by the many questions on the site regarding it.
I have a CMake project for a Qt based application using plugins.
The standard way to create a plugin is CMake (on all platforms) is with:
ADD_LIBRARY(${PROJECT_NAME} MODULE ...)
This creates a libxxx.so plugin (instead of a libxxx.dylib, if SHARED is used instead of MODULE above).
Now, when running inside an IDE like Xcode or QtCreator, the application works fine, the plugin is loaded and works.
But if I create the .app bundle, the application does not start, saying "libxxx.so is not a valid Qt plugin"! How could be that possible? Maybe some library dependency is not found, but how can i check that? I have used tool -L and I think all the libraries are ok.
You may need a "qt.conf" file in your bundle to tell Qt where the plugins are.
You should read up on CMake's BundleUtilities fixup_bundle function and let it do all that "otool -L" and "install_name_tool" stuff for you.
See this recent related stackoverflow question and answer:
CMake: Copy Frameworks into App Bundle
I was successfully able to compile and run my Qt application. However, when I move the .exe file outside its original path, I found out that I have to manually copy the Qt DLLs (e.g. mingw10.dll, qtcore4.dll). Is there any dynamic way to link these libraries with my application?
I think you mean you want to "statically" link these libraries with your application.
Basically this means that everything will be rolled inside your exe, and you will have no need of those dlls anymore.
There are advantages to to static linking, but there are also disadvantages as well. You should be absolutely sure that this is what you want to do before you go this way.
Check out this link which explains the difference in depth Dynamic Linking vs Static Linking
As for your specific issue, if you are sure you want to use static linking you will have to change your Qt setup to be built statically. By default the Qt distribution is setup to use dynamic linking. There is a handy guide for that here.
Basically when you setup the build you have to run "configure -static" to change all the project settings to use static linking instead of dynamic linking. And then build Qt over again.
You should also verify your Qt license. If you are using the Qt LGPL license and you want to to link statically you will have to include all your object files (.o and .obj) as Mihai Limbășan wisely explained in his comment. If you have bought and paid for Qt, then you have no problem.
If the DLLs are on the PATH for the application, then they will be found and work. So, you could add where your Qt binaries/dlls are into the %PATH% environment variable. If you're going to create an installer for your application, you'll need to either package these libraries in so they're in the bin directory - or you'll have to expect every user to install and possibly compile Qt themselves (hint: go with the first option. :) )
Whats the best way to deploy a QT app? I've read the documentation hosted at trolltech but is it better to link with a static library or the dynamic libraries and have the user install the framework? I don't really want anyone using my app to have to download a 160mb framework just to run a simple gui frontend.
On OS X it's a good way to do a dynamic build and post-process the resulting ".app" with the macdeployqt tool which comes with Qt starting with 4.5.
This will copy the Qt frameworks used by your application into the application bundle, which results in a larger package than building a static version of your application.
Here is what you can do to make sure you get the smallest file size possibly in a dynamic build:
First off, make sure you only include the stuff you need (in the project.pro file's QT += core gui network xml lines).
Open the application bundle and remove any unneeded "Qt Plugins" from the bundle. macdeployqt automatically compies all the Qt plugins in there, which can be kind of bulky.
Make sure you are building your application in release mode. Otherwise your application might be linked against the debug libraries of the Qt4 framework, and they are really big (for instance, well over 90 MB for the debug library vs. 16 MB of a release variant without debugging symbols). This might be what happened in your case.
If you have a large application binary, you can use UPX to compress your executable file by 40-50%.
Other than that, you should use compressed disk images to deploy your application.
One of my projects uses QtGui, QtNetwork, QtCore and QtXml and the resulting bundle is about 16 MB in size.
Hope that helps.
Unfortunately you will have to include the Qt libraries you need into your own bundle, as you cannot expect your users to have Qt installed on Mac (whereas on Linux packaging systems allow you to require at least a given version of Qt.
There is a nice tool to help you with that, which is called macdeployqt. You just need to invoke it on your bundle application and it will pack the required libraries, changing the linkage of your binary to refer to them. Without it, making bundles for Mac is a real pain (it still is, but considerably less though).
http://doc.trolltech.com/4.6/deployment-mac.html#the-mac-deployment-tool
Afterwards, you can make a .dmg image as you would do with any other app. There is an option in macdeployqt that builds a basic one.
On Linux, it's better to rely on the OS's copy of Qt, as it's almost certainly installed - for OS X, almost all apps use a statically compiled library.