The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15395 ====================================================================== Reported By: Daniel Richard G. Assigned To: ====================================================================== Project: CMake Issue ID: 15395 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-02-09 14:57 EST Last Modified: 2015-02-09 14:57 EST ====================================================================== Summary: NMAKE circa MSVC6 + Unix Makefiles + big project = "fatal error U1054: cannot create inline file" Description: I am building a large project using CMake 3.1.2 with the Visual Studio 6 toolchain. As the IDE has not proven stable for automated building, I am using the Unix Makefiles generator with NMAKE+CL.
The project build consistently fails part-way through with an error of the form [ 35%] Building C object src/lib/CMakeFiles/foo.dir/bar/baz/baz_qux.c.obj src\lib\CMakeFiles\foo.dir\build.make(66114) : fatal error U1054: cannot create inline file 'C:\tmp\nmz02696' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\BIN\NMAKE.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\BIN\nmake.exe"' : return code '0x2' Stop. Here's what I found in my investigation: Each time the build rules use an NMAKE-generated response file with the @<< ... << syntax, NMAKE creates a temporary file in the $TMP directory. The temporary file name has the form nXXNNNNN, where X is a lowercase letter and N is a digit. The first temp file created is e.g. nma12345, then nmb12345, nmc12345. (The numerical part appears to be random, but is consistent for all temp files belonging to the same NMAKE instance. It does not appear to be a PID, but effectively serves the same purpose.) After a while, it gets to nna12345, then nzz12345, it wraps back to naa12345, and then returns to nma12345. These files remain on the filesystem until the originating NMAKE process exits. So in theory, that is a maximum of 26*26 == 676 distinct temp file names that this version of NMAKE can use. Knowing that, the error above is obvious: NMAKE tried to write to an existing temp file that was still in use, and failed. I am able to work around this problem by invoking the following bit of Perl on the CMake-generated build.make file: perl -pi.orig -e 'BEGIN{$i=0} s!(\@<<)(?=\r?\n)!"$1\$(TMP)\\nmake-".($i++).".tmp"!e' /path/to/CMakeFiles/myproject.dir/build.make This assigns explicit temp-file names to the @<< ... << response files, using a naming scheme that does not top out at 676 entries. (It could still be improved, to allow multiple instances of NMAKE to run simultaneously.) Visual Studio 6 may be old, but it's still an effective way to build code that links against the original MSVCRT.DLL. CMake would benefit from knowing its way around this limitation. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-02-09 14:57 Daniel Richard G.New Issue ====================================================================== -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers