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.
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 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 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;
I'm using libconfig inside a project and thought convenient to compile it with the rest of the code using my nested CMakeLists.txt scripts. Here are the contents of the directory where the libconfig source files are located:
[config] -> ls
CMakeLists.txt libconfig.c libconfig.h++ scanctx.h strbuf.c
grammar.c libconfigcpp.c++ libconfig.hh scanner.c strbuf.h
grammar.h libconfigcpp.cc parsectx.h scanner.h wincompat.h
grammar.y libconfig.h scanctx.c scanner.l
Here are the contents of CMakeLists.txt:
set(config_source_files
grammar.c
libconfig.c
libconfigcpp.c++
scanctx.c
scanner.c
strbuf.c
)
add_library(config ${config_source_files})
I get a few warnings when I compile on my Linux (Fedora 20) machine. I get an error when I compile on my OSX (Yosemite) machine:
/Users/m4urice/myproject/src/utilities/config/libconfig.c:90:3: error:
use of undeclared identifier 'locale_t'
locale_t loc = newlocale(LC_NUMERIC_MASK, "C", NULL);
Does anyone have an idea of what this could be due to?
It would seem that libconfig.c is not seeing:
#include <xlocale.h>
which is required for OS X builds, but not for Linux (see fuller explanation below).
There is probably some configuration option or build switch that you are missing that would normally cause this header to be included on OS X builds. I suggest you take a look at libconfig.c and perhaps the other libconfig headers to see if there's an #ifdef which controls the inclusion of <xlocale.h> (try grepping for "xlocale.h"). Also check any accompanying README, makefile, or other documentation.
On Linux the required header for newlocale and locale_t is:
#include <locale.h>
but OS X requires:
#include <xlocale.h>
When in doubt, see the man page:
NEWLOCALE(3) BSD Library Functions Manual NEWLOCALE(3)
NAME
newlocale -- Create a new locale
SYNOPSIS
#include <xlocale.h>
locale_t
newlocale(int mask, const char * locale, locale_t base);
I want to compile a C program in gcc which has my 2 header files.
I am using the command:
gcc UDP_Receive.c -o UDP_Receive -lm
to compile it but I get an error stating "UDP_Data.h: No such file or directory"
How can I tell the compiler to include these header files?
Header Files:
#include "UDP_Data.h"
#include "Crypt.h"
Thanks,
Ritesh
Use -Idirectory to add include paths, or make your #include statement use relative paths.
EDIT:
Also be aware that #include filenames are case sensitive on many platforms.
EDIT2:
Use #include "UDP_Data.h" not #include <UDP_Data.h>
You have told the compiler to include that file, with a line like this:
#include "UDP_Data.h"
the problem is that the compiler can't find that file, and don't forget that some platforms are case sensitive when it comes to filenames so "UDP_data.h" is not the same file as "UDP_Data.h". The compiler will serach in a few places by default, but you will need to add extra directories to its search by using command line options. The exact option will depend on the compiler, for gcc it's:
-I<directory>