OS - Windows.
I'm using a MinGW compiler. When trying to compile a simple program:
#include <stdio.h>
int main()
{
printf("Hello, world\n");
}
through the console command:
gcc.exe -g (filedir) -o (filedir.obj)
an error message comes up, saying "no include path in which to find stdio.h".
How do I make the compiler find the header and compile the program?
Use the -I option to specify additional include paths as part of the gcc command:
gcc -I /include/file/directory ...
Having said that, you should not need to specify an additional include path to find stdio.h (or any other standard library header). Review how you installed MinGW and make sure you followed all the instructions correctly; you may need to uninstall and re-install.
I solved it. My problem was that I had two C compilers installed at the same time, the other one came along with Free Pascal. Found it out through checking every folder in my Path environment variable. Thanks for the replies.
Related
I have a simple program which I can successfully compile with clang, using MinGW's C/C++ Library:
#include <stdio.h>
int main(int argc, char **argv) { printf("Hello world!\n"); return 0; }
I am able to compile this with mingw-gcc successfully:
$ gcc test.c -o test
$ ./test
Hello world!
I am also able to compile it successfully using clang+mingw:
$ clang test.c -o test -target
$ ./test
Hello world!
However, if I make a small change to my program (include float.h), it continues to compile with gcc but no longer compiles with clang:
#include <stdio.h>
#include <float.h>
int main(int argc, char **argv) { printf("Hello world!\n"); return 0; }
$ gcc test.c -o test
$ ./test
Hello world!
$ clang test.c -o test -target x86_64-pc-windows-gnu
In file included from test.c:2:
In file included from C:\llvm\built\lib\clang\8.0.0\include\float.h:45:
C:\mingw64-8.1.0\x86_64-w64-mingw32\include\float.h:28:15: fatal error: 'float.h' file not found
#include_next <float.h>
^~~~~~~~~
1 error generated.
Is there some configuration issue with clang or some missing command line argument? Googling around a bit, it appears that the order of paths when including float.h is important, but this is all supposed to be handled internally by the clang driver.
The older binary releases of MinGW-w64 have an incompatibility with Clang 8.0+'s float.h. To fix this, copy this specific revision of float.h into the correct location and use it.
I think that it would be advisable to pass this issue on to one of the clang developers.
Comparing the previous release 7.1.0's float.h to the one in 8.0.0 shows only a few differences. The first one I myself would be asking about, is why they change to the header guard from __FLOAT_H to __CLANG_FLOAT_H.
Have a play around changing the 8.0.0 header guard and see what happens.
Edit: Did a bit more searching. The MinGW-w64 developers know of this change since August 2018. Add or adapt the patch from https://sourceforge.net/p/mingw-w64/mailman/message/36386405/ to your MinGW install may sort it out.
Edit 2: Something that I have not used for a while is my MSYS2 install of MinGW. It shows g++.exe (Rev1, Built by MSYS2 project) 8.2.1 20181214. This has the applied patch to line 27 of float.h.
#if !defined(_FLOAT_H___) && !defined(__FLOAT_H) && !defined(__CLANG_FLOAT_H)
While the source forge download of MinGW-w64 8.1.0 has it shown as
#if !defined(_FLOAT_H___) && !defined(__FLOAT_H)
Note: I'm also sure that MSYS2 uses a rolling release update, but I would have to check on that. It's not something that I use on a regular basis.
Edit3: MSYS2 looks like it's a rolling release. Latest versionis 9.1.0.
My opinion unless you need a stand alone MinGW, then go with MSYS2 with the latest updates. Just trying to patch one of the old versions may work, but there could be other issues that my show themselves. If you do need a stand alone version, then I think that the only option would be to build MinGW-w64 directly from source.
NOTE: I would have added comments to the above discussion, but being new I'm not allowed yet.
EDIT 4:
NOTE: The third party multilib toolchains are more than likely built with sjlj exceptions as default. See https://stackoverflow.com/a/17968530/11879567 on how to check.
Edit 5:
Hopefully this is the last edit I will be making.
Checking out the MinGW-w64 forums to see if anyone had asked when the next official release was due. I came across someone who did ask about when 8.2 was to be released. I got the impression that you could be in for a very long wait for any new MinGW-w64 release.
https://sourceforge.net/p/mingw-w64/discussion/723797/thread/ea9a5b00fb/
SIDE NOTE:
As I have found out when dealing with Clang, you are always going to have one issue or another with it, either with MinGW or Visual Studio.
I have tried to compile a C program using FFMPEG but every time I compile it fails at the include statement:
#include <libavcodec/avcodec.h>
#include <libavformat/avformat.h>
Gcc provides this error message:
libavcodec/avcodec.h: No such file or directory
I have installed FFMPEG and created the shared libraries, but when I try to link those libraries when I compile I get the same error.
gcc main.c -L ffmpeg_build/lib -l ffmpeg_build/include/libavcodec/avcodec.h
Do I get this error because I am linking the library incorrectly, or is there some other issue?
This is the first time I am using someone else's library, so please excuse me if I am asking a silly question.
A lowercase -l is a linker option used to specify libraries. They might look like libsomething.a and becomes -lsomething in the linker invocation. In order to add a directory to the header search path, use a capital i, -I.
gcc main.c -L/some/path/ffmpeg_build/lib -I/some/path/ffmpeg_build/include
I have a sample C project that use GLib Library. In that source code, it use :
#include <glib.h>
When I compile, I found this error : "Glib.h : no such file or folder". I have google and find out that I should install this lib. So I use those command:
apt-get install libgtk2.0-dev
apt-get install glade
After that, I have checked and see already exist this header file in my system: usr/include/glib-2.0/glib.h But when I compile, I still meet problem above.
So I have change include line to :
#include <glib-2.0/glib.h>
So, after that, when I compile, I meet error inside glib.h header :
#ifndef __G_LIB_H__
#define __G_LIB_H__
#define __GLIB_H_INSIDE__
#include <glib/galloca.h>
#include <glib/garray.h>
// more code here
glib/galloca.h : no such file or directory. Because this error is inside system header file, I cannot modify anymore and still cannot compile.
I don't know how to fix this. I have read some post, that they change makefile. But, because my project is compiled automatically by IDE (CodeBlock) and I cannot really write a makefile, so that method doesn't suitable for me.
Please tell me a way to fix this.
Thanks :)
There must be some problem with how you build. To compile C programs that use GLib, you need package libglib2.0-dev. You can either install it directly, or install libgtk2.0-dev, which pulls it in as a dependency. So you have the packages you need.
The correct way to compile a GLib program is to use -I with the path to the GLib include files.
An example (from How to compile a helloworld GLib program? on askubuntu):
gcc $(pkg-config --cflags --libs glib-2.0) hello_glib.c
This should let you compile this program:
#include <stdio.h>
#include <glib.h>
int main(int argc, char** argv) {
GList* list = NULL;
list = g_list_append(list, "Hello world!");
printf("The first item is '%s'\n", g_list_first(list)->data);
return 0;
}
The errors you are getting indicate that you are not setting the include path (-I) correctly. How to do this depends on your build system/IDE.
In Code::Blocks, you must set the include path and the linker options in the appropriate configuration dialog. Run pkg-config --cflags --libs glib-2.0, which will output something like
-I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -lglib-2.0
The directories after -I must be set in the compiler options of your project (should be under Project -> Build Options -> Search Directories), and the names after -l must be set in the linker settings. Another option is to create a Makefile, and let Code::Blocks use that.
See e.g. Q: What do I need to know when using 3rd party libs? in the Code::Blocks Wiki.
You should not alter your source code (e.g. the #include directives).
You just need to use pkg-config (both for compiling, with --cflags, and for linking, with --libs), preferably with a builder program like make.
This is an example for exactly your situation: a Makefile using pkg-config to compile some source program using glib
I installed on windows curl 7.28.0 from curl-7.28.1-devel-mingw32.zip through minGW console to default directory like:
./config && make && make install
All needed headers (aka curl.h, types.h ...) I see in C:\MinGW\msys\1.0\local\include\curl
libcurl.pc placed in C:\MinGW\msys\1.0\local\lib\pkgconfig\
libcurl.a, libcurl.dll.a and libcurl.la placed in C:\MinGW\msys\1.0\local\lib.
My download_file.c file includes are:
...
#include <curl/curl.h>
#include <curl/types.h>
#include <curl/easy.h>
...
I try to compile the C code with followed command through gcc:
$ gcc -IC:/MinGW/msys/1.0/include/
-IC:/MinGW/msys/1.0/local/include/curl
-IC:/MinGW/msys/1.0/local/lib/pkgconfig
-o download_file download_file.c -llibcurl -lcurl
with absolute path get the same error:
gcc -I/include/
-I/local/include/curl
-I/local/lib/pkgconfig
-o download_file download_file.c -llibcurl -lcurl
But I still get an error:
download_file.c:21:23: fatal error: curl/curl.h: No such file or directory compilation terminated.
row 21 is #include <curl/curl.h>
What I did wrong? Please help.
You have the curl/ directory in the source code, but also in the option.
It seems the option should point out the higher-level directory in which curl/ is, so it should be something like:
-I/local/include/
I think the problem is likely that you give your include paths on the command line in the Win32 path format. This is not the same as the one used by msys (or ultimately Cygwin).
Try these:
$ gcc -I/include/
-I/local/include/curl
-I/local/lib/pkgconfig
...
Hope I got the absolut paths right, but you can check in your msys shell.
What ticked me off was that you use ./config, which wouldn't work from the Command Prompt, but works from the msys shell. So you need to give paths that all the programs in MinGW understand.
Basically, most programs in MinGW only have the concept of a single file system root, like on any unixoid system, while Win32 has multiple (the drive letters). Since the MinGW programs are linked accordingly, you need to give paths that they understand.
Thank you very much to #0xC0000022L and #unwind. By your help I fixed my problem.
0xC0000022L you are right about absolute path
unwind you are right about -I/local/include/ instead -I/local/include/curl
I found other problem: -L/local/lib instead -I/local/lib.
So this is a working command:
gcc -I/include/
-I/local/include
-L/local/lib
-o download_file download_file.c -llibcurl -lcurl
I was trying to install/compile libraries such as igraph and SNAP in Windows 7 using Cygwin (and also tried MinGW-MSYS) and I ran into some problems.
I think I have narrowed down the problem to this error given by ./configure:
checking sys/times.h usability... no
checking sys/times.h presence... no
checking for sys/times.h... no
In Cygwin, /usr/include/sys/times.h actually do exists. I googled about this for MinGW and it seems that sys/times.h is not available for MinGW because "the POSIX/BSD "times" function is not part of the ANSI standard and does not exist under Mingw32 runtime".
As an experiment, I tried compiling this C code in Cygwin using gcc:
#include <stdio.h>
#include <sys/times.h>
int main (void)
{
return 0;
}
This does not compile, with the error sys/times.h no such file or directory. This happens even when I change the include to </usr/include/sys/times.h> or <usr/include/sys/times.h>. In the Cygwin command promot /usr/include/sys/times.h work correctly.
Question
How do I get sys/times.h usability and presence? Is there a package or library I can install?
Your code compiles with no problem on my Cygwin. Actually /usr/include is one of the default include search paths for gcc, so normally gcc should be able to find sys/times.h.
Perhaps you are using MinGW version of gcc instead of Cygwin gcc? Try which gcc to make sure it's /usr/bin/gcc, and also gcc --version to make sure it does not display like mingw32-gcc.exe (GCC) x.x.x.
You can also try to compile your C file with verbose output:
gcc -v test.c
It shows how gcc searches include files. /usr/include should be one of the search path list if you use Cygwin's gcc.
As I found out, there seems to be some intrinsic problems with this issue, and sys/times.h is not supposed to be used under windows (not supported for some reason).
As I mentioned also here, it's use should actually be removed from the code to make it compile.
I had this same problem. Delete the folder C:\cygwin64 . Reinstall cygwin. Choose all defaults but when you get to 'Select Packaages', make sure to search and select the following one by one: binutils , make , gcc-g++ . For each one, select the dropdown and change form 'skip' to the newest version. Continue until you complete the installation. Everything worked for me from there.