I have visual studio installed in my system. So its corresponding compiler and environment variables are set. When i try to compile c file using cl command, it works fine. Now i zipped mingW from another system and extracted it to my system. Say i have it in D:/mingW. Now i have created a batch file for compiling the c file. The contents of the batch file are,
set gccPath=D:/mingW/bin
%gccPath%/gcc.exe -c -std=c99 -o myC.o ../myC.c -I..\.
When i run this batch file, it is producing few errors.
One such error is
stdio.h:209:71: error: macro "snprintf" requires 5 arguments, but only 4 given
The above error might be due to the fact that compiler takes the stdio.h of visual studio instead of mingW's default header file.
Another error is,
error: previous declaration of 'xxxxFun' was here
What should i change in the batch script to compile the c file completely using mingW.
Compilation process is successful when we use Visual Studio, but throws error if we use gcc for the same set of files
EDIT:
I fixed the latter error.
Also the first error doesn't occur when stdio.h is included at first. But if we include stdio.h at the middle of the include section, the error comes.
#include <string.h>
#include <assert.h>
#include <minmax.h>
#include "myFunctions.h"
#include "MyModule.h"
#include <stdio.h>
When we have stdio.h at last as shown, the error is coming. If we move the line #include <stdio.h> to any other lines above #include <MyModule.h> , the specified error is not coming. Any reason behind this strange behavior?
Check whether you are defining snprintf using macros in any of your header files. This error may be caused due to incorrect/unnecessary macro.
Related
I have a C program that has #include <microtime.h> in the header, but when I compile it with GCC or g++, it shows the error -
fatal error: microtime.h: No such file or directory
2 | #include <microtime.h>
How could I compile it. I am not sure if I need to download this microtime separately?
use quotes:-
#include "microtime.h"
Using quotes will look in the same directory first, and then in the specified include paths. Using angle brackets <> will look in the include paths only.
I'm currently toying around with the C library NanoVG library. The library depends on OpenGL fucntions and has 2 header files nanovg.h and nanovg_gl.h. The latter file contains part of the implementation. For convenience, I have placed these two header files in /usr/include/nanovg.
When I try to compile the following code to an object file, gcc does not complain:
// working.c
#include <GL/gl.h>
#include <nanovg/nanovg.h>
#define NANOVG_GL3_IMPLEMENTATION
#include <nanovg/nanovg_gl.h>
(Command: gcc -c working.c -o working.o)
Now, I copy the header files from /usr/include/nanovg/ to the working directory, and replace the code with:
// notworking.c
#include <GL/gl.h>
#include "nanovg.h"
#define NANOVG_GL3_IMPLEMENTATION
#include "nanovg_gl.h"
(Command: gcc -c notworking.c -o notworking.o)
Gcc now complains that some OpenGL functions are not declared:
... (many more similar complaints)
src/nanovg_gl.h: In function ‘glnvg__renderDelete’:
src/nanovg_gl.h:1540:3: warning: implicit declaration of function ‘glDeleteBuffers’; did you mean ‘glSelectBuffer’? [-Wimplicit-function-declaration]
1540 | glDeleteBuffers(1, &gl->fragBuf);
| ^~~~~~~~~~~~~~~
...
Why does one file compile smoothly but not the other?
A bit deeper:
Using the cpp tool, I found that the difference between the two pre-processed files is limited to # directives but I don't see any difference as far as the "C content" goes. Below is a snippet of the pre-processed working.c. If I add the # lines from the pre-processed notworking.c, then gcc no longer compiles the pre-processed working.c and complains about a missing declaration for glDeleteBuffers.
// ...
if (gl ==
// # 1533 "src/nanovg_gl.h" 3 4 // <- uncomment this line and glDeleteBuffers is considered missing by gcc
((void *)0)
// # 1533 "src/nanovg_gl.h" // <- idem
) return;
glnvg__deleteShader(&gl->shader);
if (gl->fragBuf != 0)
glDeleteBuffers(1, &gl->fragBuf); // <- the function that gcc complains about is here
// ...
Edit: Just to make sure that I did not do anything sneaky that might have caused the difference, I followed the following steps which hopefully should be reproducible on another computer:
GCC version: gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
Copy the version of GL/gl.h can be found here to working directory and call it glfoo.h
Copy the headers of nanovg (as found in the repo) to /usr/include/nanovg/ and nanovg/ (relative to working directory).
Save the following as test.c in the working dir:
#include "glfoo.h"
#include <nanovg/nanovg.h>
#define NANOVG_GL3_IMPLEMENTATION
#include <nanovg/nanovg_gl.h>
Run gcc -c test.c -o test.o => compilation works
Replace <...> with ".." on lines 2 and 4 and run command => compilation fails.
Just tried these exact steps and I was able to reproduce it.
After investigating this a bit I found the solution. gcc does not apply the same warning level to system headers as it does for "normal" files (this is mainly because system headers are sometimes doing weird things which are not backed up by the C standard, but are "safe" for the platform they are coming with).
The gcc documentation states (emphasis mine):
-Wsystem-headers:
Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on
the assumption that they usually do not indicate real problems and
would only make the compiler output harder to read. Using this
command-line option tells GCC to emit warnings from system headers as
if they occurred in user code. However, note that using -Wall in
conjunction with this option does not warn about unknown pragmas in
system headers—for that, -Wunknown-pragmas must also be used.
When you include nanovg via <...>, it is treated as a system header.
So doing gcc -Wsystem-headers working.c actually will bring on the warning.
Note that your code is neither working in working.c nor notworking.c, as working.c just hides the warning messages. The proper way to access any GL function beyond what is defined in GL 1.1 is to use the GL extension mechanism, which means you have to query the GL function pointers at run-time. Full GL loader libs like GLEW and glad can do that for you automatically. Many of these loaders (including GLEW and GLAD) work by re-#define-ing every GL function name to an internal function pointer, so when you include the header which comes with the loader, every GL function called in your code (and nanovg's) will be re-routed to the loader-libraries function pointers, and your code can actually work (provided you properly initialize the loader at run-time before any of the GL functions is called).
simply
#include <file.h>
include file from the path listed default to the compiler, while
#include "file.h"
include file from the current folder (where you are compiling).
As in your case , switching from <> to "" makes come files missing which makes that compiler error coming.
I am struggling to compile a simple C program from RFC 2617. The program is digtest.c and it uses digcalc.c, another file from the sample implementation. The latter one depends on two files that my compiler doesn't know about:
#include <global.h>
#include <md5.h>
At first I got this error:
digcalc.c:5:20: fatal error: global.h: No such file or directory
I resolved that by changing <global.h> to <stddef.h>, it seems. But I still get this error:
digcalc.c:7:17: fatal error: md5.h: No such file or directory
Now, md5.h seems to refer to the file found in libbsd. So I installed libbsd-dev and tried to compile the files like this:
gcc digcalc.c digtest.c -o digtest -L/usr/lib/x86_64-linux-gnu -lbsd
where /usr/lib/x86_64-linux-gnu is the location of libbsd.so and libbsd.a files. However, this does not resolve the last compilation error.
Could anyone point out what am I missing here?
Figured it out. Had to change <md5.h> to <bsd/md5.h>, as noted on libbsd page.
So instead of the original headers in digcalc.c:
#include <global.h>
#include <md5.h>
I used:
#include <stddef.h>
#include <bsd/md5.h>
Also had to change function stricmp to strcasecmp, its POSIX equivalent. After that the sample code compiled seamlessly.
I am currently trying to create an application in C as an assignment for school, and my professor requires me to use the following to make it compatible with his compiler:
#pragma warning(disable: 4996)
#include<string>
#include<stdlib.h>
#include<time.h>
(I am using visual studio)
And for some reason #include <string> throws up a bunch of run time errors mainly consisting of the one in the title of the question. It pops up within a bunch of other dependencies ranging from cmath, cstudio, cstdlib, cstring, etc. So the bottom line is, can anyone tell me how to fix it? Thanks!
In visual studio you can get this error if you extension is '.c' VS studio will assume the file is type c and not c++ and use the c compiler and not the c++.
In the project settings under advanced options you can select compile as C++ and then files will all be compiled as C++. If you scroll down you will find the flag '-x' on the command line as added to it.
If you are using the gcc compiler this is the same as adding the following to the compiler command '-x c++'
Check the gcc reference for this flag.
The #include <string> is a C++ header file and therefore incompatible with C.
As others have suggested, you can change this to #include <string.h> so that you have a valid C header, however if your professor dictated that you use that specific set of headers, then you need to change your source file to a .ccp file instead of a .c file.
You're including C++ header file. Use #include <string.h>
You are including a C++ library in C code. The header files without any extension are C++ header files. Having ".h" extension are C header files. C++ also accepts C header files still they have no extension. They have given same names having "c" prefix and no ".h" extension.
for example
<string>
is a C++ header
<string.h>
is a C header
<cstring>
is a C header but in a C++ code.
Looking into learning C. As I understand it when I say #include <stdio.h> it grabs stdio.h from the default location...usually a directory inside your working directory called include. How do I actually get the file stdio.h? Do I need to download a bunch of .h files and move them from project to project inside the include directory? I did the following in a test.c file. I then ran make test and it outputted a binary. When I ran ./test I did not see hello print onto my screen. I thought I wasn't seeing output maybe because it doesn't find the stdio.h library. But then again if I remove the greater than or less than signs in stdio the compiler gives me an error. Any ideas?
I'm on a Mac running this from the command line. I am using: GNU Make 3.81. This program built for i386-apple-darwin10.0
#include <stdio.h>
main()
{
printf("hello");
}
Edit: I have updated my code to include a datatype for the main function and to return 0. I still get the same result...compiles without error and when I run the file ./test it doesn't print anything on screen.
#include <stdio.h>
int main()
{
printf("hello");
return 0;
}
Update:
If I add a \n inside of the printf it works! so this will work:
#include <stdio.h>
int main()
{
printf("hello\n");
return 0;
}
Your code should have preferably
printf("hello\n");
or
puts("hello");
If you want to know where does the standard header file <stdio.h> comes from, you could run your compiler with appropriate flags. If it is gcc, try compiling with
gcc -H -v -Wall hello.c -o hello
Pedantically, a standard header file is even not required to exist as a file; the standard permits an implementation which would process the #include <stdio.h> without accessing the file system (but e.g. by retrieving internal resources inside the compiler, or from a database...). Few compilers behave that way, most really access something in the file system.
If you didn't have the file, you'd get a compilation error.
My guess is the text was printed, but the console closed before you got the chance to see it.
Also, main returns an int, and you should return 0; to signal successful completion.
#include <header.h>, with angle brackets, searches in standard system locations, known to the compiler-- not in your project's subdirectories. In Unix systems (including your Mac, I believe), stdio.h is typically in /usr/include. If you use #include "header.h", you're searching subdirectories first and then the same places as with <header.h>.
But you don't need to find or copy the header to run your program. It is read at compilation time, so your ./test doesn't need it at all. Your program looks like it should have worked. Is it possible that you just typed "test", not "./test", and got the system command "test"? (Suggestion: Don't name your programs "test".)
Just going to leave this here : STILL! in 2018, December... Linux Mint 18.3
has no support for C development.
innocent / # cc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # gcc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # apt show libc6
(Abbreviated)::
Package: libc6
Version: 2.23-0ubuntu10
Priority: required
Section: libs
Source: glibc
Origin: Ubuntu
Installed-Size: 11.2 MB
Depends: libgcc1
Homepage: http://www.gnu.org/software/libc/libc.html
Description: GNU C Library: Shared libraries
Contains the standard libraries that are used by nearly all programs on
the system. This package includes shared versions of the standard C library
and the standard math library, as well as many others.
innocent / # apt-get install libc6-dev libc-dev
So, magic... and a minute later they are all installed on the
computer and then things work as they should.
Not all distros bundle up all the C support libs in each ISO.
Hunh.
hardlyinnocent / # gcc ThoseSorts.c
hardlyinnocent / # ./a.out
20
18
17
16
... ... ...