QtCreator CMake moc.exe fails to find DLL dependencies
-
I'm getting kits set up in QtCreator after getting a new work PC. Unfortunately after creating one of my kits, the CMake configuration fails for a project that it should work for. It fails when it tries to test 'moc'.
-- Configuring done CMake Error: AUTOMOC for target Calibration: Test run of "moc" executable "C:/Qt/5.6.3/qnx7_armv7/bin/moc.exe" failed. C:/Qt/5.6.3/qnx7_armv7/bin/moc.exe -h Exit code 0xc0000135 CMake Generate step failed. Build files cannot be regenerated correctly. CMake process exited with exit code 1.I still have my old machine and I can see that the environment path is different for the two kits (new machine vs old) but I don't understand why. What's more, only one kit that I've tried to create on the new machine has this problem. Another kit I've created runs moc.exe just fine. That kit has an entirely different system environment (e.g. Path). On the new machine when I run CMake on the project (within QtCreator), it can't find libgcc_s_dw2-1.dll or libstdc++-6.dll. I don't feel like the answer is to try to hunt down these dependent DLLs and add their paths manually to the kit's system environment, but what choice do I have? Why are the two kits I've created on the new machine so far apart in their system environment?
-
When transferring a project to a new computer, make sure your source directory does not include any generated files from a previous computer. In your case, make sure there isn't a CMakeLists.txt.user file in your source directory. That file should be added to your .gitignore file (or similar, depending on your version control), so it doesn't mistakenly get added to your version control.
-
I was hopeful, but that doesn't seem to be the issue. I removed the CMakeLists.txt.usr file, wiped the build folder away and started fresh with the same result:
CMake Error: AUTOMOC for target Calibration: Test run of "moc" executable "C:/Qt/5.6.3/qnx7_armv7/bin/moc.exe" failed. C:/Qt/5.6.3/qnx7_armv7/bin/moc.exe -h Exit code 0xc0000135Do you have any idea why two kits that I have would be different in this way: one can run 'moc.exe' just fine and the other fails to find dependent libraries when it runs 'moc.exe'?
A 'good' kit in this case is one I have an older msvc2013 project. Here's the build environment PATH that QtCreator reports:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\MSBuild\12.0\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64_x86;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Performance Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Performance Tools;C:\Program Files (x86)\Windows Kits\8.1\bin\x64;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64\;C:\Program Files\Eclipse Foundation\jdk-8.0.302.8-hotspot\bin;C:\Perl64\bin;C:\Users\VonRi\AppData\Roaming\ActiveState\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\Bitvise SSH Client;C:\Program Files\Graphviz\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Users\VonRi\AppData\Local\Microsoft\WindowsApps;C:\Users\VonRi\.dotnet\toolsThe 'bad' kit in this case is a QNX kit. Here's the Path that kit seems to get by default:
C:\Qt\5.6.3\qnx7_armv7\lib;C:/qnx700//host/win64/x86_64/usr/bin;C:/qnx700//jre/bin;C:\Program Files\Eclipse Foundation\jdk-8.0.302.8-hotspot\bin;C:\Perl64\bin;C:\Users\VonRi\AppData\Roaming\ActiveState\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\Bitvise SSH Client;C:\Program Files\Graphviz\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Users\VonRi\AppData\Local\Microsoft\WindowsApps;C:\Users\VonRi\.dotnet\tools -
I should also mention that the version of Qt for this kit was built myself and perhaps that has something to do with it. If I open a cmd.exe window and run the 'moc' from that created folder: C:\Qt\5.6.3\qnx7_armv7\bin\moc.exe it fails to find the DLLs it needs. This is not the case for other Qt installs: e.g. C:\Qt\6.2.2\msvc2019_64\bin\moc.exe or C:\Qt\5.6.3\msvc2013\bin\moc.exe.
-
@Rich-v said in QtCreator CMake moc.exe fails to find DLL dependencies:
C:\Qt\5.6.3\qnx7_armv7\bin\moc.exe
I'm not familiar with QNX, is this a cross-compile setup that runs on Windows but compiles for QNX?
-
I got a clue when I finally tried to get a list of all DLL dependencies. In a mingw32 window I got this:
VonRi@PLYL97MP7G3-NR MINGW32 /c/Qt/5.6.3/qnx7_armv7/bin $ ldd moc.exe ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x77b90000) KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x760c0000) KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x75cd0000) msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x76600000) ole32.dll => /c/Windows/System32/ole32.dll (0x75ef0000) ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x76ed0000) RPCRT4.dll => /c/Windows/System32/RPCRT4.dll (0x75fe0000) libgcc_s_dw2-1.dll => /mingw32/bin/libgcc_s_dw2-1.dll (0x6ff30000) combase.dll => /c/Windows/System32/combase.dll (0x75a40000) GDI32.dll => /c/Windows/System32/GDI32.dll (0x77af0000) win32u.dll => /c/Windows/System32/win32u.dll (0x760a0000) gdi32full.dll => /c/Windows/System32/gdi32full.dll (0x76aa0000) libwinpthread-1.dll => /mingw32/bin/libwinpthread-1.dll (0x6ff10000) msvcp_win.dll => /c/Windows/System32/msvcp_win.dll (0x76910000) USER32.dll => /c/Windows/System32/USER32.dll (0x76770000) SHELL32.dll => /c/Windows/System32/SHELL32.dll (0x76ff0000) libstdc++-6.dll => /mingw32/bin/libstdc++-6.dll (0x6f560000)The things it complains about at runtime are mingw32-supplied libraries which of course aren't easy for the system to find if you're not in a mingw32 window.