@oblivioncth said in Building 5.12.1 32-bit static Qt for MSVC on Windows 10: The system cannot find the file specified (qgltf5.pdb).:

C:\Engineering\Development\Qt\Tools\QtCreator\bin\jom -j 8

I wanted to keep the versions for the standard and static versions consistent, but its not like it would really matter since its just a small revision difference. So, I attempted to build 5.12.3 this time and while I was at it I grabbed the dynamically linked version of 5.12.3 from the maintenance tool as well.

This time I ran the Visual Studio Native Tools command prompt as an administrator since I figured that had a shot at mattering even though I didn't see it mentioned anywhere and wasn't doing this is a UAC protected directory.

And... it built completely with no issues and I was able to produced a statically linked version of the app I'm working on like I wanted to. I don't know if there was a bug in the 5.12.3 source, if it actually was running the prompt as administrator, if there was just a simultaneous access issue with some of the files/tools on the last run, or if it was just a fluke, but everything works fine now.

The build ended on the same two lines but succeeded in copying qgltf.pdb instead of not finding it and the process took much longer than the previous attempt, so I'm guessing that there were errors earlier in the process that didn't stop the build script so I didn't catch them.

I meet the same issue today. So i download the older version of Qt.

http://stackoverflow.com/questions/29657213/cannot-statically-build-x64-version-of-qt-lnk1112-module-machine-type-conflicts

http://wiki.qt.io/How_to_build_64bit_Qt_for_windows

Hi and welcome to devnet,

Unless you're using an old version of Qt, the mkspec for VS2015 is already in so you can build Qt with it.

As for jom, you can just call it in place of nmake. Use the full path to the exe and you should be good to go.

Hope it helps

@ankit-thakar said:

@koahnig
Thanks for looking into problem
I got your point. and as you said i had also the same doubt that it was causing due to parallel execution of jom. as a part of solution i thought i need to change in .pro file in such a way that jom can interpret correctly,
Is this ok to implement?
I do not know, since I am not using msvc anymore. My experience is with msvc 2005 and Qt libs, but that is outdated for sure (and also hard to remember)

And one more thing also i found is that When i start debugging using nmake.exe it takes around 10 minutes to just do one step into process and when i am using jom.exe for debugging it takes only 30 sec / 1 min.
i don't know what is the story behind this....(may be jom performs parallel execution that's why)

I do not think that this is directly related. jom is basically a substitute for nmake. The only influence is can imagine is that nmake/jom is started prior to the debugging process. What could have happened is that nmake had to compile your whole project. However, 10 minutes is a pretty long time and requires a larger project I would expect. Anyway you will see in the compilation output, when all is compiled. You can compare then to the procedure with jom. The start of debugging itself should be independent of jom and nmake afterwards. I do not know that there could be an influence of multi-threading on the debugging process. But again I am not using msvc compiler.