Is there a compiler or preprocessor flag that will force gcc to treat #include <x.h> like it would #include "x.h"? I have a bunch of generated code that uses #include <> for files in the current directory, and gcc reports No such file or directory for these files. I'm looking for a workaround that doesn't involve editing the code.
EDIT: -I. doesn't do it. Let's say I have the following files:
foo/foo.h:
#include <foo2.h>
foo/foo2.h:
#define FOO 12345
xyz/xyz.c
#include <stdio.h>
#include "foo/foo2.h"
int main(void)
{
printf("FOO is %d\n", FOO);
return 0;
}
If, inside the xyz directory, I compile with gcc -o xyz I.. xyz.c, the compile fails:
In file included from xyz.c:2:
../foo/foo.h:1:18: error: foo2.h: No such file or directory
xyz.c: In function ‘main’:
xyz.c:6: error: ‘FOO’ undeclared (first use in this function)
xyz.c:6: error: (Each undeclared identifier is reported only once
xyz.c:6: error: for each function it appears in.)
Adding -I. doesn't change anything.
But, if I change foo/foo.h to:
#include "foo2.h"
Then the compile works. I know I could add -I../foo to my command line, but I was looking for a more generic way to treat #include <> as #include "". Does one exist?
Yes, you can pass the switch -I . to the compiler to add the current directory to the include search path.
The -I- option might help you. From gcc's man page:
-I- Split the include path. Any directories specified with -I options
before -I- are searched only for headers requested with
"#include "file""; they are not searched for "#include <file>". If
additional directories are specified with -I options after the -I-,
those directories are searched for all #include directives.
Related
I am currently creating a C library to accept input(similar to scanf), but after moving all the necessary files to the relevant places, this error is seen when I type this command (gcc main.c -o main.exe -linput)
undefined reference to `getInput
collect2.exe: error: ld returned 1 exit status
I have moved the C file and the header file to the GCC include folder, and I have moved libinput.a to the lib folder.
I have also done the same thing with another library I made, but that works fine.
After some further digging I found out that when I right-click on the function "getinput" and click "go to definition", it goes to the input.c file instead of the input.h. In the other libraries, it redirects me to the library.h file and not the library.c file. This might be the problem but I have no idea of how to fix it.
Note- running gcc main.c libinput.a works while having libinput.a in the same directory, but I
would prefer gcc main.c -o main.exe -linput(without having it in the same directory,
similar to how other libraries work). Having input.c and input.h in the same directory
and then linking it also works.
Environment - VS code on windows 10
Here is my code so far:
input.h
#ifndef INPUT_H
#define INPUT_H
void getInput(char *str, ...);
#endif
main.c(an example code where I am using the library)
#include <stdio.h>
#include <input.h>
int main()
{
char *s = NULL;
getInput("{s}", &s);
printf("%s\n", s);
}
Edit - I fixed it by moving the files to the following places
libinput.a = D:\mingw64\lib\gcc\x86_64-w64-mingw32\8.1.0
input.c and input.h = D:\mingw64\x86_64-w64-mingw32\include
You tell the linker to search other directories with -L searchdir. gcc will pass that option through to the linker.
I am a C language beginners, I encountered a problem, can not find the header file, but in fact, these header files are in the current file, I saw online methods (for example : solution) are to add - I option can solve this problem, but I am very curious, why can't it find itself, can only rely on - I option?
include path:
ls .
include test_ffmpeg.c
ls include/libavcodec/
avcodec.h avfft.h dirac.h dxva2.h vaapi.h vdpau.h videotoolbox.h xvmc.h
avdct.h d3d11va.h dv_profile.h qsv.h vda.h version.h vorbis_parser.h
source tree:
root
|-----test_ffmpeg.c
|-----include
code:
#include <stdio.h>
#include "./include/libavcode/avcodec.h"
#include "./include/libvformat/acfomat.h"
#include "./include/libavfilter/avfilter.h"
int main(void)
{
return 0;
}
compile:
gcc test_ffmpeg.c -lavcodec -lavdevice -lavfilter -lavformat -lavutil
a fatal error occured:
test_ffmpeg.c:3:10: fatal error: ./include/libavcode/avcodec.h: No such file or directory
#include "./include/libavcode/avcodec.h"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Your include statement mentions include/libavcode, but the path that exists is include/libavcodec.
Add a c and you should see a difference.
I have these 3 files under /Users/koraytugay
checksum.h
enc.h
libsec.a
libsec.a is an archive file existing of checksum.o and enc.o
Korays-MacBook-Pro:~ koraytugay$ nm libsec.a
libsec.a(enc.o):
0000000000000090 s EH_frame0
0000000000000000 T _enc
00000000000000a8 S _enc.eh
U _strlen
libsec.a(checksum.o):
0000000000000078 s EH_frame0
0000000000000000 T _checkSumFor
0000000000000090 S _checkSumFor.eh
Korays-MacBook-Pro:~ koraytugay
This is how I try to compile my hello.c file:
Korays-MacBook-Pro:HelloWorld koraytugay$ gcc hello.c -L/Users/koraytugay -libsec -o koko.out
hello.c:4:10: fatal error: 'enc.h' file not found
#include <enc.h>
^
1 error generated.
What am I doing wrong?
Btw, hello.c:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <enc.h>
#include <checksum.h>
// code here..
You try to include enc.h, but it's not in your include path. You can add this to your gcc invocation to fix that:
-I/Users/koraytugay
In addition to the lack of -I. switch to bring the current directory into the include path, the link specification should read -lsec, not -libsec. The linker takes the string after the -l switch, prepends lib, and looks for that. In other words, -lfoo implies that there should be a libfoo.a (static) or libfoo.so (shared) file on the link path (which itself is specified with the -L switch).
There are two ways to #include a file: with "..." and with <...>.
Essentially both are implementation-defined:
<...> searches "a sequence of implementation-defined places", which is commonly referred as the include path.
"..." searches "in an implementation-defined manner", which is usually the directory of the parent file. If the file isn't found, the <...> way (include path) is used instead.
The first way should be used for system headers as well as headers of libraries not directly included in the project, while the second way is to be preferred for headers belonging directly to the project.
I downloaded the source code and wanted to compile the file of scanner. It produces this error:
[meepo#localhost cs143-pp1]$ gcc -o lex.yy.o lex.yy.c -ll
In file included from scanner.l:15:0:
scanner.h:59:5: error: unknown type name ‘bool’
In file included from scanner.l:16:0:
utility.h:64:38: error: unknown type name ‘bool’
utility.h:74:1: error: unknown type name ‘bool’
In file included from scanner.l:17:0:
errors.h:16:18: fatal error: string: No such file or directory
compilation terminated.
And I tried to use different complier to compile it, but it appeared different errors.
[meepo#localhost cs143-pp1]$ g++ -o scan lex.yy.c -ll
/usr/bin/ld: cannot find -ll
collect2: ld returned 1 exit status
My os is 3.0-ARCH, I don't know why this happened. How do I fix the error?
C90 does not support the boolean data type.
C99 does include it with this include:
#include <stdbool.h>
C99 does, if you have
#include <stdbool.h>
If the compiler does not support C99, you can define it yourself:
// file : myboolean.h
#ifndef MYBOOLEAN_H
#define MYBOOLEAN_H
#define false 0
#define true 1
typedef int bool; // or #define bool int
#endif
(but note that this definition changes ABI for bool type so linking against external libraries which were compiled with properly defined bool may cause hard-to-diagnose runtime errors).
Just add the following:
#define __USE_C99_MATH
#include <stdbool.h>
Somewhere in your code there is a line #include <string>. This by itself tells you that the program is written in C++. So using g++ is better than gcc.
For the missing library: you should look around in the file system if you can find a file called libl.so. Use the locate command, try /usr/lib, /usr/local/lib, /opt/flex/lib, or use the brute-force find / | grep /libl.
Once you have found the file, you have to add the directory to the compiler command line, for example:
g++ -o scan lex.yy.c -L/opt/flex/lib -ll
I have a problem with Nvidia's OpenCl/Cuda framework, but I think it is a gcc linking issue.
The opencl_hello_world.c example file uses following header file:
#include "../OpenCL/common/inc/CL/opencl.h"
with opencl.h using these header files:
#include <../OpenCL/common/inc/CL/cl.h>
#include <../OpenCL/common/inc/CL/cl_gl.h>
#include <../OpenCL/common/inc/CL/cl_gl_ext.h>
#include <../OpenCL/common/inc/CL/cl_ext.h>
So all the header files are in the same folder.
When I then compile with gcc opencl_hello_world.c -std=c99 -lOpenCL I get following error messages:
error: ../OpenCL/common/inc/CL/cl.h: No such file or directory
error: ../OpenCL/common/inc/CL/cl_gl.h: No such file or directory
...
Even though cl.h and the other header files are located in this folder.
Having searched SO, I then changed the includes in the opencl.h to
#include "cl.h"
#include "cl_gl.h"
how I have read here: gcc Can't Find a Included Header.
But messing around with the frameworks header files does not seem like the way to go? What would be the proper way to handle this problem?
You're using both #include "" form and #include <>, which don't search in the same paths. "" is local to your project, and the -i command line specified to gcc, <> is the 'system' path specified by -I to gcc.
You probably need to set the include path with -Ipath/to/includes in gcc's command line.