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
Related
I would like to compile this.
program.c
#include <libavcodec/avcodec.h>
int main(){
int i = avpicture_get_size(AV_PIX_FMT_RGB24,300,300);
}
Running this
gcc -I$HOME/ffmpeg/include program.c
gives error
/tmp/ccxMLBme.o: In function `main':
program.c:(.text+0x18): undefined reference to `avpicture_get_size'
collect2: ld returned 1 exit status
However, avpicture_get_size is defined. Why is this happening?
However, avpicture_get_size is defined.
No, as the header (<libavcodec/avcodec.h>) just declares it.
The definition is in the library itself.
So you might like to add the linker option to link libavcodec when invoking gcc:
-lavcodec
Please also note that libraries need to be specified on the command line after the files needing them:
gcc -I$HOME/ffmpeg/include program.c -lavcodec
Not like this:
gcc -lavcodec -I$HOME/ffmpeg/include program.c
Referring to Wyzard's comment, the complete command might look like this:
gcc -I$HOME/ffmpeg/include program.c -L$HOME/ffmpeg/lib -lavcodec
For libraries not stored in the linkers standard location the option -L specifies an additional search path to lookup libraries specified using the -l option, that is libavcodec.x.y.z in this case.
For a detailed reference on GCC's linker option, please read here.
Are you mixing C and C++? One issue that can occur is that the declarations in the .h file for a .c file need to be surrounded by:
#if defined(__cplusplus)
extern "C" { // Make sure we have C-declarations in C++ programs
#endif
and:
#if defined(__cplusplus)
}
#endif
Note: if unable / unwilling to modify the .h file(s) in question, you can surround their inclusion with extern "C":
extern "C" {
#include <abc.h>
} //extern
I have simple application:
#include <stdio.h>
int main( int argc, char ** argv )
{
printf( "hello");
exit( 0 );
}
When I compile it with command
gcc -c count_words.c
I have warning:
warning: incompatible implicit declaration of built-in function ‘exit’ [enabled by default]
exit( 0 );
I was trying to find where exit() function is defined. And found that it is defined in stdlib.h. But it is not included in my project and no additional libs defined in compile command.
Correct me if I'm wrong, but looks like gcc takes some libs as default. What are these libs and is it possible to tell gcc not include them?
Why compiler is not happy regarding exit(0) assuming that it somehow includes stdlib.h as default?
Let's take your example:
#include <stdio.h>
int main( int argc, char ** argv )
{
printf("hello\n");
exit(56);
}
Although we get a warning on compilation:
~$ gcc test.c -o test
test.c: In function ‘main’:
test.c:6:5: warning: implicit declaration of function ‘exit’ [-Wimplicit-function-declaration]
exit(56);
^
test.c:6:5: warning: incompatible implicit declaration of built-in function ‘exit’
test.c:6:5: note: include ‘<stdlib.h>’ or provide a declaration of ‘exit’
Anyway, I think you have tried to run it and make sure it works:
~$ ./test
hello
~$ echo $?
56
#Mat was right when he said that:
You're mixing up including headers and linking to libraries. Those are
two completely different things
The C compiler and linker are totally separate tools. Let's look on this. Actually, this program depends on the standard C library (as all programs if you didn't pass -nostdlib to compiler) and a couple of system libraries (like loader and vdso). You may see it with:
~$ ldd test
linux-vdso.so.1 (0x00007fff1b128000)
libc.so.6 => /lib64/libc.so.6 (0x00007f804389f000)
/lib64/ld-linux-x86-64.so.2 (0x0000557744537000)
These three library is a minimal set for any program. The exit function is defined in the standard library or libc.so.6 in our case. Now let's look on the compilation process in verbose mode. You can achieve this by the passing -v or --verbose option to compiler:
gcc test.c -o test --verbose
If you will execute this, you will find lines like these:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include
/usr/local/include
/usr/include
So, compile knows where to search header files for stdlib and it starts to search it to find declaration for non-local functions. Note that it searches only in header files which are included in your source code file. It can find printf declaration in thestdio.h, but can't locate declaration of the exit.
After this step, the compile starts to link your program with libraries:
/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/collect2 ... -lc ...
Where collect2 is gcc util which tries to link your program with lc which is standard C library. Note that the process consists from two steps: compilation and linking. That's why your program works.
Additionally, gcc supports -M option which will tell you about dependencies of the main file. So, if you will execute it, you will see the set of header files including stdio.h, but not stdlib.h:
$ gcc -M test.c
test.o: test.c /usr/include/stdc-predef.h /usr/include/stdio.h \
/usr/include/features.h /usr/include/sys/cdefs.h \
/usr/include/bits/wordsize.h /usr/include/gnu/stubs.h \
/usr/include/gnu/stubs-64.h \
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/stddef.h \
/usr/include/bits/types.h /usr/include/bits/typesizes.h \
/usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/stdarg.h \
/usr/include/bits/stdio_lim.h /usr/include/bits/sys_errlist.h
Or even better, try to pass -E option to gcc:
$ gcc -E test.c
and you will see result right after the first stage - preprocessing stage. I think it is the easiest way to understand why you are getting this warning.
assuming that it somehow includes stdlib.h as default?
It simply doesn't. That wouldn't be standards-compliant.
So, when you use exit, it has never been declared, so there's you implicit declaration upon usage. However, the fact to you implement exit nowhere else will only become a problem at the final linkage.
Now, GCC knows damn well that you are about to get into trouble, so it warns you.
Simply actually include stdlib.h and you should be fine.
The "library" in question is gcc/builtins.def from the gcc source tree.
That's not just a header file though, and it does not provide declarations for you to use. But it has proper prototypes to check yours against.
Calling undeclared exit() results in implicit declaration like this:
int exit(int);
Search "c implicit declarations" for the gory details. In this case however GCC has its own prototype for exit() from builtins.def:
void exit(int) __attribute__((nothrow,noreturn));
These declarations do not match, and that's what you are being warned about.
Your code works with warning not with error. If you add
#include <stdlib.h>
then no warning anymore ;)
I try to compile a library in C that need "math.h", here is the begining of the .c file:
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#include "sparse_matrix.h"
...
and I compile with this command:
gcc -c ./sparse_matrix.c -o sparse_matrix.o -lm -Wall -pedantic -std=c99 -g -O
But even with the #include done and the flag -lm after the file (I've tried at the end of the line but nothing changed) I still get the error:
undefined reference to « sqrt »
collect2: error: ld returned 1 exit status
I don't get it after an hour of googling the issue.
I'm working with gcc 4.9 under ubuntu 14.10 (utopic unicorn).
Thank for any help in advance!
I don't think that is the command you're running (well, it may be one of them, but it's certainly not the one causing your error).
The -c option to gcc tells it to only create the object files (and you're specifically sending the output to sparse_matrix.o, an object file rather than an executable one).
In that case, the linker should not be called at all.
In fact, with a dummy sparse_matrix.c of:
#include <math.h>
int main(void) {
return (int)(sqrt(16.0));
}
your command works fine and, when I complete the process with:
pax> gcc -o sparse_matrix sparse_matrix.o -lm
pax> ./sparse_matrix
pax> echo $?
4
you can see that it also runs just fine.
It may be that you're leaving off the linker flags (such as -lm) from the actual link stage, which would cause this problem. They should have no effect on the compilation stage (unless they affect both compile and link stages but -l isn't one of those).
And, by "leaving off", I also include the possibility of "misplacing". Some linkers are positional in the way they handle libraries in that they will only extract objects from libraries if they satisfy an undefined symbol at the point where they're listed.
So, the command:
linker sparse_matrix.o -lm ...
would work because the .o file introduces an unsatisfied reference to sqrt, which is satisfied by libm. If your linker is positional, then:
linker -lm sparse_matrix.o ...
wouldn't work because, at the time of processing libm, there were no unsatisfied symbols so nothing was extracted. The undefined reference to sqrt is then introduced after that point and there are no other objects or libraries to satisfy it.
Whether ld or the gcc linker stage has that limitation, I don't know, I'm just raising the possibility as something to watch out for.
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.
I am trying to compile the example libusb.c provided by libusb package (if you dl the source code.)
It doesn't work to say the least.
#include <stdio.h>
#include <sys/types.h>
#include <libusb/libusb.h>
That causes it to fail, there is no libusb/libusb.h it's usb.h, so I change that. And it fails in new and innovative ways.
I've copied the file over, exactly, and named it example.c
I am using these commands and variations:
gcc -o example example.c -lusb -L /usr/lib/libusb.a
gcc -o example example.c -lusb -L /usr/lib/libusb.so
The errors I get when compiling are:
example.c:25: error: expected ‘)’ before ‘*’ token
example.c: In function ‘main’:
example.c:46: error: ‘libusb_device’ undeclared (first use in this function)
example.c:46: error: (Each undeclared identifier is reported only once
example.c:46: error: for each function it appears in.)
example.c:46: error: ‘devs’ undeclared (first use in this function)
Line 25: static void print_devs(libusb_device **devs)
Line 46: libusb_device **devs;
At first I followed a tutorial, and that failed to compile, in more or less the same ways, so I decided to just try the provided example, and that failed.
Can anyone help me out? Explain what I am doing wrong, cause I am lost on this one.
This is what I had to do on Debian. It should be at least similar in Ubuntu.
Install libusb-1.0-0-dev
Instead of:
#include <libusb/libusb.h>
do:
#include <libusb.h>
Compile with:
gcc example.c `pkg-config --libs --cflags libusb-1.0`
Just en explanation why your attempt to replace libusb/libusb.h with usb.h fails: usb.h is a header from linux-headers, not from libusb-dev. You need #include <libusb.h> instead.