Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler
-
@kyrlon It could be that the path is too long for the MinGW GCC.
At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974 I have a bugreport with a workaround to make gcc accept long paths:
I've used the manifest tool from Visual C++ (mt.exe) to inject this manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!-- Copyright (c) Microsoft Corporation --> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"> <ws2:longPathAware>true</ws2:longPathAware> </windowsSettings> </application> </assembly>with the command line:
mt.exe -nologo -manifest "cc1plus.exe.manifest" -outputresource:"cc1plus.exe;#1"Ninja requires the same treatment, see https://github.com/ninja-build/ninja/pull/2225
wrote on 13 Mar 2024, 17:24 last edited by@cristian-adam I am not too familiar with this. Do I run this in the minGW bin? I do not have a
cc1plus.exeon my system. -
wrote on 13 Mar 2024, 20:05 last edited by kyrlon
Attempt # 7 for building on windows
Decided to use ninja that had fix in it, so I compiled from source on windows and replaced with new ninja in PATH
- Cleared out the build folder and ran the configure.bat like the following:
PS C:\Users\kyrlon\Downloads\qt-everywhere-src-6.6.2\build> ..\configure.bat- Ran the command
cmake --build . --parallel
Got another output fail due to missing header:
C:/Users/kyrlon/Downloads/qt-everywhere-src-6.6.2/qtmultimedia/src/multimedia/windows/qwindowsmediadevices_p.h:19:10: fatal error: qplatformmediadevices_p.h: No such file or directory 19 | #include <qplatformmediadevices_p.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.Attempt # 8 for building on windows [SUCCESS!!]
Trying the suggestion by Christian Ehrlicher, and decided to build in the
C:\path directly, but this required a terminal with ADMIN priv.- Cleared out the build folder and ran the configure.bat like the following:
PS C:\qt6\build> ..\configure.bat- Ran the command
cmake --build . --parallel
SUCCESS! - Ran the command:
PS C:\qt6\build> cmake --install .No issues and everything was installed.
This attempt appears to be successful, but I'm not sure if trying to build from source every time from different machines would allow me to always have access to
C:\. -
Attempt # 7 for building on windows
Decided to use ninja that had fix in it, so I compiled from source on windows and replaced with new ninja in PATH
- Cleared out the build folder and ran the configure.bat like the following:
PS C:\Users\kyrlon\Downloads\qt-everywhere-src-6.6.2\build> ..\configure.bat- Ran the command
cmake --build . --parallel
Got another output fail due to missing header:
C:/Users/kyrlon/Downloads/qt-everywhere-src-6.6.2/qtmultimedia/src/multimedia/windows/qwindowsmediadevices_p.h:19:10: fatal error: qplatformmediadevices_p.h: No such file or directory 19 | #include <qplatformmediadevices_p.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.Attempt # 8 for building on windows [SUCCESS!!]
Trying the suggestion by Christian Ehrlicher, and decided to build in the
C:\path directly, but this required a terminal with ADMIN priv.- Cleared out the build folder and ran the configure.bat like the following:
PS C:\qt6\build> ..\configure.bat- Ran the command
cmake --build . --parallel
SUCCESS! - Ran the command:
PS C:\qt6\build> cmake --install .No issues and everything was installed.
This attempt appears to be successful, but I'm not sure if trying to build from source every time from different machines would allow me to always have access to
C:\.@kyrlon said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
allow me to always have access to C:.
You can also build in your user home folder like c:\users\USER_NAME\QT_BUILD_FOLDER
-
@kyrlon said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
allow me to always have access to C:.
You can also build in your user home folder like c:\users\USER_NAME\QT_BUILD_FOLDER
wrote on 14 Mar 2024, 21:56 last edited by@jsulm Good point. In general, I am aware that this is a Windows problem, but tampering with registry keys to disable the character path limit is not the ideal solution for different systems in use. Since I don't do much development on Windows, I was just wondering if this was a gcc or cmake limitation?
-
@jsulm Good point. In general, I am aware that this is a Windows problem, but tampering with registry keys to disable the character path limit is not the ideal solution for different systems in use. Since I don't do much development on Windows, I was just wondering if this was a gcc or cmake limitation?
@kyrlon Too long paths is a Windows limitation
-
@jsulm Good point. In general, I am aware that this is a Windows problem, but tampering with registry keys to disable the character path limit is not the ideal solution for different systems in use. Since I don't do much development on Windows, I was just wondering if this was a gcc or cmake limitation?
@kyrlon said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
Since I don't do much development on Windows, I was just wondering if this was a gcc or cmake limitation?
Because the path is to long. Use a shorter source and build path and blame MS
Already answered two days ago...
-
wrote on 15 Mar 2024, 08:41 last edited by
@jsulm said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
Too long paths is a Windows limitation
Not quite. Windows has support for long paths (>255 characters) since Windows 10 version 1607 released on August 2015.
But the applications need to opt-in in order to use the new functionality.
It's a tooling problem:
- Ninja - Is fixed but waiting for an official release (1.12)
- GCC - Not fixed.
- Visual C++ - Not fixed.
- moc - Fixed since Qt 6.5.
- make - Not fixed, but forgot to open a bug report.
- clang - Works out of the box.
- cmake - Works out of the box.
So on Windows if you take llvm-mingw and a patched ninja you would be able to compile with clang and Qt 6.5+ just fine.
-
@jsulm said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
Too long paths is a Windows limitation
Not quite. Windows has support for long paths (>255 characters) since Windows 10 version 1607 released on August 2015.
But the applications need to opt-in in order to use the new functionality.
It's a tooling problem:
- Ninja - Is fixed but waiting for an official release (1.12)
- GCC - Not fixed.
- Visual C++ - Not fixed.
- moc - Fixed since Qt 6.5.
- make - Not fixed, but forgot to open a bug report.
- clang - Works out of the box.
- cmake - Works out of the box.
So on Windows if you take llvm-mingw and a patched ninja you would be able to compile with clang and Qt 6.5+ just fine.
@cristian-adam said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
But the applications need to opt-in in order to use the new functionality
Well, yes. But you can also see it as on OS problem if user has to do something special just to be able to use long paths. And I think this is a system wide setting and not per-application.
-
@jsulm said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
Too long paths is a Windows limitation
Not quite. Windows has support for long paths (>255 characters) since Windows 10 version 1607 released on August 2015.
But the applications need to opt-in in order to use the new functionality.
It's a tooling problem:
- Ninja - Is fixed but waiting for an official release (1.12)
- GCC - Not fixed.
- Visual C++ - Not fixed.
- moc - Fixed since Qt 6.5.
- make - Not fixed, but forgot to open a bug report.
- clang - Works out of the box.
- cmake - Works out of the box.
So on Windows if you take llvm-mingw and a patched ninja you would be able to compile with clang and Qt 6.5+ just fine.
wrote on 15 Mar 2024, 17:53 last edited byAttempt # 9 for building on windows
Tried your suggestion, but got the same error of missing file of
qplatformmediadevices_p.h- Cleared out the build folder and ran the configure.bat like the following:
PS C:\qt6\build> ..\configure.bat- Ran the command
cmake --build . --parallel
Buikld stop with missing header file: https://pastebin.com/AZ7zDM2d
I used the version of llvm-mingw:
version of ninja used:
PS C:\Users\kyrlon\Downloads\qt-everywhere-src-6.6.2\build> ninja --version 1.12.0.git -
@kyrlon said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
allow me to always have access to C:.
You can also build in your user home folder like c:\users\USER_NAME\QT_BUILD_FOLDER
wrote on 16 Mar 2024, 15:37 last edited by@jsulm said in Failing to build Qt 6.6.2 from source on Windows 10 with MinGW64 compiler:
You can also build in your user home folder like c:\users\USER_NAME\QT_BUILD_FOLDER
Another alternative is to use a virtual drive using the subst command. I might make this attempt later.
-
Attempt # 9 for building on windows
Tried your suggestion, but got the same error of missing file of
qplatformmediadevices_p.h- Cleared out the build folder and ran the configure.bat like the following:
PS C:\qt6\build> ..\configure.bat- Ran the command
cmake --build . --parallel
Buikld stop with missing header file: https://pastebin.com/AZ7zDM2d
I used the version of llvm-mingw:
version of ninja used:
PS C:\Users\kyrlon\Downloads\qt-everywhere-src-6.6.2\build> ninja --version 1.12.0.gitwrote on 17 Mar 2024, 13:45 last edited by@kyrlon thank you for trying out llvm-mingw.
I'll have a look at this since from my point of view all of the tools should allow for long paths.
-
wrote on 3 Apr 2024, 04:22 last edited by
Attempt # 10 for building on windows [SUCCESS!!]
Started from scratch by re-downloading the source and used the
substcommand to make a new path to build with.- Created a virtual drive to avoid the PATH length limit:
subst a: .\qt-everywhere-src-6.6.2\- created the build folder and ran the configure.bat like the following:
PS a:\build> ..\configure.bat-
Ran the command
cmake --build . --parallel -
Ran the install command afterwards
PS a:\build> cmake --build . --parallelNo issues and everything was installed.
-
C Cesar referenced this topic on 16 May 2024, 20:41