Is it possible to build ffmpeg x64 on Windows? - build

The real answer is probably "no", but still, just to double check.
Has anyone ever been able to build ffmpeg x64 on Windows (VS2013 or VS2015)? I know it is not possible with publicly available sources without heavy modifications. However, if somebody did it and if he is willing to share a few tips...
Edit:
It is interesting how most of the required x64 tools for running the "configure" are distributed without dependencies and it is impossible to get them anywhere. Looks like a professional trolling.
Edit2:
There are thousands of errors like this:
fatal error C1083: Cannot open include file: 'features.h': No such file or directory
features.h is missing as many other header files. Is there a fix for that, or switching to Linux is the only option?

I used to compile ffmpeg on a linux machine with MinGW, but now I'm able to compile on a windows machine, in my case Windows 10.
NOTE:
For me it only worked for ffmpeg versions >= 3.0 and I tested using VS 2013 and 2015
Few steps but very important:
Download and install (except YASM):
Visual Studio 2013 or 2015
YASM
MSYS2
Steps:
Install MSYS2 to a fixed folder (eg.: C:\Dev\msys64)
Run msys2.exe
Execute command "pacman -S make gcc diffutils" and press "Y" to install
Close msys2
Rename C:\Dev\msys64\usr\bin\link.exe to some other name (eg.: msys2_link.exe)
Copy and rename "yasm--win64.exe" to "C:\Dev\yasm.exe"
Add "C:\Dev" to environment variables PATH
Run VS2013/2015 x86 (for x86) or x64 for (x64) Command Prompt
Execute "C:\Dev\msys64\msys2_shell.cmd -msys -use-full-path"
On the msys2 window execute "which cl" and you should see the path of your VS
Execute "which link" and you should also see the path of your VS
Go to the ffmpeg source path (eg.: "cd /c/ffmpeg3.3")
Run ./configure and make
I use this configuration:
./configure \
--toolchain=msvc \
--arch=x86_64 \
--enable-yasm \
--enable-asm\
--enable-shared \
--enable-w32threads \
--disable-programs \
--disable-ffserver \
--disable-doc \
--disable-static \
--prefix=/c/ffmpeg3.3/DLLS
NOTE2:
If you used the last line --prefix=/c/ffmpeg3.3/DLLS, as a final step, run make install and the binaries will be copied to that path
Hope it helped.
Best of luck

Assuming with x64 you mean the standard 64-bit version, yes it is possible. See the fate page for all tested builds of FFmpeg, there's various 32- and 64-bit versions of Visual Studio in that list, including VS2013 and VS2015 64-bit. Search for "Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64" (or "19.00.24215.1") or "VS2013"/"VS2015", all the way at the bottom. For exact build options, see here for 2013 or here for 2015. The important part is to open a Windows shell with the 64-bit commandline build tools in your $PATH and open a msys shell from there, and then run configure using the --arch=x86_64 --target-os=win64 --toolchain=msvc options. For more detail, see the MSVC compilation wiki page.

No, it cannot be done. MS compiler doesn't support #include_next. Plus, many other problems... You need MinGW.

There is a How-to on the FFmpeg Page itself.It didn't work for me so far, but at least you should get rid of the C99 Errors and so on.
https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC
Maybe you try installing this stuff (I had to download pkg-config seperatly with Msys2 for it to work) and follow these steps.

Related

How to compile GMP for windows using Visual Studio

