How can I make a Qt build that I built with the -prefix parameter portable to other machines? When I copy my build over to a location on a different machine which differs from the location is specified for -prefix on the build machine qmake complains about not being able to find files and from the error messages it is clear that the files are being searched for in the directory that was used as the -prefix parameter on the original build machine. I mean, the builds that come from the Qt maintenance tool obviously do not have this problem since they do not know where they will be installed at.
My configure line is configure.bat -prefix C:\Development\qt-5.8.0-msvc2015-x86 -opensource -debug-and-release -nomake examples -confirm-license
Side question - when I use this build for Visual Studio with this build Qt cannot find qwindows.dll platform plugin. I copied it over to the binary folder under platforms and it works, but how does the installed Qt version get around this without copying anything?
the builds that come from the Qt maintenance tool obviously do not have this problem since they do not know where they will be installed at.
They do have that problem, and the maintenance tool works around it by binary patching the installation paths. You could do so as well. The paths are stored with empty space appended to facilitate this.
There's nothing you need to do to the build itself. Only after you unzip the build on the target machine, you need to patch it. A rudimentary patcher iterates all the files, and replaces the install path prefix with the real path.
Related
I'm attempting to install OpenSSL on Windows 10 for use with Qt development. I've tried installing from multiple sources, adding lines to my .pro file, and adding DLL files next to the built application, yet nothing works.
I've tried building and running the Qt HTTP request example, and that can't use HTTPS either, so it's not an issue with my code or configuration.
So, where should I get OpenSSL for Windows, and what do I do after installing it?
I've done this before.
For starters, you need to build OpenSSL 1.0.2 source code - available here. You'll need to follow the build instructions in the INSTALL.W32 file. And there are some amended instructions in the INSTALL.W64 file for 64-bit builds.
The two primary DLLs you will wind up building are libeay32.dll and ssleay32.dll. (Also copy off the libeay32.lib and ssleay32.lib stub files and corresponding .pdb files).
If your Qt sources are already built for OpenSSL, you can just drop these two DLLs into your Qt Bin folder (or wherever Qt5Networking.dll is loaded for your application).
If your Qt distribution is built from source, you might need to build Qt again with the openssl-linked option. This will enable Qt to be loaded via implicit DLL loading.
LIB=%LIB%;%c:\openssl\out32dll
configure -commercial release -opengl dynamic openssl-linked -force-debug-info -nomake examples -llibeay32 -lssleay32
jom
For a debug build to correspond to debug Qt5 binaries, you'll need to repeat the above steps, except follow the OpenSSL instructions for building debug binaries to the out32dll.dbg folder.
If your qt distribution was built with dynamic openssl loading, you just need to make sure ssleay32.dll and libeay32.dll are in a folder that is in your PATH environment variable.
I'm trying to build a static application on Ubuntu (if it matters, Ubuntu running in a virtual machine in Windows), following the Qt documentation. Accordingly, I have build the libraries from source, using the configuration from the documentation:
./configure -static -prefix /path/to/Qt
There were no error messages from the build from source. I have tried setting the PATH variable in the build environment to the directory that contains my static build files. I've also tried specifying this path in the .pro file's LIBPATH variable. Nevertheless, whenever I build the application, a call to ldd shows that there are still dependencies to the Qt's dynamic libraries. I'm at a loss to understand how I need to configure Qt Creator to fix this.
You should download sources of interested Qt version, configure for static build and compile them yourself.
I wanted to migrate my Qt 4 app to use Qt 5 instead. These instructions failed, due to some differences with how MXE builds Qt 5, including the fact that it uses modularised Qt tarballs, instead of one large tarball.
Here are the full instructions:
Get it:
git clone https://github.com/mxe/mxe.git
Install build dependencies
Build Qt 5 for Windows:
cd mxe && make qtbase
This will first build its dependencies and the cross-build tools;
It should take less than an hour on a fast machine with decent internet access.
Due to the new modular nature of Qt 5, various major Qt components are now in different tarballs. The one selected above, qtbase, should give you enough functionality to run ordinary GUI apps, which is all I needed for my own (smallish) app.
If you want to build all of Qt 5 instead, you'll need to run make qt5 (instead of make qtbase). Note that it will take a lot longer to complete, so be sure that you need the extra functionality.
Get to the directory of your app, and run the Qt Makefile generator tool:
<mxe root>/usr/bin/i686-w64-mingw32.static-qmake-qt5
Build your project:
make
You should find the binary in the ./release directory:
wine release/foo.exe
Some notes:
This was tested on my 64-bit Debian 8, and on Windows of course.
The output is a 32-bit static executable, which will work well on 64-bit Windows.
If you want a 64-bit executable, build Qt with:
make MXE_TARGETS=x86_64-w64-mingw32.static qtbase
The default MXE_TARGETS value is i686-w64-mingw32.static.
The git checkout command is not correct. You now have to get their stable branch or it will fail building.
git clone https://github.com/mxe/mxe.git
should be...
git clone -b stable https://github.com/mxe/mxe.git
That alone fixed all my issues with qtbase building but leaving no qt folder when done. Then qt5 target would fail with obscure errors. Deleted folder, checked out stable and it worked flawlessly.
For those who directly want a GCC10 64bit compiled Qt5 (for filesystem lib for example),
Here are the full instructions:
Get it:
git clone https://github.com/mxe/mxe.git
Install build dependencies
Build Qt 5 for Windows with gcc10 64bits plugin activated :
cd mxe && make MXE_TARGETS=x86_64-w64-mingw32.shared MXE_PLUGIN_DIRS=plugins/gcc10 qt5
After 2-3 hours of build you can build your app (in your .pro directory) :
<mxe root>/usr/x86_64-w64-mingw32.shared/qt5/bin/qmake
Export path of compiler & build your project:
export PATH=<mxe root>/usr/bin:$PATH
make
You should find the binary in the ./release directory & start it with wine (or wine64) :
wine foo.exe
I don't really know why, but I needed to add the MXE compiler directory to the wine path because it's couldn't find the DLLs :
WINEPATH="<mxe root>/usr/x86_64-w64-mingw32.shared/bin/" wine64 foo.exe
If you try to do this, for me work fine!
su
mv mxe /opt/mxe
cd /opt/mxe && make
I used 4.7.2 for the past months. Now I downloaded 4.7.3. Now I am searching to type "configure -static". But I don't know where the hell "the qt path". Can anybody shed a light on this issue.
Download the source package here. Download and install your favorite perl distribution. I must warn you that Strawberry perl comes with its own toolchain and that may get used instead of the MinGW you downloaded. Use ActivePerl if you don't want any trouble, or build it yourself.
Unzip it to say, C:\Qt-source so that there is a configure.exe in C:\Qt-source
Open the toolchain's command prompt
a) If you're using the Visual Studio compiler, search in the "start" menu for a CMD shortcut in the Visual Studio folder. The Windows SDK also has this shortcut.
b) If you're using MinGW, either use the accompanying mingwvars.cmd, or open a command prompt, (Run->"cmd.exe") and type set PATH=C:\path\to\mingw\bin;%PATH%. Try gcc -v to see if it can be found.
Make a build directory, preferable something like C:\Qt. Do set QTPATH=C:\Qt and set PATH=C:\Qt\bin;%PATH% and cd C:\Qt, and type:
..\Qt-source\configure -static
After configure finishes, you'll either have to type nmake (Visual Studio) or mingw32-make.
Go do something else, because it will take a while.
Some tips that result from my experience, and add a bit more to the answer of rubenv:
Pass the install directory as a flag of the configure; be sure to choose a different directory from the one where you have stored a non-static version of Qt!
Some modules will likely cause you troubles when compiling statically because you need to resolve the dependencies statically; one example is webkit, so if you don't need it be sure to disable it
It is generally not a good idea to build the debug symbols into a static library, so I normally debug with the dynamic version, and use the static Qt to generate releases only.
Therefore, my configure looks something like this:
configure -static -prefix C:\Qt\4.8.6_static -no-webkit -release
I was searching a lot through Qt forums and Google for the last few days, but I could not find any obvious answer to this question.
I found the -prefix option (not even documented on Windows) that can be supplied to configure to specify different install directory, but this is not clear separation of the sources and binaries at all, since the build is still done in the source directory and then the files needed for installation are copied to the install directoy. I tried this -prefix option, and came to some problems. (i.e It doesn't copy the .pdb files to the install directory.)
Then I found this link about doing shadow builds but it has the big limitation that the build dir must be at the same level as the source dir.
I'm guessing you didn't try make
install? So try that. It should
install Qt to a separate directory
away from the sources.
Are you saying that after I do configure, I should do nmake install instead just nmake? I know that nmake will process the generated makefiles from qmake and will place them in the source Qt dir, but what nmake install will exactly do i.e in which directory will install the files and how to specify the directory where the files will be installed.
Note that I already do this:
configure -prefix builddir -platform win32-msvc2005
nmake install
The effect of the above two lines was that qt was compiled in the source dir and not directly to my builddir specified with prefix. Then the compiled files were copied in my builddir. I was hoping for something that will build my Qt files directly to the build dir, cause this way I stil need 4 Gb space for my source dir during the compilation. Also the pdb files were not copied to my buildir which is another issue.
Basically, you just have to run configure.exe from your build directory. For example:
mkdir \qt\4.5.2-build
cd \qt\4.5.2-build
set PATH=%cd%\bin;%PATH%
\qt\4.5.2-sources\configure.exe -platform win32-msvc2005
Where sources are in \qt\4.5.2-sources, that would cause the build to go into \qt\4.5.2-build on the current drive.
Also, you must have perl in your PATH, ActiveState Perl is suggested.
I had not previously heard of this limitation where the build and source directories must be at the same level. If you hit this problem you could try working around it by creating a symbolic link (see mklink command).
IIRC on Windows, you have to do a sandbox install, you can't do the UNIX-typical "make install".
There are two options usually for building Qt, -prefix-install and -prefix /foo
You pick one, so if -prefix doesn't allow you to type make install, then I guess on Windows you have to use the -prefix-install route, which is a sandboxed install to the directory you extract Qt to.
I'm guessing you didn't try make install? So try that. It should install Qt to a separate directory away from the sources.
At least the problem with the missing include files (e.g. qscriptengine.h) may by solved by temporary adding \qt\4.5.2-sources\include\Qt to the include path.
I moved the shadow build out of my home folder to a folder in C: and it worked. I know it's weird, but that's what happened. I suspect it must be a bug in syncqt.