Important: Please read the Qt Code of Conduct -

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='' 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 jom in 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 link disappeared and nmake does 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?

  • Lifetime Qt Champion


    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 .sln files.
    Is it messing up Qt kits?

  • Lifetime Qt Champion

    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 ?

  • Moderators

    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.

  • This is a development machine with history, no surprise here.

  • Moderators

    A long, long history it seems ... Anyway, the only thing I could think of that somehow the PATH (or the VS bat scripts providing the necessary environment) somehow got screwed up.

  • 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).

  • Moderators


    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).

  • Moderators


    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


Log in to reply