Cmake cannot find the gcc/g++ compilers

[nlappas]

Hi, I installed build essentials, gcc, g++, cmake, make and I tried to run a simple project.
However I get error messages from CMAKE that the compiler is broken.

:/mnt/c/Users/NAME/Documents/githubLocal/mybuild$ cmake Unix Makefiles -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER=/usr/bin/g++ - DCMAKE_CC_COMPILER=/usr/bin/gcc ..
-- The C compiler identification is unknown
CMake Error at /usr/share/cmake-2.8/Modules/CMakeDetermineCCompiler.cmake:186 (configure_file):
configure_file Problem configuring file
Call Stack (most recent call first):
CMakeLists.txt:59 (project)

 -- The CXX compiler identification is unknown
CMake Error at /usr/share/cmake-2.8/Modules/CMakeDetermineCXXCompiler.cmake:185     (configure_file):

configure_file Problem configuring file
Call Stack (most recent call first):
CMakeLists.txt:59 (project)

-- Check for working C compiler: /usr/bin/cc
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:47 (try_compile):
Unknown extension ".c" for file

/mnt/c/Users/NAME/Documents/githubLocal/mybuild/CMakeFiles/CMakeTmp/testCCompiler.c

try_compile() works only for enabled languages. Currently these are:

C CXX

See project() command to enable other languages.
Call Stack (most recent call first):
CMakeLists.txt:59 (project)

-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/share/cmake-2.8/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:

CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:59 (project)

