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.
Related
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
In the sake of automatically-detecting native GCC installation from within a program, I would like to get the current path to gcc.exe or its root folder.
But when I type gcc -print-prog-name=gcc it simply prints back gcc which is obviously not what I was expecting.
How do I use gcc or other components supposedly installed on the system alongside gcc to retrieve the path to the gcc installation or executable?
For Linux at least, the "native GCC installation" might reasonably be
interpreted as the GCC installation that is invoked through /usr/bin/gcc.
But on that interpretation, there can be no doubt about its installation
path.
Whenever you invoke gcc, if such a program is found at all, it is
simply the first program called gcc that that is found in one of the
directories listed in the value of environment variable PATH, in the
environment of the invocation. True on Linux and other Unix-like OSes.
True on Windows.
Imagine that gcc had an option --whereami that made it print its installation
path on the standard output. The answer you will get will be the answer
given by the first installation of gcc that is found in the operative PATH at
the time of invocation. There might be any number of GCC installations on
a system each of which will yield a different answer for gcc --whereami whenever
that installation is the first to be discovered in the operative PATH.
Selection of different GCC installations via different PATH settings is
commonplace on Windows, where the notion of "the native installation of GCC"
has no meaning. But it is applicable on Linux too and sometimes used. The point is: no
matter what command you run to find out where gcc is installed, any
answer you get is in principle dependent on the operative PATH -
unless you run the command with an absolute filename:
/usr/bin/gcc --whereami
which of course amounts to deciding the answer before you ask the question.
The only cross-platform method by which you can discover the directory from
which gcc will be run, if at all, by a command gcc ..., is to get the
operative PATH (programmatically, use getenv),
parse out the the directories it contains left to right and for successive
directories query the filesystem for the existence of an executable gcc
within it, stopping when you find one.
And since this can only give an answer for the operative PATH,
and since the value of PATH needs parsed differently on Windows and
Unix-like OSes, you might just as well invoke the OS-specific utility that does the same
thing.
Unix-like:
$ which gcc
/usr/bin/gcc
Windows:
C:\>where gcc
C:\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev0\mingw64\bin\gcc.exe
And note that in the Windows case, I needed to select my mingw-w64 terminal environment to get an answer.
To execute commands and get their output programmatically, see How can I run an external program from C and parse its output?. On Windows, call _popen
instead of popen.
When I run
gcc test.c
in the terminal of msys,
I get the error
test.c:1:18: fatal error: x264.h: No such file or directory
#include <x264.h>
I can find the x264.h in /local/include
$ ls /local/include/
x264.h x264_config.h
Why MinGW gcc doesn't search the default place?
It's not a "default place" for MinGW GCC. The fact that you're calling native Win32 GCC from the MSYS shell does not mean it knows about these Unix paths MSYS conjures up.
Either install to the / directory or add your 3rd party library directory to the include paths on the commandline:
-I/local/include
Note the above only works from within the MSYS shell.
I'm using Cygwin on windows to run this command:
g++ `pkgconfig --libs --cflags opencv` -I. -o mergevec mergevec.cpp ....
But I get an error:
-bash: pkg-config: command not found
I've installed cygwin directly on C:. I've added to the PATH environment variable the following:
C:\cygwin64\bin;
C:\cygwin64\lib
I've run cygcheck -c and it gives me a whole list of packages, but pkg-config isn't in that list.
There is a folder called pkgconfig in C:\cygwin64\lib though.
How do I fix this error?
pkg-config is a piece of software that allow your computer to check installed libraries for source compilation. It may not be installed on Windows so in last scenario please check for install.
However in your case i think it is installed, but not set on the right path for linux commands. Try to type in cygwin:
$ export PKG_CONFIG_PATH=c:\\cygwin\\usr\\local\\lib\\pkgconfig
as stated in this post.
Otherwise just abandon Windows and try to compile mergevec on an Linux VM, which is really easier (it was made for it). The only down point of this method is that you will have to do the mergevec operation (and the ones before, otherwise you may have encoding problems) under your linux space. See my previous answer for this manipulation.
If any problem don't hesitate.
run cgywin setup and in package search type pkg-config then make sure that pkg-config utility is installed.
it should solve the not found command problem.
I think that in this case it has nothing to do with the PKG_CONFIG_PATH, because the user complains on the "command not found" error message.
The user probably mixes up pkg-config as a tool (with -) and pkgconfig (without -) as a directory as I see from the command. If I run it without dash on my system I get the same error message of course:
$ pkgconfig --libs --cflags opencv
-bash: pkgconfig: command not found
On Cygwin there is pkgconf.exe as a tool, pkg-config as a symlink to it and pkgconfig as a directory. There is no tool pkgconfig.
If it is not found as pkg-config then it means that pkg-config tool is missing in the Cygwin installation (the solution is to upgate Cygwin tools and select it in the checkbox) or it is probably the symlink problem which I described in https://stackoverflow.com/a/66037850/4807875 (the solution in this case is to use the indeed Cygwin console instead of the native cmd.exe with C:\Cygwin64\bin in PATH in it, or to call explicitly pkgconf.exe).
This shoud be a simple problem for users more advanced than I am. :-)
How do I use the boost library with cygwin on windows?
I am programing with g++ using cygwin on a winxp machine.
I need modified Bessel functions of the second order, so I downloaded the latest version of the boost library and installed it in
'c:\cygwin\lib\boost_ 1_ 38_0\' folder.
I am trying to run the "example.cpp" program from the "getting started" section of their website:
http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html
I am compiling from the directory where I created the example file using a simple Bash shell command line: 'g++ -Wall example.cpp'
I keep getting the message:
"boost/lambda/lambda.hpp: no such file or directory"
I tried every possible combination of -L, -l, -I options in the command line to include the directory, to no avail. Also tried to add the folder in the PATH line of my windows system.
How do I link to the /boost directory and ALSO to all subdirectories? The header file 'lambda.hpp' is calling other header files in subdirectories.
You're probably not that familiar with C++ yet? It seems you are confusing terms.
C++ programs are built in two steps: compiling and linking. In the first step, each source file (typically called .cpp) is handled individually. Each .cpp file usually uses multiple headers, so the compiler first inserts those - literally. That's why it's called #include.
In the second step, the linker takes all the compiled .cpp files together and builds your final program. Some of those compiled .cpp's might have been bundled together before, in which the bundle is called a library.
Boost is a collection of headers and .cpp files. So, both compiler and linker might need to find the Boost directories. From your error message, it's clear that the compiler step is the problem. The linker does not need headers anymore.
The compiler will see the #include <boost/lambda/lambda.hpp> instuction. That means it needs to know where that first-level boost directory is found. I would guess at this point that the path would be /lib/boost_ 1_ 38_0/include (there's always the find / -name lambda.hpp shotgun appraoch)
If you are not utterly wedded to cygwin, you should take a look at http://nuwen.net/mingw.html which gives you a complete MinGW C++ installation with all the libraries (such as Boost) set up for you.
Edit: I should make it clear you can use this MinGW installation in addition to Cygwin, not as a replacement. Just make sure the MinGW bin directory appears in your PATH before the Cygwin one.
I think you need -I /lib/boost_1_38_0 - although that's a pretty unusual place to put it. You'll have to let us know how you installed it, did you just unzip it in the location you said, or did you run the makefiles? I assume that since you gave a windows path you didn't install it within cygwin - which you probably should do. The instructions in the getting started guide for unix should help - although don't download a prebuilt bjam - it needs to be built with cygwin.
But if you're not very familiar with cygwin (or unix in general) I think you might find it easier to use a native windows tool - as in Neil Butterworth's answer.
Thank you all for the information, it's a nice introduction to the use of libraries with cygwin.
Daniel was right. While any variation gives an error, the following line (using caps i) does the trick:
g++ -Wall -I /cygdrive/c/cygwin/lib/boost_1_38_0/ example.cpp -o example
I will also check MinGW in the next few days.
p.s. I simply downloaded and unzipped boost in that folder, but since I am only using header files I probably won't need to compile with cygwin. [The boost version included with cygwin was 1.33, which does not seem to have Bessel functions.]
This is on win7 cygwin64 g++ 5.4, and boost-1.64.7z on 2017-7. Google doesn't show any useful result for getting started for boost on windows (is boost out of fashion?).
By experimenting, I managed to compile and run a boost graph sample program as follows:
:: g++ 5.4 in c:\cygwin64
:: 7z extract boost download in c:\tools\boost\boost164
> set BOOST_ROOT=c:\tools\boost\boost164
> setx BOOST_ROOT c:\tools\boost\boost164 -m
> cd %BOOST_ROOT%
> bootstrap.sh gcc (the bat files doesn't work)
> b2.exe
...failed updating 58 targets...
...skipped 18 targets...
...updated 1123 targets...
:: Lots of example here (not ranked highly by google)
> mklink /D eg %BOOST_ROOT%/libs/graph/example
:: Compiled and run [maxflow code using boost library][1]
:: http://vision.csd.uwo.ca/code
> unzip ; vi Makefile
CPPFLAGS = -I %BOOST_ROOT%/
LDFLAGS = -L%BOOST_ROOT%/stage/lib
> make
> set PATH=%PATH%;%BOOST_ROOT%/stage/lib
> maxflow.exe
Flow = 6