Trouble linking against OpenCL library/ies in Cygwin with an NVIDIA GPU - c++

I'm trying to build this small OpenCL project:
https://bitbucket.org/Anteru/opencltutorial/src
on Windows, within Cygwin. It is a toy project with one .cpp file and one kernel to demonstrate the use of OpenCL. So, I download the package and cmake it. I get the error message:
CMake Error at /usr/share/cmake-3.14.5/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find OpenCL (missing: OPENCL_LIBRARY)
Call Stack (most recent call first):
/usr/share/cmake-3.14.5/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
cmake/FindOpenCL.cmake:35 (find_package_handle_standard_args)
CMakeLists.txt:6 (FIND_PACKAGE)
I do not balk at this, and proceed to change my CMakeCache.txt so that instead of:
OPENCL_LIBRARY:FILEPATH=OPENCL_LIBRARY-NOTFOUND
I make it:
OPENCL_LIBRARY:FILEPATH=/cygdrive/c/Program Files/NVIDIA Corporation/OpenCL/OpenCL.dll
(this is the legit path of NVIDIA's OpenCL DLL) Ok, so now CMake configuration concludes successfully. The main.cpp file compiles, but linking fails!:
/usr/bin/c++.exe -Wl,--enable-auto-import CMakeFiles/clTut.dir/main.cpp.o -o clTut.exe -Wl,--out-implib,libclTut.dll.a -Wl,--major-image-version,0,--minor-image-version,0 "/cygdrive/c/Program Files/NVIDIA Corporation/OpenCL/OpenCL.dll"
CMakeFiles/clTut.dir/main.cpp.o:main.cpp:(.text+0x610): undefined reference to `clGetPlatformInfo'
CMakeFiles/clTut.dir/main.cpp.o:main.cpp:(.text+0x610): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `clGetPlatformInfo'
CMakeFiles/clTut.dir/main.cpp.o:main.cpp:(.text+0x659): undefined reference to `clGetPlatformInfo'
CMakeFiles/clTut.dir/main.cpp.o:main.cpp:(.text+0x659): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `clGetPlatformInfo'
and so on, dozens of such errors.
Why am I getting these errors and how can I fix them? Is it a result of ELF/WinPE incompatibility because I'm using Cygwin?
Additional info:
My machine has both integrated Intel Graphics (630 - coffee lake), and a Quadro P1000.
I 've installed CUDA 10.2 and AMD CodeXL installed (never mind why) to their default locations.
Looking for An OpenCL DLL file, I find:
$ locate OpenCL.dll
/cygdrive/c/Program Files (x86)/CodeXL/spies/OpenCL.dll
/cygdrive/c/Program Files (x86)/CodeXL/spies64/OpenCL.dll
/cygdrive/c/Program Files/NVIDIA Corporation/OpenCL/OpenCL.dll
/cygdrive/c/Windows/LastGood/system32/OpenCL.dll
/cygdrive/c/Windows/LastGood/SysWow64/OpenCL.dll
/cygdrive/c/Windows/System32/OpenCL.dll
/cygdrive/c/Windows/SysWOW64/OpenCL.dll

Usually Cygwin programs are Unix like and do not call directly Windows DLLs, that use
a different paragdim.
For example the Cygwin cygwin1.dll provides its own C library different from the
MS C library, this cause the sharing the data problematic specially in the 64bit version where the size of long is different. See
https://cygwin.com/cygwin-ug-net/programming.html#gcc-64
Your Tutorial example can be built in a Cygwin pure enviroment, with the proper OpenCL library
$ cygcheck -cd | grep -i opencl
libOpenCL-devel 2.2.12-1
libOpenCL1 2.2.12-1
$ unzip Anteru-opencltutorial-cb1df4439f83.zip
Archive: Anteru-opencltutorial-cb1df4439f83.zip
inflating: Anteru-opencltutorial-cb1df4439f83/.hg_archival.txt
...
inflating: Anteru-opencltutorial-cb1df4439f83/main.cpp
inflating: Anteru-opencltutorial-cb1df4439f83/test.ppm
$ cd Anteru-opencltutorial-cb1df4439f83
/pub/tmp/Anteru-opencltutorial-cb1df4439f83
$ cmake .
-- The C compiler identification is GNU 7.4.0
-- The CXX compiler identification is GNU 7.4.0
...
-- Found OpenCL: /usr/lib/libOpenCL.dll.a
-- Configuring done
-- Generating done
-- Build files have been written to: /pub/tmp/Anteru-opencltutorial-cb1df4439f83
$ make
Scanning dependencies of target clTut
[ 50%] Building CXX object CMakeFiles/clTut.dir/main.cpp.o
/pub/tmp/Anteru-opencltutorial-cb1df4439f83/main.cpp: In function ‘int main()’:
/pub/tmp/Anteru-opencltutorial-cb1df4439f83/main.cpp:249:9: warning: ‘_cl_mem* clCreateImage2D(cl_context, cl_mem_flags, const cl_image_format*, size_t, size_t, size_t, void*, cl_int*)’ is deprecated [-Wdeprecated-declarations]
&error);
^
In file included from /pub/tmp/Anteru-opencltutorial-cb1df4439f83/main.cpp:10:0:
~~~~~~~^~~~~~
...
[100%] Linking CXX executable clTut.exe
[100%] Built target clTut
The built program seems to run fine
$ ./clTut.exe
Found 1 platform(s)
(1) : Portable Computing Language
Found 1 device(s)
(1) : pthread-Intel(R) Core(TM) i5-8250U CPU # 1.60GHz
Context created

