Linking error when building OpenCV 3.0 with CMake and NMake

Question

Trying to build OpenCV 3.0 with CMake and NMake with commnads:

cmake -DCMAKE_BUILD_TYPE=release -G "NMake Makefiles" -DBUILD_SHARED_LIBS=OFF -DBUILD_opencv_java=OFF -DWITH_MSMF=OFF -DWITH_DSHOW=OFF -DWITH_VFW=OFF DWITH_OPENEXR=OFF -DWITH_CUDA=OFF ..

and

nmake

I get

...
-- Configuring done
-- Generating done
-- Build files have been written to: W:/VSONLINE/Passport-Photo/thirdparty/openc
v-3.0.0/build
nmake

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target zlib
[  0%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/adler32.c.obj
adler32.c
[  0%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/compress.c.obj
compress.c
[  0%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/crc32.c.obj
crc32.c
[  0%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/deflate.c.obj
deflate.c
[  0%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/gzclose.c.obj
gzclose.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/gzlib.c.obj
gzlib.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/gzread.c.obj
gzread.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/gzwrite.c.obj
gzwrite.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/inflate.c.obj
inflate.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/infback.c.obj
infback.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/inftrees.c.obj
inftrees.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/inffast.c.obj
inffast.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/trees.c.obj
trees.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/uncompr.c.obj
uncompr.c
[  1%] Building C object 3rdparty/zlib/CMakeFiles/zlib.dir/zutil.c.obj
zutil.c
[  2%] Linking C static library ..\lib\zlib.lib
The system cannot find the path specified.
NMAKE : fatal error U1077: 'cd' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0
\VC\BIN\nmake.exe"' : return code '0x2'

Any idea what am I doing wrong? I have tried with Visual Studio 2010 and 2013 with exactly the same result.

UPDATE If I change the generator to be "Visual Studio 10 2010" or any other version of Visual Studio and then build with msbuild.exe OpenCV.sln it all builds successfully. Is this a problem within nmake or cmake ?

Answer 1

Apparently, this is a known bug ( issue 5496 ), which has been tagged as wontfix . In the comments the user MarianMMX suggested the following work-around:

1. Open CMakeLists.txt .
2. Go to line 70. ( Note: it's line 90 in my case, so better do a text search)

3. Comment (or delete):

    #if(MSVC) # set(CMAKE_USE_RELATIVE_PATHS ON CACHE INTERNAL "" FORCE) #endif() 

4. Delete the generated files and rerun cmake.

I have successfully compiled OpenCV 3.0.0 using nmake (VS2010 and VS2013) after applying the above work-around:

> cmake -G"NMake Makefiles" <other options> <opencv src dir>
...
> nmake
...

Answer 2

This is not an answer, just some debugging I've done. The problem is not with linking. The problem is with the cd commands that are piling up. I haven't been able to find where these are in the CMake scripts, but somewhere, these are going wrong. If you run the CMake configure step with:

 -DCMAKE_VERBOSE_MAKEFILE=true

Then you'll see output like:

[ 2%] Linking C static library ..\\lib\\zlib.lib cd 3rdparty\\zlib C:\\Users\\builder\\Miniconda2\\envs\\_build\\Library\\bin\\cmake.exe -P CMakeFiles\\zlib.dir\\cmake_clean_target.cmake cd ..\\.. cd 3rdparty\\zlib The system cannot find the path specified.

That latter cd line is very fishy - you can't chain two cd's together without some joining character there. Something is going wrong with the NMake generator here - either due to the OpenCV source code, or due to CMake.

If you dig into the build/3rdparty/zlib/CMakeFiles/zlib.dir/build.make file, you'll see why this is happening: all of the cd ..\\..\\ lines have that extra slash, which I think at the end of a line is line continuation, not the end of the path.