I recently installed a new SSD on my machine, and when I did a clean install of windows I got Visual Studio Code, and was about to get the c++ extension up and running, so I got MinGW, and tried to install the GCC and G++ compilers... And low and behold, after trying a lot of solutions, it is still not working properly on this computer image.
When I try to test the compiler after I got MinGW installed properly, this is what it output:
gcc.exe -Wp,-v -E -xc -dD -x c++ nul
ignoring nonexistent directory
"c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../mingw32/include"
ignoring duplicate directory
"c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include/c++"
ignoring duplicate directory
"c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include/c++/mingw32"
ignoring duplicate directory
"c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include/c++/backward"
ignoring duplicate directory
"c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include"
ignoring duplicate directory
"/mingw/lib/gcc/mingw32/6.3.0/../../../../include"
ignoring duplicate directory "c:/mingw/lib/gcc/../../include"
ignoring duplicate directory
"c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/include-fixed"
ignoring nonexistent directory
"c:/mingw/lib/gcc/../../lib/gcc/mingw32/6.3.0/../../../../mingw32/include"
ignoring duplicate directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++/mingw32
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++/backward
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include-fixed
End of search list.
cc1plus.exe: fatal error: nul: No such file or directory
compilation terminated.
Error: 1
The odd part is that the cc1plus.exe is in the MinGW directory, and I even added it to the include path later to see if that would help, and still nothing. I'm not quite sure how to proceed.
This bug has become the bane of my existence for the last week. If anyone has any ideas I'd really appreciate the help. I've had success with MinGW in the past, but for some reason it's giving me problems this time.
Your commandline is:
gcc.exe -Wp,-v -E -xc -dD -x c++ nul
The error:
cc1plus.exe: fatal error: nul: No such file or directory
is the C++ compiler (cc1plus.exe) telling you that the input file nul
does not exist. That will be because there is no file called nul in the current directory.
The Windows CMD NUL device is a virtual device to which the output of a command may be
redirected ( command >NUL) to throw it away. It is not a file.
If you want to test that the compiler can be successfully invoked with this commandline,
then write a program such as:
main.cpp
int main()
{
return 0;
}
Save it in the current directory and run:
gcc.exe -Wp,-v -E -xc -dD -x c++ main.cpp
Close your IDE and go your program folder and open folder with your IDE. Then run and check to see if your problem is solved.
Related
I was trying to build zlib with CMake 3.9.0, output set to MinGW Makefiles, and noticed upon trying to call mingw32-make in the output dir that there was a weird error message which very much looks like a quoting error to me.
D:\zlib-1.2-11> mingw32-make
[ 2%] Generating zlib1rc.obj
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files\mingw-w64\x86_64-7.1.0-win32-seh-rt_v5-rev0\mingw64\bin\windres.exe: preprocessing failed.
CMakeFiles\zlib.dir\build.make:60: recipe for target 'zlib1rc.obj' failed
mingw32-make[2]: *** [zlib1rc.obj] Error 1
CMakeFiles\Makefile2:103: recipe for target 'CMakeFiles/zlib.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/zlib.dir/all] Error 2
Makefile:139: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
What could be the cause of this error and how can I fix it? If it were only zlib, I could scrape the net for pre-built binaries, but this has happened with some other builds, too.
This appears to be a bug in MinGW's version of windres.exe, although I'm also going to heap some blame onto CMake for it's appalling method of invoking windres, which is what is causing this to fail.
The Problem
CMake understands that Windows Resource .rc files are a thing, and that they are compiled with the Windows Resource Compiler (aka windres.exe), which it wraps in the default variable CMAKE_RC_COMPILER.
The problem is, that rather than just invoking windres like a normal person, CMake thinks it's being clever by invoking it like so...
cmd.exe /C "cd /D C:\Users\username\zlib-1.2.11\build && "C:\Program Files\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev0\mingw64\bin\windres.exe" -D GCC_WINDRES -I C:/Users/username/zlib-1.2.11 -I C:/Users/username/zlib-1.2.11/build -o C:/Users/username/zlib-1.2.11/build/zlib1rc.obj -i C:/Users/username/zlib-1.2.11/win32/zlib1.rc"
Evidently it doesn't understand the notion of the current working directory, or the system path variable (which it used to find windres in the first place). If we were to simplify the command, it would look like this...
windres -D GCC_WINDRES -I.. -I. -ozlib1rc.obj -i ../win32/zlib1.rc
Those two commands carry the exact same meaning, except the second one actually works.
The Solution
We have to step in and stop CMake from trying to be clever.
cmake .. -DCMAKE_RC_COMPILER=windres
I have MSVC 2017 installed, and CMake assumes that I want to use that by default, despite none of its environment variables being set and it not being in the path (in normal usage, one must invoke the vcvars64.bat file before using MSVC, this behaviour predates CMake). So I have to use -G "MinGW Makefiles", except that I also have sh.exe in my path (because Git), and that just blows CMake's mind, so I need the command...
cmake .. -G"MSYS Makefiles" -DCMAKE_RC_COMPILER=windres
The CMake file author should have quoted strings containing unknown filesystem paths, i.e. variables and the VERBATIM option also avoids headaches:
if(MINGW)
# This gets us DLL resource information when compiling on MinGW.
if(NOT CMAKE_RC_COMPILER)
set(CMAKE_RC_COMPILER windres.exe)
endif()
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj"
COMMAND "${CMAKE_RC_COMPILER}"
-D GCC_WINDRES
-I "${CMAKE_CURRENT_SOURCE_DIR}"
-I "${CMAKE_CURRENT_BINARY_DIR}"
-o "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj"
-i "${CMAKE_CURRENT_SOURCE_DIR}/win32/zlib1.rc"
VERBATIM)
set(ZLIB_DLL_SRCS "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj")
endif(MINGW)
I am building my test.c using mingw5.4 using command:
/software/mingw5.4/bin//x86_64-w64-mingw32-gcc test.cxx -o /home/user1/test.o
But I am getting following error:
c:/cygwin64_new/home/admin/software/mingw5.4/bin/../lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
cannot open output file /home/user1/test.o: No such file or directory
If I use version mingw4.8.3 the same file is compiling fine.
/usr/bin/x86_64-w64-mingw32-gcc test.cxx -o /home/user1/test.o
If anybody know reason of error in case of version mingw5.4 please let me know.
LOL. I've done that. There is a command called test on *nix systems. Some shells have it built in (for speed). Try running ./test or text.exe or call the executable something else.
I have installed the cds library with command ./build.sh -b 64 -z '-std=c++0x' -l '-L /usr/lib/x86_64-linux-gnu' --with-boost /usr/include/boost --amd64-use-128bit at build folder.
After I tried to compile the example init.cpp of src folder, I typed this in terminal: g++ init.cpp -o init, and terminal showed: fatal error: cds/init.h: No such file or directory.
What should I do for compilation command in this case?
Thanks.
For general troubleshooting in cases like this, i would recommend finding where on the system the file got installed (if your build.sh actually installed the file). You would be able to find the missing header file using
find / -path '*/cds/init.h' 2>/dev/null
Then you need to supply two parameters to g++:
First one gets the compiler to know about the include files from the install directory
-I path_to_folder_one_step_above_cds_folder
Second one gets the linker to know about the librarys location. If the library file is called libcds.so, you can find it by running
find / -name libcds.so 2>/dev/null
So for linking, you supply the flag
-L path_to_folder_one_step_above_libcds.so
In your case you might not need the -L flag, since most of your library supposedly is header only.
UPDATE: the build.sh script is printing out important information at the top, starting with "Building with the following options:". The important bits will be "Compile options:" and "Link options:". Those should be enough to solve your specific option.
UPDATE2: build.sh also exports some flags which might include more options. You can print them out directly after running build.sh by running
echo LDFLAGS=$LDFLAGS
echo CFLAGS=$CFLAGS
echo CXXFLAGS=$CXXFLAGS
you are likely to need to pass all these options to g++ when compiling and linking against that library. LDFLAGS are specific to the linker only. Both the other ones are needed for compiling c++ files.
I'm trying to generate a c++ project using cmake on Windows 7. Before it actually makes the project though it looks cmake does a quick test of your toolchain (I'm using MinGW) and that's where my problem. Cmake triggers a make build which ultimately fails with the response "The system cannot find the path specified."
I ran the particular makefile that was failing in dry run mode (-n) and manually executed all the commands:
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
echo Building C object CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj
C:\PROGRA~2\CODEBL~1\MinGW\bin\gcc.exe -o CMakeFiles\cmTryCompileExec306416588.dir\testCCompiler.c.obj -c C:\SFML\CMakeFiles\ CMakeTmp\testCCompiler.c
echo Linking C executable cmTryCompileExec306416588.exe
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\cmTryCompileExec306416588.dir\link.txt --verbose=1
And they all executed without error leaving me with a functional .exe file as expected. However when run through make I return the error:
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
The system cannot find the path specified.
mingw32-make.exe: *** [CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj] Error 1
I then experimented with replacing all of the commands with something simple like "dir" and noticed that when run through make is returned "The system cannort find the path specified" again before printing out the dir information and exiting with an error.
My next step, and about as far as I've gotten, is to run make with the -d flag; the interesting bit being:
Creating temporary batch file C:\Users\CJ\AppData\Local\Temp\make8664-1.bat
Batch file contents:
#echo off
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
"C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report C:\SFML\CMakeFiles\CMakeTmp\CMakeFiles 1
CreateProcess(C:\Users\CJ\AppData\Local\Temp\make8664 1.bat,C:\Users\CJ\AppData\Local\Temp\make8664-1.bat,...)
Putting child 00490378 (CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj) PID 4730176 on the chain.
Live child 00490378 (CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj) PID 4730176
Main thread handle = 00000074
The system cannot find the path specified.
Reaping losing child 00490378 PID 4730176
Cleaning up temp batch file C:\Users\CJ\AppData\Local\Temp\make8664-1.bat
mingw32-make.exe: *** [CMakeFiles/cmTryCompileExec306416588.dir/testCCompiler.c.obj] Error 1
I don't really know too much about the inner workings of make but from what I can tell from this output it looks like it has something to do with the temporary batch file that make is making. I looked at this stackoverflow post What causes GNU Make to shell out and it looks like what triggers a temporary file to be made is pretty vague. I was able to find a command that executed without the creation of a temporary batch file ("ls" from the windows Git bin) and sure enough it executed via make without returning the "The system cannot find the path specified" response like the "dir" command did ("dir" caused make to generate that temp file).
I feel like I've kind of hit a wall with my debugging abilities and am turning to you guys to see if you can offer any advice. Does it seem like I'm making the right assumptions? Do you have any insights into what may be manifesting the problem?
It looks like I was able to figure out the problem on my own so sorry for bothering with the post. It turns out that the problem wasn't with Make but instead with cmd itself (which would explain the error whenever make tried to run a batch file). It looks like somehow (possibly through some kind of malware that snuck onto my system or maybe some kind of misguided windows update) the Command Processor's registry key was set to something like "C:\Users\CJ\AppData\Roaming\Microsoft\Windows\IEUpdate\RMActivate_ssp.exe" which I recall specifically wiping from my computer not too long ago, hence the "The system cannot find the path specified." message whenever a cmd process was spawned by make (I guess I just totally missed it when I opened up the root cmd process). In any case, this was a simple fix following the instructions at https://superuser.com/questions/727316/error-in-command-line-the-system-cannot-find-the-path-specified, after which I was able to run the make, and subsequently cmake, build without any problems.
The keys in question are
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun and/or HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
Also this error can occur if you picked MSYS toolset in Cmake, but running it under a normal shell. In this case make tries to compile something like /c/source/build/stuff.cpp and normal Windows ABI rejects this path.
A great diagnostic method for this issue is --debug-trycompile flag for Cmake. If something has gone bad, you can re-run the failed command manually or peek into generated files to find the cause.
I downloaded Xcode and the command line tools. When I go to the directory "/usr/bin" and enter "ls" in my terminal, I can see gcc listed among the files and directories. However, when I run the command gcc in this directory, I get a message saying: "-bash: gcc: command not found". Why does it say the command can't be found when I can clearly see it listed among the files in my /usr/bin directory?