I am trying to install gmp on windows. I have found the mingw way of compiling from sources on windows.
But was unable to find binaries fro gmp 6.1.2 or visual studio project in order to compile from sources.
So the question is: Where can I download the gmp 6.1.2 binaries or compile from sources using Visual Studio.
I'll describe three ways of compiling GMP in Windows.
First
Install Visual Studio 2022 Community from this page.
Install VCPKG package manager as described here, basically just do two steps:
git clone https://github.com/Microsoft/vcpkg --depth=1
inside vcpkg directory run
cmd /c bootstrap-vcpkg.bat
Set system environment variable VCPKG_DEFAULT_TRIPLET=x64-windows-static, for doing this press WinKey+Pause, then click "Advanced system settings", then "Environment variables", inside "System variables" click "New" and set value of VCPKG_DEFAULT_TRIPLET to x64-windows-static.
Instead of this step above (setting variable) you can just pass triple directly to all vcpkg commands like vcpkg install gmp --triplet=x64-windows-static.
Inside git directory of vcpkg run following command:
vcpkg install gmp --triplet=x64-windows-static
(you may omit --triplet=x64-windows-static if you set environment variable as I told above)
It will take quite a lot of time, it will compile many packages from sources.
After full compilation is finished it will show in console path to ZIP file with compiled GMP library. On my system ZIP file was created at C:\Users\user\AppData\Local\vcpkg\archives\8d\8d1c08fabf677187083dedd12d6accf7114d91580e75611c065f1674b600bee9.zip.
Unpack this ZIP file and then you can compile your C++ program like following:
cl program.cpp /O2 /GL /EHsc /std:c++latest /Ipath_to_unpacked_zip/include/ path_to_unpacked_zip/lib/gmp.lib
As you might know cl command should be run from "x64 Native Command Prompt" command shell which can be found in "Windows Start Menu / Visual Studio 2022 /".
Also you may install MPIR instead of GMP, this is a fork of GMP, with same interface, but more preferred by Windows users. Just do vcpkg install mpir, but this can be done only if you delete GMP package first, only one of MPIR or GMP can be installed.
Second
This step doesn't compile GMP, but uses precompiled binaries from MinGW installation.
Install Visual Studio as in first step.
Go to home page of MSYS2. Download installer, link is located near "1. Download the installer:" phrase. Install it to any location, e.g. c:\bin\msys\.
After installation in Windows Start Menu go to application "MSYS2 64bit" and inside it start program "MSYS2 MSYS", it will run Unix-like shell, from it do:
pacman -S msys/binutils msys/gcc msys/mingw-w64-cross-crt-git clang64/mingw-w64-clang-x86_64-gmp
This command above will install all needed packages to use GMP. If you need more packages use -Ss option like pacman -Ss clang, this will search for CLang, so -Ss does search and -S installs.
If you need some time later, pacmans -Syu command updates all installed packages, run this command two times, one time updates base system files, second time all other packages (after first time you need to close and open MSYS shell again).
Now you need one tweak, rename two symbols inside library libmingwex.a because of collisions with libucrt.lib library of Visual Studio.
In following two commands I assume that your MSYS installation folder is c:\dev\msys\, you can change to one that you installed to.
c:\bin\msys\usr\bin\objcopy.exe --redefine-sym wcsnlen=wcsnlen_renamed --redefine-sym strnlen=strnlen_renamed c:\bin\msys\opt\x86_64-w64-mingw32\lib\libmingwex.a c:\bin\msys\opt\x86_64-w64-mingw32\lib\libmingwex_renamed.a
(this will create file libmingwex_renamed.a with renamed two symbols out of libmingwex.a library)
Now everything is ready and you can compile your C++ program like following:
cl program.cpp /O2 /GL /EHsc /std:c++latest /Ic:\bin\msys\clang64\include\ c:\bin\msys\clang64\lib\libgmp.a c:\bin\msys\usr\lib\gcc\x86_64-pc-msys\11.3.0\libgcc.a c:\bin\msys\opt\x86_64-w64-mingw32\lib\libmingwex_renamed.a
See that in command above I used 3 libraries libgmp.a and libgcc.a and libmingwex_renamed.a. Also notice that libgcc.a is taked from sub-folder \11.3.0\, it is current version of installed GCC, but when time passes MSYS2 updates GCC to later versions, so this version-subfolder should be changed accordingly.
Third
Install Visual Studio like in First and Second steps.
In this step we will use MPIR, it is a fork of GMP, really good fork more suitable for Windows.
Clone repository:
git clone https://github.com/BrianGladman/mpir --depth=1
Inside folder .\mpir\msvc\vs22\ run:
cmd /c msbuild.bat gc LIB x64 Release
Above command builds Generic version that is suitable for any CPU. After that do
cmd /c msbuild.bat skylake_avx LIB x64 Release
Which builds very optimized version, faster than generic.
Very Important. If second (skylake) builds with failure, then Generic (gc) version can be used but it can be even 5x times slower. If fast Skylake version has failed then better not to use this Third way of compiling GMP, unless you can't do others, or if slow version is enough for you.
This command above should be run as usual from "x64 Native Command Prompt" shell of Visual Studio in Start Menu.
After build is finished GMP (actually MPIR), you can compile your program as:
cl program.cpp /O2 /GL /EHsc /std:c++latest /Ipath_to_mpir_repo\msvc\vs22\lib_mpir_skylake_avx\x64\Release\ path_to_mpir_repo\msvc\vs22\lib_mpir_skylake_avx\x64\Release\mpir.lib
Note that in command above I used \lib_mpir_skylake_avx\ subfolder for optimized AVX version, please use \lib_mpir_gc\ subfolder if only Generic version is available.
Compiling GMP on Windows with VisualStudio might be tricky, however there are already some SO questions, that might help you (depending on your exact use-case):
Building GMP library with Visual Studio?
How to install MPFR and GMP for C++ on visual studio
GMP on visual studio c++
Simple answer is, that there are no sources of GMP compilable directly using VisualStudio as GMP is developed with UNIX in mind.
Summary of your options:
Use GMP version provided in your MinGW distribution
Compile own GMP using MinGW/Cygwin
Use MPIR fork of GMP compilable using VisualStudio
Try to solve all the compilation problems yourself, some hints for older GMP versions are here:
https://cs.nyu.edu/exact/core/gmp/
http://www.blizzhackers.cc/viewtopic.php?t=393933
I faced the same problem in Windows 11 when I needed both gmp and gmpxx for which only the first option works, thanks to #Arty.
The only thing to add is that vcpkg install gmp --triplet=x64-windows-static command should be run in a terminal with admin privilege, otherwise the following error will occur:
file RENAME failed to rename
C:/Users/Desktop/polycut/vcpkg/packages/gmp_x64-windows-static
to
C:/Users/Desktop/polycut/vcpkg/packages/gmp_x64-windows-static_tmp
because: Access is denied.

How to install gcc-arm-none-eabi for MinGW users?

