I'm starting to look into deploying a Qt application I've been developing but I've never had to deploy any C++ application before this.
I want to be able to ship my product as a pre-compiled executable that dynamically links against shared library files(Qt) for Linux/Windows so that there is an executable that looks in its own sub directories for libraries instead of libraries that may be installed as a result of other Qt products.
Is this something that is possible? Or must the Qt library files be installed separately for an application to link against them? I want to avoid requiring the end user to install ANYTHING on their systems while also avoiding static linking.
This is a normal behavior for Qt. How to do it greatly depends on your build system.
If you use CMake, you can generate installers with CPack. Here is a link to adding the required shared libraries to an installer. CPack makes many different types of installers for Linux, Windows, and Mac OS X.
You can also generate your own installers using NSIS. This is a lot more involved but doable.
Qt has documentation on how to deploy applications that use their libraries.
At my company, we do both CPack and NSIS. The CPack way is a lot easier and there is more examples online.
Related
I'm struggling to deploy my Qt/C++ application, probably because I have not found a good introduction about this online. In brief my question is how do I setup an installation framework which requires only minimal, or preferably no, compilation before shipping to users.
I want to deploy the GUI to users on different platforms, who may or may not have admin rights on their machines. I have found different options:
Statically compile Qt -> statically compile an executable -> distribute the executable. With this setup I have encountered a Windows security warning, which requires admin privileges (I have not yet tried on Linux / macOS). And frankly this approach seems sub-optimal, as my compiler has no idea about how to compile optimally for my users.
Create an installer. But there I start to be confused... Do I need to provide a statically compiled executable of my GUI, or just of the installer, or neither? Or can I avoid pre-compiling on my side all together by using an installer from Qt with built-in compiler/libraries?
With this setup I have encountered a Windows security warning
You didn't sign the binaries. This issue has nothing to do with Qt. You'd face it even when distributing a trivial "Hello World".
Ensure that you sign all of the following:
The executables.
All DLLs that you redistribute and are not signed (verify each one).
The installer.
my compiler has no idea about how to compile optimally for my users.
Since C++ doesn't use just-in-time compilation, this statement is a truism. When you dynamically link your compiler will also have "no idea" how to compile "optimally for your users" if you imply that you need CPU-specific variants of your code. This has to be addressed by having multiple executables, each compiled for a particular CPU, and selecting them on installation. I don't think you meant that, though. But then I have no idea what you mean by "compile optimally for my users".
Do I need to provide a statically compiled executable of my GUI
It's up to you. If you don't provide a statically compiled executable, you will need to provide all of the dependencies: the C++ runtime of your compiler, and all the libraries and plugins needed by Qt.
The procedure for producing a statically linked executable on Windows, Linux and OS X is identical. You start with a statically configured copy of Qt (configure -static -static-runtime), then build it, and then use that to build your application. The end product will be statically linked against C++ runtime and Qt libraries.
Do I need to provide a statically compiled executable of [...] the installer
Only if you compile the installer program yourself using a C++ compiler. Most installer generator packages take care of creating an installer that has no additional dependencies, i.e. you can run it on a bare Windows system.
can I avoid pre-compiling on my side all together by using an installer from Qt
Qt provides no pre-built installers for re-use.
You can use e.g. NSIS to deploy the compiler runtime, Qt libraries and plugins, and your application and any data files it needs.
Or you can statically compile your application so that it has no dependencies and is a single .exe file, and have it as a portable application. It could also self-install, i.e. you could bundle the installer within the application, and on startup the application could detect whether it's already installed, and if not it'd relaunch itself in administrative mode and perform the installation.
Obviously you need to build your application on each platform you want to distribute it to. Easiest way is to link all the QT libraries dynamically to your application. After that all you need to do is provide your application (as in exe file on windows, or executable on linux etc) and the QT libraries you used (DLLs on windows, SO file I think on linux etc)
For example (on windows) if your app is called MyApp and uses QTGui, QTWidgets and QTNetwork, then you have the following files to distribute:
MyApp.exe
QTCore.dll and few other DLLs needed called icu*.dll something, can't remember)
QTGui.dll
QTWidgets.dll
QTNetwork.dll
and you can zip them all in one zip, create an installer etc.
EDIT Few notes after the follow up in the comment.
The standard library (what you called default library that has vector class) is part of the c/c++ runtime (on windows) or installed on linux systems etc, so no, you don't have to worry about this. I can't say for all compilers but for some you can specify a flag/parameter to link this runtime statically (rarely there is a need to do this).
On windows there is a tool called dependency walker, which gives you the list of all DLLs needed for the application to run. On linux systems I don't know, never needed one really. But for your own application, you do know which libraries you need, since you wrote it :)
I'm planing for making setup file in qt creator for some proposes , any way my questions
Dose the release exe required any run-time lib ?
Regareds
If you dynamic link your app, it will need some libraries (if you are developing on Windows, use Dependency Walker to identify all of them).
Also, take a look at the Qt modules your app need to compile: each of them corresponds to a library, which you will need to bundle with your app.
If you are static linking, I believe you may need a smaller number of libraries (those that are not bundled with Qt), but will still need.
Hope it helps.
So I recently got fed up with Windows and installed Linux Mint. I am trying to get a project to build I have in Code::Blocks. I have installed Code::Blocks but I need glew(as well as a few other libraries). I found it in the software manager and installed it. I've managed to locate and include the header files. But I feel like the next step should be relatively straightforward and all over the internet but (perhaps due to lack of proper terminology) I have been as of yet unable to locate an answer.
Do I need to locate the files on my system and link to each library manually? This is what I did on windows but I just downloaded the binaries and knew where they were. I found one library from the software manager and linked to it manually but it just feels like I'm doing it the wrong way. Since it's "installed" on the system is there some quick way to link?
You should use two flags for linker '-l' and '-L'. You can set these flags somewhere in project properties.
The first one '-l' tells linker to link with particular library. For example glew, probably in /usr/lib is a file named libglew.so, when you link your program with '-lglew' flag, it will link it with glew library. Linker looks for libraries in few standard places: /usr/lib, /usr/local/lib and few extra. If you have your libs in nonstandard place, use '-L' flag to point these dirs.
Many linux distributions provide two kinds of packages with libraries, regular ones just with runtime, and devel ones (usually prefixed or suffixed with dev or devel) with header files and development version of libraries.
use build systems, Luke!
the typical way to develop/build software in *nix world is 3 steps:
configure stage -- before building smth you have to realize in what environment you are going to build your software... is everything that required is installed... it wouldn't be good if at compile stage (after few hours of compilation) you (or user who build your soft) got an error: unable to #include the 'xxx.h'. the most popular build systems are: cmake, my favorite after autotools. yout may try also scons or maybe crazy (b)jam...
compile stage -- usually just make all
install stage -- deploy just built software into the system. or other way: build packages for target distro (.deb/.rpm/&etc)
at configuration stage using test scripts (don't worry there are plenty of them for various use cases) you can find all required headers/libraries/programs/compiler options/whatever you need to compile your package... and yes: do not use hardcoded paths in your Makefiles (or whatever you use to make your binaries)
Answer to this question really depends on what you want to achieve. If you want just to build you app by yourself then you can just write path to libraries in your makefile, or your code editor settings. You may not even have to do that as if libraries installed by your linux distribution package manager, headers usually go to /usr/include and libraries to /usr/lib or /urs/lib64 etc. That locations are standard and you do not need to specify them explicitly. Anyway you need to specify libraries you want to link to.
If you want to create application that can be build by others, or by you on many different configurations/environments using something like cmake would be very helpful.
How can i run a program which already has been built and compiled before on Qt IDE, so that i can take that program and run on any computer I want without recompiling it on that computer. I am a beginner so bare answering this question.:)
Thanks
There are a few parts to your problem.
1) You need to compile it for each architecture you want it to be used on.
2) Each architecture will have a set of Qt dynamic libraries associated with it too that need to be available.
3) Some architectures have an easy-to-deploy mechanism. EG, on a mac you can run "macdeployqt" to get the libraries into the application directory. For nokia phones (symbian, harmattan (N9), etc) QtCreator has a deploy step that will build a package for the phone and even include an icon.
4) For systems without such a feature, like linux and windows, you'll either need to distribute the binary and require the user to have Qt available or to package up a directory/zip containing the needed Qt libraries and distribute that.
It doesn't launch because it cannot find the dependencies. As you are on Windows, these libraries can be moved in the same directory as your application. To find which library is missing, use dependency walker
I am pretty sure these libraries are not found:
The Qt dynamic libraries (can be found on Qt bin directory, take the dll)
The C dynamic libraries used for compilation. If you are on creator and use default setting it will be mingw-xxx(can be found in the Qt installation directory, don t know exactly where)
Every Architect has a set of CPU Instructions.
so it's like when you hear a language that you don't understand. like when i speak Arabic To Someone who don't Understand The Language.
Every Architect Has a set of Processor Instructions, The Compiler only convert the code into instruction only understood by The Architecture that your CPU is.
That's Why Python and the most of High level languages Use Interpreter Instead of a Compiler.
But There are some cross compilers like MinGw that Support Cross compiling To Windows (.exe files)
Simply QT Have some libraries important to be in the working directory for your project.
I've compiled Boost and it works just fine. I would like to to copy specific .dll's and .libs into my project for deployment. The problem is I'm having a hard time finding which packages contain the libraries I need. I've looked around but haven't seen any documentation on what's actually inside the compiled libraries.
For instance, if I wanted to use boost:asio and boost::prt_vector in my project, which .dll/.libs should I copy over?
The entire library folder is over 1.2 GB so I'd rather not use the entire thing. I'm using Windows, vs2008.
Any ideas?
Are you deploying your application as an executable or as a project to be compiled by the user? If it is the former, you shouldn't need to send static libraries, as they're linked into your executable. If you build Boost libraries as dynamic libraries, you will need them of course.
But if you're deploying your app as something to be compiled, or if you have Boost DLLs, then as martiall said, you should use BCP.
You can use the bcp which is bundled in Boost
BCP Docs