-- Configuring incomplete, errors occurred!
See also "/mnt/c/Users/NAME/Documents/githubLocal/mybuild/CMakeFiles/CMakeOutput.log".
See also "/mnt/c/Users/NAME/Documents/githubLocal/mybuild/CMakeFiles/CMakeError.log".
nlappas@NIKOS-SURFACE:/mnt/c/Users/Nikos/Documents/githubLoca/mybuild$`

By the way the compilers work properly, when I use them from the command line, they compile source files and link them succesfully. Which gcc and which g++ give me also the correct paths.

[benhillis]

Could you try cloning your git repro into your UNIX user's home directory (cd ~) and try building again?

If this is a public GitHub repro? If so send me the link and I can try this myself.

Thanks!

[nlappas]

I tried a minimal helloworld c++ test program with the corresponding cmakefile that fails for me even in the home directory.
https://github.com/nlappas/CMAKE_BASH_WINDOWS_TEST.git

[mxalbert1996]

Same problem here. I wanted to compile x265 (https://bitbucket.org/multicoreware/x265) and it showed:

-- The C compiler identification is unknown
CMake Error at /usr/share/cmake-2.8/Modules/CMakeDetermineCCompiler.cmake:186 (configure_file):
configure_file Problem configuring file
Call Stack (most recent call first):
CMakeLists.txt:19 (project)

-- The CXX compiler identification is unknown
CMake Error at /usr/share/cmake-2.8/Modules/CMakeDetermineCXXCompiler.cmake:185 (configure_file):
configure_file Problem configuring file
Call Stack (most recent call first):
CMakeLists.txt:19 (project)

-- Check for working C compiler: /usr/bin/cc
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:47 (try_compile):
Unknown extension ".c" for file

/root/Dev/x86_64/x265/build/linux/CMakeFiles/CMakeTmp/testCCompiler.c
...

CMakeError.log:

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /usr/bin/cc
Build flags:
Id flags:

The output was:
1
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o: in function _start' (.text+0x20): undefined reference to main'
collect2: error: ld returned 1 exit status

The C compiler identification could not be found in "/root/Dev/x86_64/x265/build/linux/CMakeFiles/2.8.12.2/CompilerIdC/CMakeCCompilerId.o"
...

Currently using Insider Preview 14332. There were no problem on 14295. Didn't test on 14318.

[mcgoo]

This appears to be caused by the writev system call failing with -EFAULT on WSL and succeeding on linux when passed a struct iovec containing a null pointer.

This program prints nothing on Linux and "bad address" on WSL.

#include <sys/uio.h>
#include <iostream>

//  gcc -std=c++11 main.cpp -lstdc++ && ./a.out

int main()
{
    iovec iov{nullptr,0};
    if( writev(1, &iov, 1) < 0)
        perror(NULL);
    return 0;
}

[benhillis]

@mcgoo Thanks for the awesome debugging! Minor note: Its actually the buffer size of zero that makes the above example work. If you change the size to non zero you will get EFAULT.

I'm actually working on a fix for this right now. I'll be sure to try cmake to make sure it works with my change.

[mcgoo]

@benhillis Yeah, seems like it shouldn't validate the pointer member if the length is zero. I'd expect EFAULT with a null pointer and a non-zero length.

Thanks, WSL is great stuff.

[benhillis]

@mcgoo after fixing the issue with the writev system call that you identified I'm able to build run cmake on the project that @nlappas linked.

@mxalbert1996 I'm trying out https://bitbucket.org/multicoreware/x265 now.

root@BENHILL-VM7:~/CMAKE_BASH_WINDOWS_TEST# cmake .
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /root/CMAKE_BASH_WINDOWS_TEST

[benhillis]

@mxalbert1996 Looks like cmake is finding the C and C++ compilers, but I'm not sure what to do at this screen. If I press 'c' I get an "Errors occurred during the last pass" error.

[aidsjorb]

I'm afraid I don't know what to say on that latest issue but I did get the same cmake compiler errors on both wangle (https://github.com/facebook/wangle) and casablanca (https://github.com/Microsoft/cpprestsdk) if you're looking for other projects to try it out on.

[mcgoo]

@benhillis maybe try

cd ~/x265; mkdir tmp; cd tmp; cmake ../source

and you should be able to see what cmake is complaining about.

[WhiteBearSpirit]

Hello @benhillis !
I am trying to setup torch7 on my BashOnWindows and I'm getting exactly same error as described in this topic:

CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:47 (try_compile):
Unknown extension ".c" for file

/home/white/torch/build/CMakeFiles/CMakeTmp/testCCompiler.c

try_compile() works only for enabled languages. Currently these are:

C CXX

My cmake version is 2.8.12.2

I've installed Bash on my Windows 10 (build 14332) like 40 minutes ago, so i guess it's the newest version of it. If this error is already fixed, please tell me how can I get this fix.
I'm very glad that here I can get support from a direct developer and I am really hoping for your feedback!

[benhillis]

@WhiteBearSpirit Unfortunately you'll have to wait for another external release to the fast ring for this to be fixed. The change that fixes this was made a few days ago on our development branch and will take some time to reach the fast ring. Unfortunately there is currently no workaround.

Keep an eye out for our release notes as we release new builds.

[nlappas]

Thanks @benhillis !

[bitcrazed]

Bug also filed over here on the CMake tracker - https://cmake.org/Bug/view.php?id=16079.

Will point them this way as the source of the fix.

[hohoCode]

Hi @WhiteBearSpirit , if you can install Torch7 on this great Windows Bash (after they fixed the bug), please let me know... I also want to install Torch7 on Windows. Thanks!!

[benhillis]

Adding a link to #238 since this has the same root cause.

[mcgoo]

I just updated - looks like this fix did not make it in time for 14342.

[benhillis]

@mcgoo thanks for confirming, I will make sure that our release notes for 14342 get published today.

[davidanthoff]

If you want another public repo that is affected by this, try https://github.com/julialang/julia. That might actually generally be a good test case, it compiles a LOT of external dependencies etc., so it might be a good test case.

[vertgo]

What build number (and later) is this fixed in?

[kimjs29]

@mcgoo Your test case passes successfully on 14342, specifically to STDOUT file.
@benhillis But a test case writev()ing to a file with zero size has failed.

I modified @mcgoo's test case as follows:

#include <sys/uio.h>
#include <stdio.h>
#include <fcntl.h>

//  gcc main.c && ./a.out

int main()
{
    char str[] = "test";
    struct iovec iov = {str, 0};
    int fd = creat("test.txt", O_WRONLY);
    if (writev(fd, &iov, 1) == -1)
        perror(NULL);
    close(fd);
}

I had tested combinations and summarized the test results.

No	File	Address	Size	Build 14342	Ubuntu 15.10
1	STDOUT	NULL	0	S	S
2	STDOUT	NULL	Improper	F	F
3	STDOUT	Valid	0	S	S
4	STDOUT	Valid	Proper	S	S
5	test.txt	NULL	0	F	S
6	test.txt	NULL	Improper	F	F
7	test.txt	Valid	0	F	S
8	test.txt	Valid	Proper	S	S

Different cases are for a file + zero size combinations. (Nos. 5 & 7)

[benhillis]

@kimjs29 Thanks for providing such a clear repro. I'll give this a shot as soon as I get to my desk.

I've confirmed that in our dev build we match the Ubuntu 15.10 column above. The fix will be in an upcoming Windows Insider fast ring build.

[mrunix]

when I can get the fixed release? Thank you.

[nlappas]

It seems fixed in the build 14352 that was released today to the fast ring :D

[benhillis]

Closing this out as users have verified this is fixed in build 14352, please reopen if you continue to see this issue. Thanks!

[eliseofe]

I confirm too!

[vagarwal87]

is there a way to fix this issue without upgrading the build? the build upgrade screws up other components of my computer so I'm hoping to find a workaround with build 14342

[sunilmut]

@vagarwal87 - No. At the moment and unfortunately, WSL upgrade is tied to Windows build upgrade.

[LazerPanth3r]

Is this coming to regular users anytime soon? If it's been fixed since May, well its now October and I just ran into this bug in the Windows Anniversary edition.

[cvelten]

It indeed is fixed, might be that those fixes haven't made it into the newest official builds? Just subscribe to the Release Preview channel for Windows Insider, which will give you one of the most stable versions. I can confirm that in the current build of the Release Preview ring, this bug is fixed.