I am interested in taking my C++ program and cross compiling it into something that can run on an ARM MCU. To do this, I am required to have gcc-arm-none-eabi installed. I'm currently on a Windows 7 machine, and so I have installed GCC/make/g++/etc. via MinGW.
From the research I've done, it seems that MinGW does not support this toolchain, which leads me to believe that Windows-based ARM development isn't possible. So I ask: how does one use MinGW to install the gcc-arm-none-eabi toolchain locally?
You can use MinGW for this; you just need to swap out the C++ toolchain for your chosen one. You can still invoke it from the MSYS console, and all your other tools will still work. There's nothing inherent to MinGW or MSYS that makes this "not supported".
Personally I install GCC 4.9 gcc-arm-none-eabi from launchpad.net, mount the toolchain's directory in MSYS then export the paths I need:
mount 'C:\PROGRA~2\GNUTOO~1\4947E~1.920' /foo
mount 'C:\PROGRA~2\GNUTOO~1\4947E~1.920\ARM-NO~1' /foo_local
To discover the short name for the paths, write dir /X at the Windows command prompt. On my machine, the paths above are equivalent to the following, respectively:
C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2014q4
C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2014q4\arm-none-eabi
The mounting only needs to be done once; the export directives may be added to /etc/profile:
export CPPFLAGS="-I/foo_local/include"
export CFLAGS="-I/foo_local/include"
export CXXFLAGS="-I/foo_local/include"
export LDFLAGS="-L/foo_local/lib -mthreads"
export PATH=".:/foo_local/bin:/foo/bin:/bin:/opt/bin"
Then just run g++.
Or of course you can skip all the export business and just invoke your chosen GCC directly:
/foo/bin/g++
If you're using MSYS2, MinGW compliance, you'll be able to install arm-none-eabi-gcc through pacman
You can download it from here: https://www.msys2.org
Follow the instructions to properly setup the environments.
Then use this commands below
pacman -S mingw-w64-x86_64-arm-none-eabi-gcc mingw-w64-x86_64-libwinpthread-git
now you'll also need to add this into PATH,
echo "export PATH=$PATH:/mingw64/bin" >> ~/.bashrc
source ~/.bashrc
Then, you can now call arm-none-eabi-gcc with the MSYS2 shell.
See here for the details of this package https://packages.msys2.org/group/mingw-w64-x86_64-arm-none-eabi-toolchain
ELLCC is another option. You don't necessarily need mingw or mingw-64 installed to run it since it is statically linked. This post talks about using it to target Windows, but the same binary can also be used to target ARM and other processors. It's based on clang/LLVM though, not gcc.

Building Qt5 with Visual Studio 2012 / Visual Studio 2013, and integrating with the IDE

