I'm trying to compile a C program using Ncurses on Windows. I compiled it successfully using GCC and it works perfectly if I run it in Cygwin or MSYS2. However, if I try to run it in the Windows Command Prompt, I get this error:
Error opening terminal: xterm-256color.
Is it possible to compile it to run using the native Windows console? This is how I've been compiling it:
gcc -o PROGRAMNAME main.c -lncurses
I also have the Cygwin and Msys dlls for Ncurses copied into the directory of the compiled executable.
Update
So I figured out how to get the program to run. I deleted all the DLLs from the project folder and then added "C:\msys64\usr\bin" to my PATH environment variable. However, I would still like to know if there's a way to get this to work if I were to distribute it, since it's still relying on my installation of MSYS2.
Update 2
Gave up and just used pdcurses and it works fine.
Update 3
Nevermind, found a solution! See below.
I figured out a solution. I'll post it here in case anyone else has this same issue. Thanks to Thomas Dickey for your help!
Install the mingw-w64 toolchain and any other packages you need to compile your project (this is mostly where I messed up)
Make sure to include the /mingw64/include/ncurses directory when compiling, or else gcc won't be able to find curses.h
Include /mingw64/bin as a static directory or copy over the necessary dlls to the same folder as the directory
I ended up with this to compile:
gcc -I/mingw64/include/ncurses -o PROGRAMNAME main.c -lncurses -L/mingw64/bin -static
I have both MinGW gcc and Clang clang installed and added to path via chocolatey, and both can be found on the command line. However, when I try to use clang with gcc, clang doesn't seem to know where to find header files in the standard library (such as iostream), returning the following error:
clang++ -v main.cpp -o main.exe -std=c++14 -target x86_64-mingw64
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-unknown-windows-gnu
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
(SKIP)
ignoring nonexistent directory "(nonexistent directories)"
#include "..." search starts here:
#include <...> search starts here:
C:\Program Files\LLVM\lib\clang\9.0.0\include
End of search list.
main.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^~~~~~~~~~
1 error generated.
shell returned 1
I've added both gcc and clang to path, as well as the directory containing header files included in gcc (C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\lib\gcc\x86_64-w64-mingw32\8.1.0), so I don't understand why clang isn't looking in the right place for the header files. How can I fix this problem? And this isn't really necessary, but can the default target for clang be changed? The current Windows 10 default for clang is msvc, but I'd rather not use it.
Solution:
edit your path environment, move or add [path to your g++ folder] to some position ahead of "C:\ProgramData\Chocolatey\bin".
Reason:
LLVM installed using prebuilt binaries from chocolatey or its offcial website lacks header files, therefore it has to use header files of other compiles such as MSVC or mingw64. When you specify your target as mingw64, clang will guess path to header files of mingw by the position of g++.exe (maybe gcc.exe).
Chocolatey uses a software shimgen to "map" (I don't know if there is more proper word) executable file to "C:\ProgramData\Chocolatey\bin", which is placed before [path to your g++ folder]. Therefore clang will detect "g++.exe" under that path first and infer a wrong path from it.
Please forgive my poor English.
I downloaded
Ruben’s build of
Cygwin GCC.
However upon running it seems unable to compile any files
$ touch foo.c
$ gcc foo.c
gcc: error: spawn: No such file or directory
As a workaround, I found this to work
i686-w64-mingw32-gcc foo.c
I had the same problem and solved it by installing the g++ package in addition to gcc-core
I had this same problem on Cygwin64, and the solution was PATH related..kinda.
Turns out, there are copies of gcc in /usr/bin and /bin (at least, there is in my install).
Executing /bin/gcc failed with the error above -- I'm guessing due to incorrectly assumed relative paths???
Executing /usr/bin/gcc works as expected!
In my case, the "problem" was that I had inadvertently injected "/bin" into my PATH environment variable, resulting in /bin/gcc being executed, instead of /usr/bin/gcc. Removing the "/bin" from the path solved the problem.
Still unclear why there are two gcc binaries (which appear to be identical) in different places... but maybe the Cygwin gurus can answer that; or maybe my installation is just foo-barred.
Ruben's builds are not Cygwin GCC packages, rather they are cross-compilers which run on various platforms but target native Windows using the MinGW-w64 toolchain.
In any case, you shouldn't be using them on Cygwin. If you want to compile Cygwin executables, install the gcc4 packages; if you want to cross-compile for Windows, install the mingw64-i686-gcc (for Win32) or mingw64-x86_64-gcc (for Win64) packages instead.
Gcc isn't really the compiler. It's a front end program that orchestrates the execution of any necessary compiler, assembler, and linker components. Typically these others are separately compiled programs.
So, gcc is trying (kind of) to tell you that it can't find the compiler. I guess it needs to be on your PATH or in an expected location.
If you are executing this from a Windows DOS box then it definitely needs a windows PATH setting.
I like to install Cygwin, making sure to include rxvt. At that point, you can configure a purely sh(1) path and your environment is rather more civilized.
I had the same error when I tried to extract a couple of executables from cygwin installation dirctory and copied them into another location.
strace shows me the file which was not found by spawn:
/lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
When I copied cc1.exe into the location relative to
<dir with sh.exe and cpp.exe>/../lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
it works fine.
This error occurs whenever cygwin cc can't find a required file.
For those running stuff within cygwin's bin directly from a Windows shell, a gotcha to watch out for is that Windows allow you to run programs from the command line like this:
e:cyg/bin/gcc -flags
Notice that there is no slash between e: and cyg.
So this command would successfully start cygwin gcc from the Windows shell, but halfway through the run it will error out because some component(s) of gcc will utilize the first argument of the input e:cyg/bin/gcc and unlike mingw, this is not a valid path for cygwin gcc.
This can be fixed simply by changing the command to:
e:/cyg/bin/gcc -flags
Notice the slash in between e: and cyg.
A similar gotcha is due to Windows allowing paths like e:/../folder1 as an alternative to e:/folder1. Windows does not give you an error if you are at the root folder and try to go up another folder using ...
So you could start running cygwin gcc using the command:
e:/../cyg/bin/gcc -flags
..or even:
e:/../../../../../../../../../cyg/bin/gcc -flags
However, it would fail halfway with gcc: error: spawn: No such file or directory because some component(s) of cygwin gcc would attempt to run gcc using the first argument of the command input itself, and unlike mingw, e:/../cyg/bin/gcc is not recognized as a valid path by cygwin because you are going up a folder when there's no folder to go up to.
As like above, this can be fixed by keeping the path valid:
e:/cyg/bin/gcc -flags
Make sure the source file extension is in lowercase (i.e. main.c, not main.C):
$ gcc -o main main.C
$ gcc: error: spawn: No such file or directory
$ gcc -o main main.c
$ # all good
This only refers to the case of the extension as given to the gcc, the actual source file can have the extension in whatever case you want.
Explanation: This is from my experimenting with cygwin and gcc, I don't know the actual reason for this behavior.
I was trying to install gcc and gfortran on my intel mac with mountain lion and keep getting the above error when trying to compile the fortran file. gcc doesn't seem to work either with c programs. This is the error I get with my c program:
test.c:1:19: fatal error: stdio.h: No such file or directory
I tried typing this into terminal:
export PATH=${PATH}:/usr/local/bin
but that did not work. I added gcc and gfortran to /usr/local/bin instead of /usr/bin. I downloaded the compilers through hpc. The files had the given directory structure:
/usr/local/bin: contained gcc and gfortran along with other compilers
/uer/local/include/...
/usr/local/lib/...
etc...
I pretty much just copied and pasted all the files directly over to the exact same path directories on my computer and ran the export command. That is all I have done.
You probably need either odcctools (as provided by macports) or XCode (which contains the Mac "binutils", and the Clang compiler, GCC was discontinued).
I have installed the latest version of Cygwin, selecting the following packages during setup:
libgcc1
gcc
gcc-core
And created a file (test.c) with only this line:
#include <link.h>
Then ran the following from my Cygwin bash:
$ gcc test.c
... but got this error:
test.c:1:18: link.h: No such file or directory
Any ideas how I can fix it?
Cygwin is based on the Win32 subsystem, which means it uses Windows' executable format (COFF) and dynamic linker, i.e. it does not have an ELF dynamic linker. Hence providing the ELF-specific <link.h> would probably make little sense.