@naveen13 said in Can't we build Qt with /Zc:wchar_t- flag anymore?: Is there any workaround without altering the Qt source file No. You might provide a patch and see if it gets accepted though.

Attempt # 10 for building on windows [SUCCESS!!] Started from scratch by re-downloading the source and used the subst command 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 . --parallel No issues and everything was installed.

Sorry for not posting before, but I had completely forgotten about this thread!!! The problem is not happening lately; now I'm using Qt Creator 17.0.0 and the latest (as of today) version of MSVC 2022. However, the last times this problem happened I could solved more or less quickly following the steps below: Go to folder %appdata%\roaming. Here, delete subfolder QtProject Still in %appdata%\roaming... I'm not sure about whether deleting subfolder Qt is necessary, since it contains your credentials to log into the Qt websites. Normally, I delete it and when finishing the process I retype the credentials once more. Then go to folder %appdata%\local. Then delete subfolder QtProject. Then go to folder %appdata%\Temp and there delete all files whose name start with "QtCreator-" (there will be quite a few!) Finally, using the Qt Maintenance Tool, uninstall Qt Creator. Once that it's been completely uninstalled, reinstall it again. As I said, this worked for me the last two or three times the problem arised. Can't guarantee that it'll work for everybody! I guess that deleting the files and folder listed above I'm cleaning all traces pointing to MSVC. Uninstalling and reinstalling forces re-creating (hopefully) correctly these links.

@Norzka said in Problems with building qt from source (it doesn't generate lib files): D:\Libraries\Qt\6.6.0\Build\plugins\styles\qwindowsvistastyle.lib Hang on, why do you expect a .lib file for a plugin, that is supposed not to be linked to (it is loaded at runtime)? There should be a .dll, but not a .lib file. Do you (try to) explicitly link against the plugin nevertheless, in your project file? Or do you somehow try a static build (which would require Qt to be built statically, too)?

@JoeCFD Where is it located in the relative /QT folder? /... like 5.12.5 , dist, Docs, Examples

@harveyab said in Show build kit at runtime: use it for conditional compilation If you want to use it for this you will need to know at compile-time, not at runtime. Assuming (I don't know but would guess) that you cannot access the particular kit selected in Creator I would expect to have to test for compile-time defines which come from the kit chosen, e.g. compiler version like _MSC_VER.

so with help of someone from BugReport portal, the solution was extremly simple... as you can see form the log: [image: f6284e81-faef-499d-827b-8550811a27b0.png] C and C++ compler is pucked up from PERL, not form MinGW, so I have onlymoved MinGW environment variables PATH above the PERL and then all worked fine... they also suggested to try specify: -DCMAKE_CXX_COMPILER=C:/path/to/mingw/compiler/g++.exe -DCMAKE_C_COMPILER=C:/path/to/mingw/compiler/gcc.exe but im not sure where to put this realy. other option (im only thinking, was not suggested) is to use MingwDir parameter in configure but not sure if the Qt is this smart enough to use this parameter as a compiler path for C and C++, this has to be tested realy

i resolved this. Perhaps someone will be useful. I had cmake 3.24-rc4 and they broke something with it. Here is the link: https://gitlab.kitware.com/cmake/cmake/-/issues/23759 Rolled back cmake to 3.23.3, everything works fine @SGaist thk for trying to help

This has been fixed in a development release of Creator 8.0.0 beta 2, and can be found here. Marking as solved. Thanks for the help.

In Qt 6.4 (on macos) Debug build does not generate javascript file...

@Christian-Ehrlicher Got it working by myself now, but thanks anyhow for the quick reply. The problem was that i called cmake from within the source not the build dir so it ran cmake for a fresh new build that wasn't already setup from within Qtcreator and did not know where to search for Qt stuff. This is my script now: cd C:\Build\myQtApp\build_r cmake -S Y:/ -B C:/Build/myQtApp/build_r "-DBUILD_TYPE_1:BOOL=ON" "-DBUILD_TYPE_2:BOOL=ON" cmake --build C:/Build/myQtApp/build_r --target all -j2 ... cmake -S Y:/ -B C:/Build/myQtApp/build_r "-DBUILD_TYPE_1:BOOL=OFF" "-DBUILD_TYPE_2:BOOL=ON" cmake --build C:/Build/myQtApp/build_r --target all -j2 The boolean parameters BUILD_TYPE_1 and so on are used inside cmake to add a preprocessor defines that are then used to switch between different build configurations just in case anybody wants to know. In cmake: if(BUILD_TYPE_1) message(STATUS "Build Type: Type 1") add_definitions(-DBUILD_TYPE_1) endif() in c++ #ifdef BUILD_TYPE_1 ... #endif

Hi, AFAIK, it has nothing to do with macOS. Usually the -- means that what follows will by passed as is to a process started by the script / command / other that you are invoking.

@Dmitriano ANDROID_PLATFORM is correct with NDK 21.3.6528147 and NDK 22.1.7171670 but with NDK 23.1.7779620 it is not.

@jsulm Thank you very much! This is exactly the problem, I set up mingw in the environment variable, which caused me to compile MSVC Qt using MINGW

@jsulm Ok, i will check it

thanks for trying to shed some light on this. As I said, I have already installed the vulkan SDK (the "official" one from LunarG as I am trying to build for windows). I have even added the include directory directly in the *.pro file, and have observed that when opening the qt3d project with QtCreator, it can correctly resolve the vulkan libraries, so I think this is not the problem. I will try your suggestion of putting the vulkan headers directly in the qt directory and see if that gets me anywhere..

@Kyeiv said in Could not resolve all artifacts for configuration ':classpath': OpenJDK 9.0.4 You need to use Java 8, see here. Versions higher than 8 might cause issues for the Android SDK command-line tools.