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.
Related
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.
I installed the hidapi library from Signall11 on my windows10 pc (using minGW). But now I'm having some trouble actually getting it to work with gcc. I have some main.c file in which I include the hidapi.h file. My gcc command looks like
gcc main.c
I'm not sure where I'm going wrong because whenever I try to run this command I get an undefined reference error to some function that is defined in the hidapi.h file.
A full compile command for a project using hidapi is like this:
gcc -o your_app your_app.c -lhidapi-hidraw
It's not enough to include #include "hidapi.h" in the C-code, which does let gcc compile. You also need -lhidapi-hidraw to link with the library. I.e. compiling is in fact a 2 step process.
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 am trying to compile a C program that requires Image Magick's MagickWand.h:
#include "wand/MagickWand.h"
But my Image Magick was installed through Homebrew on my Mac so I changed the include to the actual location:
#include </usr/local/Cellar/imagemagick/6.8.9-7/include/ImageMagick-6/wand/MagickWand.h>
However, when I compiled the program I received the following error:
/usr/local/Cellar/imagemagick/6.8.9-7/include/ImageMagick-6/wand/MagickWand.h:71:10: fatal error: 'wand/method-attribute.h' file not found
#include "wand/method-attribute.h"
Now I've been going into the .h files when this error crops up and changing their #includes so that they are pointed correctly (because that appears to be the problem), but there is always a new error here and I'd rather not spend hours manually updating these because of a Homebrew install. Does anyone have any suggestions on how to fix this without manually updating each file? I'm not sure exactly what the problem is so perhaps there is a more elegant solution.
Your code should include the MagickWand library as system headers, and keep the generic path. This will keep your future compiling from breaking when the system/library updates.
#include <wand/MagickWand.h>
Tell your C compiler where homebrew installed ImageMagick by setting the preprocessor include flag -I, and linking/library options with the -L & -l flags.
example:
clang -I/usr/local/Cellar/imagemagick/6.8.9-7/include/ImageMagick-6 \
myProject.c -o myProject.o \
-L/usr/local/Cellar/imagemagick/6.8.9-7/lib \
-lMagickWand-6.Q16 \
-lMagickCore-6.Q1
To simplify the whole process, ImageMagick ships MagickWand-config utility. This will take care of libs, includes, and definitions for you.
example:
CFLAGS=$(MagickWand-config --cflags)
LFLAGS=$(MagickWand-config --libs)
clang $CFLAGS myProject.c -o myProject.o $LFLAGS
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