I have compiled program in minGW which I want to run in my computer which has Cygwin installed in my system. I have the following compilation error:
error: 'off64_t' undeclared (first use in this function)
I added the following to the CFLAGS in Makefile, but still having the same error.
-D"_LARGEFILE64_SOURCE" -D"_FILE_OFFSET_BITS=64"
Can someone suggest what am I missing here and what I need to add?
Cygwin does not define the off64_t type. Instead, if defines _off64_t. If you want to compile your existing code with minimal changes, add the following at the top of your sources:
#include <sys/types.h>
typedef _off64_t off64_t;
Related
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 experiencing an issue with O_DIRECT.
I am trying to use it with open(), but I get an error like:
error: O_DIRECT undeclared (first use in this function)
I am including <fcntl.h>
I grepped /usr/include/ directory for O_DIRECT and it exists in x86_64-linux-gnu/bits/fcntl-linux.h. I tried to include this file instead, but then I get this error:
error: #error Never use <x86_64-linux-gnu/bits/fcntl-linux.h> directly; include <fcntl.h> instead.
I am trying to all of this in Eclipse CDT project on newly installed Ubuntu 20.04 system.
You should define _GNU_SOURCE before including <fcntl.h> or add -D_GNU_SOURCE to your compiler command.
Note that this reduces portability of your program.
it exists in x86_64-linux-gnu/bits/fcntl-linux.h. I tried to include this file instead, but then I get this error
As the error says, you shouldn't include bits headers directly.
O_DIRECT is a Linux extension (i.e. not in POSIX). You need to define _GNU_SOURCE to get it. You can either define it at the top of source file, like:
#define _GNU_SOURCE
or define while compiling with -D_GNU_SOURCE. e.g.
gcc -D_GNU_SOURCE file.c
You may interested in What does "#define _GNU_SOURCE" imply? too.
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 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 libpcap with cross compilator arm-linux-gcc. When I run 'make' I get an error:
./pcap-linux.c:254:14: conflicting types for socklen_t /usr/arm-linux-gnueabi/include/unistd.h:275:21: note previous declaration of 'socklen_t'
I've also tried to compile it using common gcc but i have the same error. I work on ubuntu. How to resolve this problem
pcap-linux.c makes an alias in next way:
#ifndef HAVE_SOCKLEN_T
typedef int socklen_t;
#endif
You should pass -DHAVE_SOCKLEN_T to compiler or put
#define HAVE_SOCKLEN_T
to some header (usually it is done automatically by configure script or similar, that generates config.h).
Seems like you skipped build configuration step, so be ready to see another weird build errors.