How do you get Qt5 to download and integrate with Visual Studio 2012? What are some of the problems you will encounter, and how do you solve those problems?
UPDATE re. Visual Studio 2013
Successes are reported with Visual Studio 2013 as well, and the notes are being maintained for VS 2013.
Also note that the focus of the question is strongly on just building Qt with Visual Studio. There are also notes about integrating with the Visual Studio IDE
This method is tested to work on Visual Studio 2013. Pre-built binaries using Visual Studio 2012 and 2013 are available here, including OpenGL versions.
Step 1: The Setup
Download and install RapidEE here. RapidEE is a windows environment variables editor. It is extremely useful for the rest of this process (and just in general).
Install the DirectX 11 SDK. It is now part of the Windows 8 SDK, so you first have to install the DirectX 10 SDK, which you can get here (but see warning in next sentence). If you have the Visual C++ 2010 Redistributable Package installed, and you probably do (it is automatically installed along with VS 2010), follow the steps outlined here to assist with the DirectX 10 installation. Once you have the DirectX 10 SDK installed, download and install the Windows 8 SDK here, which contains the DirectX 11 SDK. Yes, this is a pain, but unless you know you have the DirectX 11 SDK, the Qt build will fail.
Install Python for Windows (I've heard 2.6+, working with 3.3) from Python.org or Anaconda Python.
Install Perl for Windows from ActiveState.
Step 2: Gitting (and building) Qt5 (yes, that means Git)
Follow the installation guide for Windows at the qt-project website.
Summary
To summarize the details from the above link and from the following notes (PLEASE SEE FOLLOWING NOTES if you have any errors; they might be answered):
Uninstall Avast (if you have this installed) to avoid build errors. Yes, that literally means uninstall it. Remove it 100% from your system. Deactivating it will not work. See detailed notes below.
Note for the first steps: DO NOT use SmartGit for the first git pull, below (unless you really know what you're doing), as SmartGit's defaults will pull everything, and that's not what you want.
Git for Windows must be installed.
Decide where you want to put the Qt installation, and cd to the directory that will contain the new installation from any Command Prompt window. (Because the process is so fragile and error-prone, I personally put it directly in C:, but this is likely not necessary).
From the above directory, execute:
git clone git://gitorious.org/qt/qt5.git qt5
This is fast. Once complete, you should be on the 'stable' branch, but you can always run git checkout stable after cding into the newly-created qt5 directory, just to be sure. Using git checkout 5.4.1 is confirmed to work with VS2013 64-bit.
Close out of your current command prompt window (if it's not a Visual Studio command prompt window) before proceeding to the next step. This is to make sure you're using the Visual Studio command prompt window in the next steps.
Next run the 32-bit (x86) or 64-bit VS Tools command prompt (depending on whether you're building Qt5 as 32- or 64-bit). To access this, you must find it through the Start menu - go to Program Files -> [Microsoft] Visual Studio 2012/2013 -> Visual Studio Tools, and you'll see it in there with a funny name; the name should include the phrase Native Tools; the 32-bit version will have x86 in the name and the 64-bit version will have x64 in the name.
cd into the newly-created qt5 directory from the step above.
From within the Visual Studio command prompt, the remainder of the Qt submodules must be downloaded:
perl ./init-repository --no-webkit
It takes kind of a while to execute this step, because it has to download a lot, but it's not too terrible on a decent connection.
Then download any remaining OPTIONAL submodules that init-repository does not download - SmartGit works well only starting at this stage (see comments below).
Once the download of Qt is complete, the following command prepares the build environment (it should also be executed using the [32|64] VS Native Tools Command Prompt):
configure -developer-build -opensource -confirm-license -mp -nomake examples -nomake tests -debug-and-release -c++11 -no-warnings-are-errors -platform win32-msvc2012.
Notes on this command line: the c++11 option might not be necessary with the VS2012 compiler, but works with VS2013; the -no-warnings-are-errors is necessary in case you get errors on a 64-bit automatic build of ANGLE; -platform is automatically set to win32-msvc2012, so by default the 32-bit build of Qt is used, and -platform probably does not need to be supplied at the command line (EVEN if you have previous versions of VS installed). For VS2013, use -platform win32-msvc2013.
It takes a few minutes to execute this step, but it's not so bad.
Finally, the command to actually build Qt on the system (also run within the VS Native Tools Command Prompt) is simply:
nmake
Expect to wait hours for the build to complete. If you specified an output folder with -prefix (see notes below), then use nmake install, otherwise that's it.
NOTES:
General Notes
In case you're confused from the above-linked documentation, just an FYI that the ANGLE library will be used (by default) instead of OpenGL, and that's why you had to install DirectX 11, above.
Make sure that you use the VS Native Tools Command Prompt to run all commands from the above link (that is, perl .\init-repository --no-webkit, configure, and nmake). You will use the [32|64] bit command prompt (x86 or x64), depending on whether you are building Qt as 32-bit or 64-bit. If you install perl with the Command Prompt open (make sure it is in the PATH), you will need to restart the Command Prompt for perl to be recognized as a command.
When running "init-repository" (from the steps in the above link), it's not clear from the documentation, but you must execute this via perl; i.e. perl ./init-repository --no-webkit. The configure and nmake commands, however, are called directly.
One very useful option to pass to configure is -mp, which causes Qt to build on multiple cores in parallel, significantly speeding up the (long) build time.
To specify an output folder add the -prefix [outfolder] to the configure command. For example, use -prefix %CD%\output\x64\vc12 would be a suitable output (sub)folder for a 64-bit Visual Studio 2013 (12.0) build.
Unicode Support (ICU)
If you want Unicode support (via ICU), pay special attention to the instructions noted within the link above. In summary, ICU must be built from scratch in VS 2012, as the only prebuilt ICU binaries for Windows are for VS 2010. Building in VS 2012 is painless - simply locate the ICU solution (.sln) in <icuroot>\icu\source\allinone, and build in both Debug and Release mode (either in 32-bit or 64-bit mode, depending on which mode you're building Qt in - DO NOT build in the other bitness, because ICU will overwrite the output folder with the binaries). (The Qt build process will properly locate the debug vs. release build of ICU.) It should build without errors. Then, add the path to <icuroot>\lib as a string entry in a (probably) NEW Windows environment variable called "LIB" (you can use Rapid EE for this; make LIB an "expandable string" in RapidEE even though there's only 1 entry), and also add the path to <icuroot>\include as a string entry in a (probably) NEW Windows environment variable called "INCLUDE". (Note: Adding these paths to the PATH variable will not work.) After Qt is built, you can remove all of these entries you've just added. Also, do add the runtime path to the ICU dll's (<icuroot>\bin) to the environment's PATH variable, or the Qt build process (specifically, when uic.exe runs) will give a deceptive and misleading error. Finally, on the configure command line (below), be sure to add -icu as an additional command-line parameter.
ICU Failure:
Currently, there seems to be a bug building Qt5 with the VS2012 compiler WHEN ICU IS ENABLED. Specifically, qtbase\src\corelib\codecs\qtextcodec.cpp Line 688 (Qt5 v5.02) fails to return a codec for codec name "US-ASCII" (the codec is NULL), causing "lrelease.exe" to crash when trying to dereference the codec later (I have lost track of that file/line number, but it is an obvious dereference of the NULL codec variable). Unfortunately, this means that to my knowledge, WebKit cannot be built with (at least the) 32-bit build of Qt5 with the VS2012 compiler, because WebKit requires ICU.
If anyone is able to build Qt5 with the VS2012 compiler with ICU enabled, please update this Wiki saying so.
ICU Clarification:
If you have ICU in your path, Qt will automatically built it. In other words, the flag "-icu" is there implicitly. However, this causes an error with "lrelease.exe" as mentioned above. So the way around this would be to add the flag, -no-icu to the configure command
Additional Submodules
If you want submodules in addition to the default submodules, you can use SmartGit (or command line) after you complete the init-repository command. SmartGit is perhaps easiest, because you do not need to copy the path to the command line, but can use the user interface directly.
WARNING: DO NOT DOWNLOAD THE OPTIONAL qlalr SUBMODULE, as it will not build in combination with the overall Qt build, and is not necessary for users of Qt, but is only used for internal Qt development.
WARNING: A shell command line, followed by perl .\init-repository --no-webkit, must be used (NOT SmartGit); these steps will properly only download the default Qt submodules. You must not use SmartGit to clone and download the Git files from git://gitorious.org/qt/qt5.git because SmartGit does not currently handle the submodules properly. Instead, open a standard Windows shell command prompt (using any command-prompt application, not necessarily the VS Tools command prompt), and (assuming Git is properly installed on the system; a SmartGit installation might or might not do this automatically; if it does not, go to Git for Windows and install directly) type git clone git://gitorious.org/qt/qt5.git directly from the command line; perhaps follow that with git checkout stable (I'm not sure if this branch is checked out by default); then follow that with the command line perl .\init-repository --no-webkit to pull down the DEFAULT repositories (except WebKit, which requires ICU and ICU seemingly cannot be built in 32-bit Qt5 with VS2012; see comments).
The steps for downloading all necessary Qt source files therefore are:
1. Use a Windows command line to execute the initial git clone git://gitorious.org/qt/qt5.git;
2. Execute perl .\init-repository --no-webkit from within a VS Tools 2012 Command Prompt; and then optionally
3. Use SmartGit (from above link) (or equivalent) to "open an existing project" (choose the Qt5 root folder) and do a Pull from within SmartGit to download any non-default repositories (but do not download qlalr). That's it; you have all necessary and optional Qt files (including submodules) on your system.
If anybody discovers other optional submodules that fail to build and/or are for internal use only (besides qlalr), please update this Wiki to specify them.
In general, the default submodules obtained via perl .\init-repository --no-webkit are sufficient. If you know, or later find out, that you other (non-default) modules, you can always add them later.
General Problems
If at some point you get the error saying that the command "python" (or anything similar) is not recognized, just check that the folder containing python.exe (or the appropriate .exe) is part of the path variable. If it is not, add it (use RapidEE as noted above for convenience) and try what you were doing again. If it is there, make sure you have restarted your command prompt AFTER the addition of the command to the path.
Two other path-related issues are important to note (quoted from the documentation associated with the link above): "Make sure the perl executable is found in the path before the perl executable provided by msysgit, since the latter is outdated"; and "You might not be able to build if sh.exe is in your PATH (for example due to a git or msys installation). Such an error is indicated by qt5-srcqtbasebinqmake.exe: command not found and alike. In this case, make sure that sh.exe is not in your path. You will have to re-configure if your installation is already configured."
During the process, you may encounter an error using nmake on a file. If you do, just go into that directory and force build the problem file. Then begin the nmake process on Qt5 again.
Specific Problems
WARNING: You may need to disable antivirus software AND SANDBOXING during the Qt nmake process (and, to be safe, throughout this entire process). Internally, Qt executes a number of executables that antivirus programs can interfere with (sometimes silently). In particular, if you have any sandboxing software, be SURE to disable sandboxing.
WARNING: AVAST! Sandbox users: Avast Sandbox has a bug in which even when you disable Avast's auto-sandbox, the sandbox will NOT turn off and it will silently sandbox all resource files automatically created by Qt's rcc program during Qt's build process. The Qt build ALWAYS fails for any user who has installed the Avast autosandbox feature, EVEN WITH AUTO-SANDBOXING TURNED OFF. THE ONLY WAY TO OVERCOME THIS ISSUE IS TO COMPLETELY UNINSTALL AVAST! FROM YOUR SYSTEM before building Qt. You can reinstall Avast! after the Qt build is complete.
The compilation of Qt5 can take a long time (hours, even with the -mp multithreading option). Patience.
Step 3: Integrating Qt5 with Visual Studio 2012
Download and install the Visual Studio Qt5 addin. It is in the "Other Downloads" section near the bottom of the page, and will not work with Visual Studio Express.
Open Visual Studio 2012, and go to Qt Options (It's under "Qt5" on the top menu bar).
In the Qt Versions tab, check to see if Qt5 is already there. If it is not, click add, choose a version name (probably a name such as 5.x.x), and navigate to the folder containing qmake.exe (usually C:\Qt\qt5\qtbase).
Exit the Qt Options dialog.
Create a new Visual Studio Project. When you see the New Project dialog, you should see the Qt5 Projects Template option.
Once you have your new Qt Project, right click on it and select "Convert to QMake generated project". Build the project, then right click on it again and select "Convert project to Qt Add-in project". Build again, then run. You should now have a working Qt Project.
Add Qt5 to an existing Visual Studio 2012 VC++ project
This section may or may not work for you. If you run into problems or have additional/better solutions, please leave a comment or edit the appropriate step.
Right-click on your project in VS, and choose "unload project". Right click on the project again, and select "edit [project name].vcxproj". This opens the project file so you can add Qt5 to it.
Go down to the Global PropertyGroup, and add or change the <Keyword> to Qt4VSv1.0.
Reload the project, then right-click and select "Convert project to Qt Add-in project"
Wait for the conversion to finish (it does not take more than a couple seconds), then choose Qt5>Project Settings. Go to the Modules tab, and check the modules you would like your project to rely on (the basic ones are Core, Widgets, and GUI).
Following the steps here, add the directory $(QTDIR)\include.
NOTES:
If at any time you are including windows.h, you need to #define NOMINMAX before doing so to prevent conflict with qdatetime.h.
Once the above steps are done, you can make your project usable by Qt Creator by selecting Qt5>Create basic .pro file.
ENDING NOTES: If you have a question related to the information contained in this guide, please post it as a new question (not an answer here), and the answer or a link to the answer may get added.
I successfully managed to integrate Qt 5.0.2 with Visual Studio 2012 on Windows 7 based on the excellent wiki above and on this qt-project link as well. Since I made some of the steps on a slightly different way, I thought it would be valid to post it in here:
The sequence below should be executed in the exact given order:
0 - Uninstall Avast (if you have this installed) to avoid build errors. Due to an Avast bug, deactivating it will not work;
1 - Install Git (>= 1.6.x);
2 - Install Python (>=2.6.x). [python.org];
3 - Install Perl (>=5.14). [activestate.com];
4 - Install Ruby. [rubyinstaller.org];
5 - Open the Windows 7 Command Prompt (don't use VS2012 Developer Command Prompt by now);
6 - Choose any directory you want for qt5, regarding that NO SPACES ARE ALLOWED for the chosen path. I decided to use the path "C:\qt5";
7 - Back to Windows 7 Command Prompt (in my case, prompting "C:\qt5>") type:
git clone git://gitorious.org/qt/qt5.git qt5
8 - Checkout the stable version:
cd qt5
git checkout stable
9 - You'll probably receive a message confirming that this version is already stable. Close the Command Prompt;
10 - Open Visual Studio's Developers Console (All Programs > Visual Studio 2012 > Visual Studio Tools > Developer Command Prompt for VS2012) and change the current directory to the one you have chosen("C:\qt5" in my example);
11 - Download Qt submodules, ignoring webkit (common source of build errors...):
perl .\init-repository --no-webkit
12 - Now enter this huge command to configure your build properly:
configure -developer-build -opensource -nomake examples -nomake tests -nomake demos -debug-and-release -c++11 -mp -nomake webkit -confirm-license
13 - Next, ensure that the module qlalr will NOT be built. To do this, open Windows Explorer and navigate to your chosen Qt directory ("C:\qt5" in my example) and check if the folder qlalr exists. If so, delete it;
14 - Time to build... Possible build errors would come from secondary modules (such as webkit), which don't affect the main Qt functionality (webkit itself should not be a problem since we've previously set the configuration not to build it). We can then ignore them and also keep the build running on independent modules:
nmake /I /K
15 - To conclude integration, follow the step 3 of the community wiki above("Step 3: Integrating Qt5 with Visual Studio 2012").
Just want to mention that there is a prebuilt version of Qt 5.2 for Visual Studio 2012 available at http://qt-project.org/downloads. So if you don't have a special interest in building Qt 5 from sources you can use the prebuild binaries, too.
There are also several precompiled (x64) binaries for different compiler versions available at the Tver-Soft website.
I was finally able to compile QT 5.1 (git) with QWebKit on Windows 8 x64 using Visual Studio 2012 and figured I'd share my experience with those that had problems as well.
Did step 1 and 2 as stated in the above post. I tried to do step 3 but SmartGit pulled a bunch of extra projects that wouldn't compile with Qt5. I was able to solve most of the problems by cloning from a different fork (e.g. https://qt.gitorious.org/qt/qt3d/), but this became too tedious to do for every extra module, so I decided against compiling any of them.
The post at ICU support in a 32-bit build of Qt5 with the VS2012 compiler causes Qt5 build failure; Webkit is also therefore unbuildable told me how to fix the ICU problem.
Download the source code at http://download.icu-project.org/files/icu4c/51.2/icu4c-51_2-src.zip and add the line
#define U_CHARSET_IS_UTF8 1
to the file %ICU%\source\common\unicode\platform.h , where %ICU% is the path to the ICU source code.
Open %ICU%\source\allinone\allinone.sln file in Visual Studio 2012 and compile. Add %ICU%\bin to your path
set PATH=%ICU%\bin64;%PATH%
Then I ran the following command in the QT root directory
configure -platform win32-msvc2012 -opengl desktop -opensource -debug-and-release -I %ICU%\include -L %ICU%\icu\lib64 -mp -qt-freetype -icu
At this point I started to suspect that no one tried to do what I was doing, because nmake started to complain about unexpected lines in the makefiles (all of which had the extension DerivedSources, e.g. Makefile.JavaScriptCore.DerivedSources and Makefile.WebCore.DerivedSources))
(set PATH=<stuff>;%PATH%) && ....
do the set PATH manually before running nmake and delete the characters up to and including && e.g.
(set PATH=<stuff>;%PATH%) && perl -ne "print $1" css\CSSPropertyNames.in ...
Becomes
perl -ne "print $1" css\CSSPropertyNames.in ...
Finally, one of these files will try to call win_flex.exe (or win-flex.exe) instead of flex. I changed it to flex.exe and everything finally compiled (Had to change it twice, because I think the file got regenerated).
Brief experience with a program that uses QWebKit and linked against this build leads me to believe everything is fine.
--Update--
Just to be complete. According to What does (set PATH=...;%PATH:)=^)%) mean in a Windows shell script, and how can I overcome failure of this line in the context of a Qt5 nmake build? (which points to http://qt-project.org/forums/viewthread/20605) most of the Makefile problems should be solvable by using jsom instead of nmake (although I still wonder about win-flex.exe)
compile Qt 5.5 with visual studio 2015:
1- Modify configure.bat in qtbase directory so it can generate configure.exe (just the first 18 lines)
#echo off
set QTSRC=%~dp0
set QTDIR=%CD%
rem if not exist %QTSRC%.gitignore goto sconf
echo Please wait while bootstrapping configure ...
for %%C in (cl.exe icl.exe g++.exe perl.exe) do set %%C=%%~$PATH:C
rem if "%perl.exe%" == "" (
rem echo Perl not found in PATH. Aborting. >&2
rem exit /b 1
rem )
if not exist mkspecs (
md mkspecs
if errorlevel 1 goto exit
)
rem perl %QTSRC%bin\syncqt.pl -minimal -module QtCore -outdir "%QTDIR%" %QTSRC%
rem if errorlevel 1 goto exit
2- configure -opensource -confirm-license -mp -nomake examples -nomake tests -release -c++11 -no-warnings-are-errors -platform win32-msvc2015 -no-ltcg
3- nmake

Netbeans and MinGW-w64

I'm trying to configure my NetBeans on win7 64bit, to work with the MinGW-w64.
So I put in the %PATH% variable the following paths of the compiler:
C:\mingw-w64-bin_i686\mingw\bin
C:\minGw-MSYS\msys\bin
C:\mingw-w64-bin_i686\libexec\gcc\x86_64-w64-mingw32\4.7.0
Then I opened NetBeans and this was configured:
The configuration in NetBeans
I tried to compile a little test program but I received this error:
g++.exe: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not
found compilation terminated. make[2]: *
[dist/Debug/MinGW-Windows/test.exe] Error 1 make1: [.build-conf]
Error 2 make: ** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 1s)
I do have this file in C:\mingw-w64-bin_i686\libexec\gcc\x86_64-w64-mingw32\4.7.0
what am I missing?
Right, after months of putting this off I've finally sat down and done it. I'll probably make a more detailed post on my blog with pretty pictures but here is a trimmed down SO version which will hopefully be enough for you (and everyone else) to get going with.
Prerequisites
Remove MinGW, MSYS and CMake if you have them and can afford to lose them (we will reinstall MinGW (obv.) and MSYS but not CMake as it doesn't appear to be needed.)
Netbeans or other suitable IDE
64bit Windows.
EnvMan (optional but handy for managing Windows Environment
variables.)
Installation
MinGW-W64 C compiler and MSYS
Download and install MinGW-W64
http://mingw-w64.sourceforge.net/ (link is on the left menu with a
hyperlink called 'WIN64 Downloads'.)
There are a lot of versions which can be a bit complicated. We are
going with mingw-w64-bin_i686-mingw_20111220 (although the numbers at
the end may be different) which basically says we want the version
with the windows binaries.
Once the download is complete (about 300mb so 10min or so) extract to
C:\MinGW-W64 or similar. Make sure there aren't any spaces in the
path!
Download MSYS for MinGW-W64
Took a bit of searching
http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS is the wiki for
it and
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/
is where I found the download and the version I went with was
MSYS-20111123
Once the download is complete extract the files to C:\MSys or
similar. Make sure there aren't any spaces in the path!
Setup
Add 'C:\MinGW-W64\bin' to your Windows PATH variable.
Add 'C:\MSys\msys\bin' to your Windows PATH variable.
Start Netbeans and go to Tools -> Options -> C/C++.
Click 'Add' under 'Tool Collection' and select the base directory of
MinGW-W64 (C:\MinGW-W64\bin).
Select 'MinGW' from 'Tool Collection Family' if it isn't
auto-detected and click 'OK'.
Set the 'C Compiler to C:\MinGW-W64\bin\x86_64-w64-mingw32-gcc.exe.
Set the 'C++ Compiler to C:\MinGW-W64\bin\x86_64-w64-mingw32-g++.exe.
Set the 'Make Command' to C:\MSys\msys\bin\make.exe.
And that should be it!
I should note that I am using the system to compile a library file to be use via JNI so have some additional steps for that which I missed out as they weren't needed here. However I made a quick 'Hello World' program and it compiled and ran nicely.
Happy coding!
I have just downloaded the latest automated build, unzipped it, added the main bin directory to path, and run:
x86_64-w64-mingw32-gcc test.cpp -o test.exe
and
x86_64-w64-mingw32-gcc -fuse-linker-plugin test.cpp -o test.exe
and it works. The same for the i686 variant. Your IDE is doing something wrong. Or you shouldn't have messed with the files. Or you shouldn't have removed the prefixes. Seriously.
PS: You only have to add the main "bin" directory to PATH, all the rest is wrong.
With some searching via your favorite Internet search engine, I have come across a better approach to quickly add MinGW-x64 to a Windows 64-bit system. On the Sourceforge site is MSYS2.
While following the installation directions and obtaining the most up to date packages, there may be a time out at the primary mirror site on Sourceforge. If so, follow the mirror site update directions and update the three pacman text files in the respective MSYS2 directory (e.g. /etc/pacman.d). Then proceed to complete the package updates from the MSYS2 installation directions.
Within the MSYS2 packages are things like gcc, llvm, make, dmake, etc. Here is the command used from the MSYS2 command line shell (e.g. bash) to install the GNU make utility:
$ pacman -S msys/make
The executable location it will be placed is: /usr/bin inside the MSYS2 command shell. As far as configuring Netbeans for where make.exe is located, the Windows path is:
MSYS2 installation directory\usr\bin\make.exe
(e.g. C:\msys64\usr\bin\make.exe).
To successfully build C++ with Netbeans, I used the GNU make package (e.g. msys/make). Then in order to use the default make files that Netbeans manages, and to not interfere with other C++ compilers within your Windows installation (e.g. Visual Studio, Intel, CLang from Visual Studio, etc.), run Netbeans from the MinGW-x64 command shell provided by MSYS2. In this way, the environment variables and other things like:
ls rm mkdir
will indicate successful execution and compilation within the Netbeans internal terminal window. I opened the MinGW-w64 Win64 Shell by navigating to the installed shortcut from MSYS2's installation. Then pasted into the MinGW-x64 shell command line, the Target property value from the Netbeans Windows desktop shortcut:
$ "C:\Program Files (x86)\NetBeans 7.4\bin\netbeans.exe"
And then could finally create the respective debug and release object and executable files. I also modified the Netbeans project output to be within the MSYS2 directory structure. Then run the executable within the MSYS2 MinGW-x64 shell. Running from the Netbeans IDE produces this error message:
Unable to start pty process: The application failed with exit code
-1073741515 (0xc0000135).
If the MSYS2 path were in the computer system's PATH environment variable, then perhaps this error would not happen.

Adding gdb to MinGW

I've gone to http://sourceforge.net/project/showfiles.php?group_id=2435, downloaded the Automated MinGW Installer for MinGW 5.1.4 and at the same time the GNU Source-Level Debugger Release Candidate: GDB 6.8-3. I've then installed MinGW base tools into C:\MinGW. No problem so far.
However when I come to install the gdb debugger it has a lot of files and folders with the same names as some already installed but the files are different to those already installed. e.g C:\MinGW\include\bfd.h is 171 KB but gdb-6.8-mingw-3\include\bfd.h is 184 KB.
How do I add gdb to MinGW without breaking what's already installed?
In a command prompt I browsed to C:\MinGW\bin and ran:
mingw-get.exe install gdb
That fixed it for me. Not sure if it matters but I have C:\MinGW\bin in my path (guess I probably didn't need to browse to C:\MinGW\bin).
The Current Release (5.2.1) version of gdb at the project files page has always worked for me. The download is a stand-alone .exe, you don't need anything else.
But I'll bet the .exe in the 6.8 package will work, too. I'd try using just the .exe, and then if there are problems, try extracting the other files from the 6.8 package. (Though that may cause problems with the rest of the MinGW installation.)
Update: There seems to be a 7.something version. I haven't tested it thoroughly, but it seems to work, even with gcc 3.
Get Wascana Desktop Developer. It combines MinGW, gcc, Eclipse and gdb in one package.
You can safely overwrite the files prepackaged with MinGW with the (newer) ones from the gdb tarball. You can also choose not to overwrite them - just make sure to pick either one set, i.e. avoid mixing files from the older and the newer package.
Most of the offending files are probably not really relevant to you anyway. For example, the files belonging to the libbfd library aren't required for gdb's day to day operation, they're used if you want to extend the debugger or write debugging tools yourself.
At any rate, make a backup of the mingw directory before untarring the new release. It's very easy since MinGW is self-contained in that directory. That way, if anything should malfunction, you can just delete the directory and restore from the backup.
Usually for installing gdb in windows, You have to 2 ways to install:
1) use ready-made binaries that were build and compiled from GNU gdb by some provider (easy to install)
use TDM-GCC binaries provided from the following URL and that is including inturn the gcc complier and also gdb debugger.
http://tdm-gcc.tdragon.net/
use Equation package inside which GNU GDB was already compiled and built.
http://www.equation.com/servlet/equation.cmd?fa=gdb
2) use minimal mingw or cygwin package then after install gdb inside it.
Install either mingw or cygwin inside which GDB is already shipped
Open cygwin or mingw terminal and just type the following to make sure it is already installed
$ gdb --version
Hint: if you did not find gdb installed, simply open the cygwin or mingw package installer and make sure you already check gdb
Hint: getting and installing a debug build of the OHRRPGCE is providing useful information about crashes.
From cygwin or mingw terminal, Start gdb using the following
c:\mingw\bin\gdb.exe program_to_debug.exe
REF: http://rpg.hamsterrepublic.com/ohrrpgce/GDB_on_Windows
The TDM GCC/MinGW32 builds installer includes gdb. It's gcc 4.4.x with all the core binary packages required for basic Windows development, and is widely used without any unusual problems.