Neither Jom nor nmake work anymore
-
The source code I am working with was updated and I pulled the commit from SVN.
This was built fine on another Windows machine using MingW, but this one uses VS2013 and it did not build. Lots of linker errors for no obvious reason.
I closed QtCreator and when re-started it, it no longer tried to build.
Instead it threw the errors:17:41:50: Starting: "C:\Qt\Tools\QtCreator\bin\jom.exe" C:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Debug link /NOLOGO /DYNAMICBASE /NXCOMPAT /DEBUG /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /MANIFEST:embed /OUT:debug\MandelbrotQt.exe @C:\Users\user0\AppData\Local\Temp\MandelbrotQt.exe.15864.47.jom 'link' is not recognized as an internal or external command, operable program or batch file.After turning off
jomin the settings:17:35:45: Running steps for project MandelbrotQt... 17:35:45: Configuration unchanged, skipping qmake step. 17:35:45: Could not start process "nmake.exe" Error while building/deploying project MandelbrotQt (kit: Desktop Qt 5.6.0 MSVC2013 64bit) When executing step "Make" 17:35:45: Elapsed time: 00:00.It sounds like
linkdisappeared andnmakedoes not exist at all. I was building on this machine for at least a week without issues. Does anyone have any idea why it cannot link anymore? -
Hi,
Might be a silly question but do you have Visual Studio 2013 installed on that machine ?
-
Not silly at all: Yes and no.
This may sound strange, but the only version of VS that were intentionally installed were 2005, 2008, 2010 and 2012. They are listed in this order under Programs and Features.
But after installing AMD OpenCL SDK I suddenly have VS 2013 installed and it is now registered as a default association for the.slnfiles.
Is it messing up Qt kits? -
Looks strange to say the least. Microsoft is the only Visual Studio provider.
Is it really a full VS 2013 installation ? Or did just the OpenCL SDK modify some stuff ?
-
Not silly at all: Yes and no.
This may sound strange, but the only version of VS that were intentionally installed were 2005, 2008, 2010 and 2012. They are listed in this order under Programs and Features.
But after installing AMD OpenCL SDK I suddenly have VS 2013 installed and it is now registered as a default association for the.slnfiles.
Is it messing up Qt kits?@nulluse
Are you sure you're not mistaking the MSVC runtimes with visual studio? It'd be very, very odd to have so many visual studios installed ... and also it would explain why a new entry has appeared after installing the AMD SDK, they (AMD) may bring and install the redistributables with their installer. -
It appears as if AMD OpenCL SDK absolutely devastates this machine.
Uninstalled and everything worked again. And it is not even the fact that it adds path values over 2048 characters - it simply destroys Visual Studio and it has to be repaired from media even if I restore the path to the original.It does not seem to have any negative effect on another Windows 7 machine I use for development, but it has MingW and no VS, so it's VS thing only. Anyhow, removing OpenCL SDK and repairing VS restored the ability of Qt Creator to build the project (having commented out OpenCL stuff of course).
-
It appears as if AMD OpenCL SDK absolutely devastates this machine.
Uninstalled and everything worked again. And it is not even the fact that it adds path values over 2048 characters - it simply destroys Visual Studio and it has to be repaired from media even if I restore the path to the original.It does not seem to have any negative effect on another Windows 7 machine I use for development, but it has MingW and no VS, so it's VS thing only. Anyhow, removing OpenCL SDK and repairing VS restored the ability of Qt Creator to build the project (having commented out OpenCL stuff of course).
And it is not even the fact that it adds path values over 2048 characters
The length of the path is inconsequential. I just recently had to look up the limits, so here they are.
-
Those are the registry key limits, PATH is different.
It's 32KB for the OS and applications, but 2048 for CMD.EXE
And if your PATH is set to > 2048 characters, CMD will behave unpredictably so it seems. In my case it thought there was the 1st path before the semicolon there only and nothing else.Everything running in the CMD window was affected and acted as %windir%* did not exist.
Robustness of MS software knows no limits (lower ones).
-
Those are the registry key limits, PATH is different.
It's 32KB for the OS and applications, but 2048 for CMD.EXE
And if your PATH is set to > 2048 characters, CMD will behave unpredictably so it seems. In my case it thought there was the 1st path before the semicolon there only and nothing else.Everything running in the CMD window was affected and acted as %windir%* did not exist.
Robustness of MS software knows no limits (lower ones).
Those are the registry key limits, PATH is different.
The PATH is a registry value.
And if your PATH is set to > 2048 characters, CMD will behave unpredictably so it seems.
I don't develop actively on windows, but I read on the internet the same thing. However on my development win (win 7) the path was over 2048 characters and I don't experience anything unusual. I would like to see what M$ says on the matter, but wasn't able to find anything definitive for the PATH in MSDN.
Robustness of MS software knows no limits
Amen!
