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.
Related
I'm following the example provided at https://assimp.sourceforge.net/lib_html/usage.html to import a simple model using the assimp library. The first three lines in the example are the required include statements:
#include <assimp/cimport.h> // Plain-C interface
#include <assimp/scene.h> // Output data structure
#include <assimp/postprocess.h> // Post processing flags
Of these, scene.h seems to be problematic. If you include it AND link against a compilation unit that also includes it, it gives multiple definition errors for aiGetMaterialFloat and aiGetMaterialInteger. A stripped down example is given below:
main.c:
#include <assimp/cimport.h> // Plain-C interface
#include <assimp/scene.h> // Output data structure
#include <assimp/postprocess.h> // Post processing flags
#include "model.h"
//...
model.h:
#include <assimp/cimport.h> // Plain-C interface
#include <assimp/scene.h> // Output data structure
#include <assimp/postprocess.h> // Post processing flags
//...
model.c
#include "model.h"
makefile:
main: main.c model
gcc main.c model.o
model: model.c model.h
gcc -c model.c
I'm using MinGW to compile these.
Now this DOES seem to compile if:
main.c does not include model.h, OR
the include statements are removed from model.h, OR
model.o is not linked when compiling main.c, OR
the import for scene.h is removed from one or both files
It will also compile just fine if the #includes are all moved to main.c and the model compilation unit is removed entirely.
Note that if one of the above conditions are met, this compiles just fine without a DLL or static library linked. The problem seems to be exclusively from including the header files.
I've done a lot of research and the only thing I could find is that it might be the inline specifier on these functions that was causing the issue. However, after removing the inline specifiers from the function definitions in the library header file, I'm still getting the same errors. I've been trying to solve this issue for hours and nothing seems to be working. Any ideas?
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 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.
I'm trying to compile a Contiki OS example on Ubuntu 16.10, but I'm facing the following issue:
$ make
returns
../../platform/slwstk6201a/./contiki-conf.h:40:26: fatal error:
sys/select.h: No such file or directory
#include <sys/select.h>
When I include <stdio.h>, which is in the same folder (but 1 level below sys), the <stdio.h> include does not throw an error. This makes me believe it's an issue with permissions/path variable?
I also tried changing the include to #include </usr/include/sys/select.h>, but that will throw an error, complaining about another include features.h
Any suggestions?
I'm fairly new to programming with c and i am having a hard time including the squash library into my program.
I cloned the repository and ran ./configure and make sudo make install.
That installed the files:
/usr/local/lib/pkgconfig/squash-0.8.pc
/usr/local/lib/libsquash0.8.so.0.8
/usr/local/lib/libsquash0.8.so.0.8.0
/usr/local/lib/libsquash0.8.so
/usr/local/lib/cmake/Squash-0.8.0/SquashConfig.cmake
/usr/local/bin/squash
And some more files in this directories:
/usr/local/include/squash-0.8/
/usr/local/lib/squash/0.8/plugins/
In the squash examples the library is included by #include <squash/squash.h> but when i am trying to compile it i get fatal error: squash/squash.h: No such file or directory
Also #include <squash-0.8/squash.h> doesnt work because then i get fatal error: hedley/hedley.h: No such file or directory That file is located at
/usr/local/include/squash-0.8/squash/hedley/hedley.h
I guess the solution is pretty simple for an experienced c programmer but i am failing here..
Do i need to set some sort of environment variable to let the compiler find the library?
And how do i link the library to the compiler anyway?
I found something like:
-rdynamic ../squash/libsquash0.8.so.0.8 but could not test it yet because of the error above.
Try to change
#include <squash/squash.h>
to
#include "squash/hedley/hedley.h"
or
#include "<squash-0.8/squash/hedley/hedley.h>"
easier and faster solution would be adding the path to your includes during compilation:
-I/usr/local/include/squash-0.8/squash/