Related

Protobuf ld undefined symbol ~InternalMetadata()

I'm hitting an issue with some fairly basic Protobuf files in a library of mine. This is built as a static library successfully but then when compiling tests (Catch2) and linking to the same protobuf library I'm getting the below undefined symbol:-
[build] Starting build
[proc] Executing command: /usr/local/bin/cmake --build /Volumes/TB3-1/git/skunkworks/herald-for-cpp/build --config Debug --target herald-tests --
[build] [1/1 100% :: 0.182] Linking CXX executable herald-tests/herald-tests
[build] FAILED: herald-tests/herald-tests
[build] : && /usr/bin/clang++ -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names herald-tests/CMakeFiles/herald-tests.dir/test-templates.cpp.o herald-tests/CMakeFiles/herald-tests.dir/test-util.cpp.o herald-tests/CMakeFiles/herald-tests.dir/mesh-tests.cpp.o herald-tests/CMakeFiles/herald-tests.dir/main.cpp.o -o herald-tests/herald-tests herald/libherald.a /usr/local/lib/libprotobuf.a /usr/local/opt/openssl#3/lib/libcrypto.a && :
[build] Undefined symbols for architecture x86_64:
[build] "google::protobuf::internal::InternalMetadata::~InternalMetadata()", referenced from:
[build] google::protobuf::MessageLite::~MessageLite() in libherald.a(modem.pb.cc.o)
[build] google::protobuf::MessageLite::~MessageLite() in libherald.a(mesh.pb.cc.o)
[build] google::protobuf::MessageLite::~MessageLite() in libherald.a(models.pb.cc.o)
[build] ld: symbol(s) not found for architecture x86_64
[build] clang: error: linker command failed with exit code 1 (use -v to see invocation)
[build] ninja: build stopped: subcommand failed.
[build] Build finished with exit code 1
The super interesting thing is it even complains about the missing symbol from the ~MessageLite call when I force SPEED instead of LITE_RUNTIME. Doesn't seem to matter whether I link the library and programme to the dylib or the static lib on my mac, whether the full library or the lite library. Tried both SPEED and LITE_RUNTIME in my proto files with exactly the same result.
I've been struggling with this a while. Any ideas greatly appreciated.
Note: My library's target platform ranges from a container on a server to an embedded hardware device. These particular tests are compiled local (Mac OS X x86_64 Intel Mac in my case currently).
This issue was tracked here and ought to be fixed in the recently released Protobuf 3.21.3.
The library builds that ship with package managers are usually built with NDEBUG defined (-DNDEBUG to the compiler, #define NDEBUG in the code). Usually this just turns off checking assert() macros, but Protobuf keys on this symbol to turn on and off its own internal debugging. It turns out that in release mode the InternalMetadata destructor was always inlined and (with -fvisibility-inlines-hidden in the compiler options) never produced a symbol to link against, while in debug mode it was not always inlined and needed to be linked against.
So trying to build user code that didn't define NDEBUG for the Protobuf headers would result in code that needed to link against that destructor, which wouldn't be in the release Protobuf packaged libraries.
The workaround is to use -DNDEBUG in your application, or to build a debug build of Protobuf to link against, or to use a Protobuf new enough (3.21.3+) or old enough (I think <=3.19) to not have this particular problem.
The only remaining mystery is why the whole Internet noticed this bug in the past few days, when it's been there for much longer.

Build Assimp with Cygwin

i want to build Assimp using cmake with cygwin.
According to cmake documentation,cmake has 7 Makefile generators:
Borland Makefiles
MSYS Makefiles
MinGW Makefiles
NMake Makefiles
NMake Makefiles JOM
Unix Makefiles
Watcom WMake
But there isn't any Makefile generator for cygwin.
How can i build Assimp with cygwin?
building on cygwin, there is an issue on strcasecmp
/pub/tmp/assimp-5.0.1/include/assimp/StringComparison.h:146:14: error: ‘::strcasecmp’ has not been declared; did you mean ‘strncmp’?
146 | return ::strcasecmp(s1,s2);
| ^~~~~~~~~~
| strncmp
https://pubs.opengroup.org/onlinepubs/9699919799/functions/strcasecmp.html
It is due to Cygwin still considering it as an extention
A second problem arise from convoluted C++ templates
[ 37%] Building CXX object code/CMakeFiles/assimp.dir/Importer/IFC/IFCReaderGen1_2x3.cpp.o
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/as: CMakeFiles/assimp.dir/Importer/IFC/IFCReaderGen1_2x3.cpp.o: too many sections (88485)
/tmp/cc95KPdy.s: Assembler messages:
/tmp/cc95KPdy.s: Fatal error: can't write 180 bytes to section .text of CMakeFiles/assimp.dir/Importer/IFC/IFCReaderGen1_2x3.cpp.o: 'file too big'
and we can take the solution from:
https://digitalkarabela.com/mingw-w64-how-to-fix-file-too-big-too-many-sections/
A third problem is
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/as: CMakeFiles/assimp.dir/Importer/StepFile/StepFileGen1.cpp.o: section .xdata$_ZNSt11_Tuple_implILm1EJSt14default_deleteIN6Assimp8StepFile31draughting_callout_relationshipEEEE7_M_headERS5_: string table overflow at offset 10000005
/tmp/ccNl78l4.s: Assembler messages:
/tmp/ccNl78l4.s: Fatal error: can't close CMakeFiles/assimp.dir/Importer/StepFile/StepFileGen1.cpp.o: file too big
and the suggestion to use -O1 from
gcc string table overflow error during compilation
works.
With all of them we can:
tar -xf assimp-5.0.1.tar.gz
cd assimp-5.0.1
cmake -DCMAKE_CXX_FLAGS="-D_GNU_SOURCE -Wa,-mbig-obj -O1" -DCMAKE_C_FLAGS="-D_GNU_SOURCE -Wa,-mbig-obj -O1" .
make
and finally
....
[100%] Linking CXX executable ../bin/unit.exe
[100%] Built target unit

Building a simple C++ project on Windows, using CMake and clang

I'm trying to get a simple 'Hello World' program to build on Windows 10, preferably using CMake and clang. I can successfully compile, link and run the same project if I use the g++ compiler from MinGW, but have problems when I try using clang++.
I have CMake, MinGW and LLVM already installed and accessible in my path:
clang++
clang++: error: no input files
cmake --version
cmake version 3.16.0-rc1
I have set up environment variables for CMake to use clang:
echo %CC%
C:\Program Files\LLVM\bin\clang.exe
echo %CXX%
C:\Program Files\LLVM\bin\clang++.exe
Now when I run cmake with my simple "Hello World" C++ project, cmake complains about not being able to use clang:
cmake -G "MinGW Makefiles" ..
-- The CXX compiler identification is Clang 9.0.0 with GNU-like command-line
-- Check for working CXX compiler: C:/Program Files/LLVM/bin/clang++.exe
-- Check for working CXX compiler: C:/Program Files/LLVM/bin/clang++.exe -- broken
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/CMakeTestCXXCompiler.cmake:53 (message):
The C++ compiler
"C:/Program Files/LLVM/bin/clang++.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/pball/git/bchest/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/mingw-w64/x86_64-8.1.0-win32-seh-rt_v6-rev0/mingw64/bin/mingw32-make.exe cmTC_838da/fast && C:/mingw-w64/x86_64-8.1.0-win32-seh-rt_v6-rev0/mingw64/bin/mingw32-make.exe -f CMakeFiles\cmTC_838da.dir\build.make CMakeFiles/cmTC_838da.dir/build
mingw32-make.exe[1]: Entering directory 'C:/Users/pball/git/bchest/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_838da.dir/testCXXCompiler.cxx.obj
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -o CMakeFiles\cmTC_838da.dir\testCXXCompiler.cxx.obj -c C:\Users\pball\git\bchest\build\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTC_838da.exe
"C:\Program Files\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\cmTC_838da.dir\link.txt --verbose=1
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -fuse-ld=lld-link -nostartfiles -nostdlib -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd #CMakeFiles\cmTC_838da.dir\objects1.rsp -o cmTC_838da.exe -Xlinker /implib:cmTC_838da.lib -Xlinker /pdb:C:\Users\pball\git\bchest\build\CMakeFiles\CMakeTmp\cmTC_838da.pdb -Xlinker /version:0.0 #CMakeFiles\cmTC_838da.dir\linklibs.rsp
lld-link: error: could not open 'kernel32.lib': no such file or directory
lld-link: error: could not open 'user32.lib': no such file or directory
lld-link: error: could not open 'gdi32.lib': no such file or directory
lld-link: error: could not open 'winspool.lib': no such file or directory
lld-link: error: could not open 'shell32.lib': no such file or directory
lld-link: error: could not open 'ole32.lib': no such file or directory
lld-link: error: could not open 'oleaut32.lib': no such file or directory
lld-link: error: could not open 'uuid.lib': no such file or directory
lld-link: error: could not open 'comdlg32.lib': no such file or directory
lld-link: error: could not open 'advapi32.lib': no such file or directory
lld-link: error: could not open 'oldnames.lib': no such file or directory
lld-link: error: could not open 'msvcrtd.lib': no such file or directory
CLANG_~1: error: linker command failed with exit code 1 (use -v to see invocation)
mingw32-make.exe[1]: *** [CMakeFiles\cmTC_838da.dir\build.make:88: cmTC_838da.exe] Error 1
mingw32-make.exe[1]: Leaving directory 'C:/Users/pball/git/bchest/build/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [Makefile:120: cmTC_838da/fast] Error 2
This is a freshly installed Windows 10 PC. It has no Visual Studio nor any Microsoft development tool installed on it. If possible I would prefer not having to install the Visual Studio for example to get the msvcrtd.lib. I am using VS Code at the moment, but this should be independent of the IDE being used.
My question is, what exactly do I have to install apart from LLVM, CMake and MinGW to make my first simple C++ project to build?
You are missing the libraries in the linker flag. These libraries may be found in the following location:
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17134.0\um\x86
The exact path on your system may vary depending on the OS version etc., but you get the idea i believe. After finding the location you can add the path to the compiler flag in the CMakeLists.txt file e.g.,
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Xlinker /libpath:path_to_library")
See related answers:
https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/784047
https://stackoverflow.com/a/48576249/811335
How /libpath flag is used:
https://learn.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath?view=vs-2019
To force Clang to use its own libraries instead of MSVC's, add "-target x86_64-w64-mingw32" to CMAKE_C(XX)_FLAGS.
Beware: you have to do this before CMake identifies the compiler, e.g. either before the first C or C++ project definition in CMake (e.g. before the project() call):
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -target x86_64-w64-mingw32")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -target x86_64-w64-mingw32")
project(MyProject ...)
Alternatively, you can pass it with "-D" to CMake on the command line.
Tested with clang 10.0
If I remember correctly, Clang attempts to use MSVC's standard library on Windows by default, since Clang's own standard library doesn't work on Windows yet.
If you don't have MSVC installed, this causes problems.
The easiest solution is to install MSYS2 and use MSYS2's patched Clang, which uses GCC's libraries by default. As a nice bonus, MSYS2 also comes with an up-to-date GCC version.
Alternatively, you can use -target flag to tell Clang to use GCC's libraries. If I remember correctly, this is done by adding -target x86_64-w64-mingw32 to both compiler and linker flags.
(If it doesn't work, try -target x86_64-w64-windows-gnu, I can't remember which one it is. Replace x86_64 with i686 if you're using a 32-bit compiler.)
Your Clang compiler is probably built to target the MSVC ABI. If I try your scenario, this is my error message:
-- The CXX compiler identification is Clang 9.0.0
CMake Error at C:/Program Files/CMake/share/cmake-3.13/Modules/CMakeDetermineCompilerId.cmake:802 (message): The Clang compiler tool
"C:/Program Files/LLVM/bin/clang++"
targets the MSVC ABI but has a GNU-like command-line interface. This is not supported. Use 'clang-cl' instead, e.g. by setting 'CXX=clang-cl' in the environment. Furthermore, use the MSVC command-line environment.
This was with CMake 3.13 and LLVM 9.0, and trying to use -G "MinGW Makefiles". It works using this:
SET CXX="C:/Program Files/LLVM/bin/clang-cl.exe"
cmake -G "NMake Makefiles" ..
You probably don't need to install Visual Studio, but if you want to use nmake and the MSVC libraries, you definitely need the Windows 10 SDK which is a big download, and it will be installed as well if you decide to install Visual Studio.
On the other hand, The problem seems to be related to the CMake 3.16 version. The above unsucessful tests were made with cmake 3.13, but after that I've upgraded to CMake 3.15.5 and it works perfectly. Here are the exact versions:
> cmake -version
cmake version 3.15.5
> clang++ --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
My build.cmd script:
SET CXX="C:/Program Files/LLVM/bin/clang++.exe"
cmake -G "MinGW Makefiles" ..
So the problem may be with your CMake version, or the MinGW libraries, as your error message is suggesting.

undefined reference to `WinMain' with cygwin and cmake

I am trying to build a executable with cygwin in windows 7 and I get the following error in the linking stage.
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../lib/libcygwin.a(libcmain.o): In function `main':
/usr/src/debug/cygwin-2.3.0-1/winsup/cygwin/lib/libcmain.c:39: undefined reference to `WinMain'
/usr/src/debug/cygwin-2.3.0-1/winsup/cygwin/lib/libcmain.c:39:(.text.startup+0x7f): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `WinMain'
collect2: error: ld returned 1 exit status
I dont understand why it tries to find WinMain. I have a cpp file with int main(int, char**) function defined which is part of the build. I do not understand why it is trying to use libcmain.c, which is part of cygwin during executable creation. I am using cmake and it has following:
add_executable(binary_name ${SOURCE_FILES})
This application need to be a console type application and does not have a GUI.
EDIT:
My main function is as follows.
#include "gtest/gtest.h"
int main(int argc, char **argv) {
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
Three points I would recommend to check:
Check the command line(s) that are called by activating verbose output. See Using CMake with GNU Make: How can I see the exact commands?
Are you sure that you really have only one main() function in your code?
Is the source file containing main() function directly added to the add_executable() call?
Because I just have given your code a try with the latest CMake package available in Cygwin and it seems to work just fine (with and without #include <windows.h> in main.cpp).
In the hope that it might help finding your problem, here is what I've done:
$ export PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin
$ cmake --version
cmake version 3.3.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ c++ -v --version
c++ (GCC) 4.9.3
gcc-Version 4.9.3 (GCC)
GNU C (GCC) Version 4.9.3 (x86_64-pc-cygwin)
GNU assembler version 2.25 (x86_64-pc-cygwin) using BFD version (GNU Binutils) 2.25
GNU assembler (GNU Binutils) 2.25
GNU ld (GNU Binutils) 2.25
$ cmake ..
-- The CXX compiler identification is GNU 4.9.3
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found GTest: /cygdrive/c/gtest-1.7.0/lib/.libs/libgtest.a
-- Configuring done
-- Generating done
-- Build files have been written to: ...
Scanning dependencies of target binary_name
[ 50%] Building CXX object CMakeFiles/binary_name.dir/main.cpp.o
[100%] Linking CXX executable binary_name.exe
[100%] Built target binary_name
$ ./binary_name.exe
[==========] Running 0 tests from 0 test cases.
[==========] 0 tests from 0 test cases ran. (3 ms total)
[ PASSED ] 0 tests.
I've used the following CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
project(binary_name CXX)
enable_testing()
set(GTEST_ROOT /cygdrive/c/gtest-1.7.0)
set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "${GTEST_ROOT}/lib/.libs")
find_package(GTest REQUIRED)
add_executable(binary_name main.cpp)
target_include_directories(binary_name PRIVATE ${GTEST_INCLUDE_DIRS})
target_link_libraries(binary_name PRIVATE ${GTEST_LIBRARIES})
Resulting in the following link line CMakeFiles/binary_name.dir/link.txt:
/usr/bin/c++.exe
-Wl,--enable-auto-import CMakeFiles/binary_name.dir/main.cpp.o
-o binary_name.exe
-Wl,--out-implib,libbinary_name.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
/cygdrive/c/gtest-1.7.0/lib/.libs/libgtest.a
More References
Most references to similar problems where in combination with SDL or far more general:
undefined reference to 'WinMain' with SDL compiling in a native enviroment
Undefined reference to WinMain in Cygwin
g++ linker problem with libcygwin.a -> linker error libcygwin
WINMAIN and main() in C++ (Extended)

cmake error showing nonexistent folder on running in cygwin terminal

I am trying to compile a c++ library g2o in cygwin(in windows 8) using cmake . I created a build folder and when I try to do cmake in that folder it fails with the following error
$ cmake ../
-- The C compiler identification is GNU 4.8.3
-- The CXX compiler identification is GNU 4.8.3
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/share/cmake-2.8.11.2/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "/usr/bin/cc" is not able to compile a simple test program.
It fails with the following output:
Change Dir: /cygdrive/b/g2o/trunk/build/CMakeFiles/CMakeTmp
Run Build Command:/cygdrive/c/Program\
Files/MATLAB/R2009a/bin/win64/gmake.exe "cmTryCompileExec3795381385/fast"
C:/Program Files/MATLAB/R2009a/bin/win64/gmake -f
CMakeFiles/cmTryCompileExec3795381385.dir/build.make
CMakeFiles/cmTryCompileExec3795381385.dir/build
gmake[1]: Entering directory `B:/g2o/trunk/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake.exe -E cmake_progress_report "/cygdrive/b/g2o/trunk/build/CMakeFiles/CMakeTmp/CMakeFiles" 1
Building C object
CMakeFiles/cmTryCompileExec3795381385.dir/testCCompiler.c.o
/usr/bin/cc -o CMakeFiles/cmTryCompileExec3795381385.dir/testCCompiler.c.o
-c "/cygdrive/b/g2o/trunk/build/CMakeFiles/CMakeTmp/testCCompiler.c"
Linking C executable cmTryCompileExec3795381385.exe
/usr/bin/cmake.exe -E cmake_link_script
CMakeFiles/cmTryCompileExec3795381385.dir/link.txt --verbose=1
gmake[1]: Leaving directory `B:/g2o/trunk/build/CMakeFiles/CMakeTmp'
process_begin: CreateProcess(NULL, /usr/bin/cmake.exe -E cmake_link_script
CMakeFiles/cmTryCompileExec3795381385.dir/link.txt --verbose=1, ...)
failed.
make (e=2): The system cannot find the file specified.
gmake[1]: *** [cmTryCompileExec3795381385.exe] Error 2
gmake: *** [cmTryCompileExec3795381385/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:4 (PROJECT)
-- Configuring incomplete, errors occurred!
The interesting thing here is I have cmake 3.0 installed in my machine and the error says cmake 2.8.11.2. I did a search in the pc and cannot find any folder by that name. The system path variable contains the path to correct cmake bin folder also.
I cannot figure out what could be the reason behind this error. Can it be an issue with the cygwin itself? What can I do to avoid this error?
One thing to note, Cygwin has its own copy of CMake, which is what your seeing as 2.8.11.2. That version has nothing to do with the one you have on your Windows machine. Have you tried to use the Windows installed version and not Cygwin?
I think the problem comes from not having all required compiler libraries installed in Cygwin. You could try creating a simple C++ file and try compiling it with gcc directly. If that fails, you've now found out why CMake is failing.
Unless there is a good reason to do so, you should probably consider NOT using Cygwin to run CMake inside Windows. CMake is very capable of producing Visual Studio project files.
The issue, at least for me, was the c compiler not accepting unix style paths.
The solution was to install gcc via cygwin. The packages I installed is gcc-base and gcc-cpp I believe.