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);
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 programming in CCS (based on Eclipse) to learn to use microcontrollers.
I'm having some problems with includes.
I have 4 files:
GPIO.h - macros and prototypes of GPIO functions
GPIO.c - implementation of GPIO functions declared in GPIO.h
main.c - main program
util.h - macros and typedefs essential to all other files
In each of the programs put the includes, I ctrl + c / ctrl + v of my code:
I really try with " ", I would like to make my code run, it would be rewarding.
GPIO.h - #include "util.h"
GPIO.c - #include "GPIO.h"
main.c - #include "GPIO.c"
util.h - (no includes)
As in eclipse all files are placed in the project folder. Already checked manually by accessing the folder, and they are there.
When I compile and run, there are 2 errors referring to include:
"../GPIO.c", Line 9: fatal error # 1965: Can not open source file "GPIO.h"
"../main.c", Line 1: fatal error # 1965: Can not open source file "GPIO.c"
I do not understand what's wrong!
I made the edit so that people understand that even with "" the error continues (# mame98). I made it clear that I am using the CCS IDE based on Eclipse and now my suspicion is with the operating system. I will have the opportunity to test on Windows only now.
You should only include H files as Eugene Sh. Points out... Also, use #include "util.h" and #include "gpio.h" as they are local files and they are not in the default search path of your compiler. If you want to include 'global' headers (which are in the search path) you have to use #include <file.h>.
Maybe also note, that it is possible to add your local folder to the search path with using the -I. option for GCC (should work with other compilers too).
For more infos about the search path, see here.
<> is for libraries like #include <stdio.h>
"" is used for your own files #include "GPIO.h"
Be careful including .c! If GPIO.h is included in GPIO.c, too, you could get errors..(multiple inclusion protection is useful here!)
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
... ... ...
I am currently learning ffmpeg tutorial of Martin Bohme Tutorial Here
and I want to compile an ffmpeg sample program using Code Block IDE but, it can't
#include <stdio.h>
#include <stdlib.h>
#include "libavcodec/avcodec.h"
#include "libavformat/avformat.h"
int main(int argc, char *argv[])
{
av_register_all();
return 0;
}
Please help me. How to compile it. I am using Linux (Ubuntu)
You have to tell the compiler where the header and library files are. This is done by the -I flag to tell which directories contain header files, and -L to tell which directories contains libraries. You will also need -l to tell which libraries to link with.
The flags can be used like this:
$ g++ -I/path/to/headers myprogram.cpp -L/path/to/libraries -lthelibrary
A note about libraries: On Linux (and UNIX systems) they are files with names that start with "lib" and end with the extension ".a" or ".so". When specifying the library with the -l flag you do not write those. So for a library file "libfoo.a", you only use -lfoo to link with it.
For more information about the options of gcc and g++, see http://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html.
Edit: For an IDE like Code::Blocks there most likely is some project setting where you can add include and library directories and link libraries. Check the "Project" menu for a "Settings" or "Properties" alternative.
Edit2: See for example this FAQ where to find linker settings in Code::Blocks, the pre-processor settings should be close by.
you can try following command to compile in Linux.
gss <program-name.c>
For IDE like eclipse follow FFMPEG - Eclipse Setup Guide[Linux] official