I'm trying to use pcap functions, but it giving me compiler error:
project.c:(.text+0x140): undefined reference to `pcap_open_offline'
I have installed library and while compiling I give "-lpcap" at the and as it advised in many forums.
What can be wrong, please?
You need to understand what the arguments evoke into the linker.
I am supposing you are using Linux system with gcc, using ld as linker (note that this could change depending on the system and the linker used).
In such case, -Lpath tell the linker where to look for the libraries that you tell it that are needed to be linked with your program to create the final binary. For example -L/usr/lib.
when you type in for example:
# gcc -L/usr/lib -lcap my_program.c -o my_program
You are telling the linker to append /usr/lib to the list of paths to locate libraries, and to link the dynamic library "libcap.so" with your program.
Other modifiers for the path used to locate libraries is LD_LIBRAY_PATH (the name of this environment variable could change from one system to another, review the manual of your linker).
As you are using "-lcap" the error you get look to be related with the fact that no path is found where libcap.so exist. Locate that file into your system and pass the argument
-L/path/to/the/directory/that/contain/libcap.so
By the way, try to run this before any other thing and recompile:
# sudo ldconfig
Related
I am writting an mqtt communication script where I am using the paho library.
the files .so exist in the /home/chaima/paho.mqtt.c/build/output directory.
but when trying to compile the code using the gcc compiler, I am getting this error
/usr/bin/ld: cannot find -l/home/chaima/paho.mqtt.c/build/output
I've tried so many solutions but none of them worked for me.
please if you need further information let me know about it.
Thank you in advance.
The -l switch asks the linker to use a certain library. It should followed by the name of a library or a file system path to the library.
/home/chaima/paho.mqtt.c/build/output is a path to a directory, not a library.
The -L switch tells the linker to use a certain directory as a place to look in for libraries. After -L/A/B/C and -L/D/E/F, the linker will look in the directories /A/B/C and /D/E/F for libraries. For example, with -L/A/B/C -L/D/E/F -l foo, the linker will look for a file named /A/B/C/foo.extension and /A/B/C/foo.extension, where extension is one of the file name extensions used for libraries, such as a or so in foo.a or foo.so.
To get the linker to use your libraries in /home/chaima/paho.mqtt.c/build/output, use -L/home/chaima/paho.mqtt.c/build/output followed by -lName0 -lName1 -lName2 …, where Name0, Name1, Name2, and such are the names of your libraries. You an also ask the linker to use a library by giving its full path and name with no switch, as in /home/chaima/paho.mqtt.c/build/output/foo.so.
Both the ld command (to invoke the linker directly) and the gcc command (an overall command that will compile, link, and perform other tasks) accept these switches. In the future, read the manual page (also called the “man page”) or other documentation of the tools use use. The man page for ld explains what its -l and -L switches do. On Unix systems, you can usually see the man page for ld by executing man ld and the man page for gcc by executing man gcc. The current GCC documentation is also here.
I've recently begun using a new ELF loader. The loader requires you to link your applications with ld -r.
The problem is that GCC no longer warns me of undefined functions, and then the loader (obviously) fails to find them.
How do I link with ld -r, and get the undefined symbols method.
I am using ld -r for relocation purposes, so a different way to include relocations will also work for me.
In your makefile, define an intermediate target where you link with all the options but the -r one, to a file in the temporary directory (so you're sure not to use it).
If this phase succeeds, then proceed to the real link with the -r option.
I'm using OSX command line gcc and attempting to build a dynamic library. when I do the build I get the following warning. How is it it is not finding this library given /usr/lib is well known? And /usr/lib does indeed exist on my machine
this is what I am using:
gcc -arch i386 cata/*.c -dynamiclib -o build/cata.dylib -LC_ID_DYLIB=/usr/lib
Thanks
the way i solved it was to make it so the string that got stuck in the library (on where to find the library at runtime) was relative to nowhere -- if that makes sense. so it would be forced to use the LD_LOAD_PATH.
I was using the other flags because someone suggested I use them.
so the gcc i ended up using is this:
# my tree is like this
# cata/*.c
# build/*.dylib
#
cd build
gcc -arch i386 ../cata/*.c -dynamiclib -o cata.dylib
Doing this compiles/makes a library in the same directory where it thinks it is 'used' (basically having no path). I am now free to put it somewhere else. When it is later linked at compile time by a different program and then examined using
otool -L
it appears with no path in front of the library name. This is apparently preferable as now when the system goes to try to find it it resorts to looking at the standard libraries and eventually finds it (because I install it to one of the standard locations).
In the original way, otool -L was showing it having a required path of
'build/cata.dylib'
This made it un-findable and which is why i was trying to use the apple documentation to get around the problem.
This doesn't really solve why LC_ID_DYLIB doesn't work. I looked into the Loader.h file (line 643) and it has room for an identifier(0xd), a path, and a structure, so I don't really understand why my path wasn't getting picked up. but its two different topics. Loader.h is runtime and the other is gcc AFAIK. I'm still learning apple.
I have a makefile in Mac OS X and the last command line for the final compilation is:
gcc count_words.o lexer.o -lfl -o count_words
but it responds:
ld: library not found for -lfl
collect2: ld returned 1 exit status
I found that the library libfl.a is in /opt/local/lib/ and that modifying the command line to read:
gcc count_words.o lexer.o -L/opt/local/lib/ -lfl -o count_words
it works perfectly, but I've read when a prerequisite of the form -l is seen, GNU make searches for a file of the form libNAME.so; if no match is found, it then searches for libNAME.a. Here make should find /opt/local/lib/libfl.a and proceed with the final action, linking, but this is not happening.
I tried using LD_LIBRARY_PATH, then realized that as I'm working on Mac I have to use DYLD_LIBRARY_PATH, I exported the variable pointing to /opt/local/lib and tried running the makefile again, didn't work. Found another environment variable called DYLD_FALLBACK_LIBRARY_PATH, exported, didn't work.
What should I do?
DYLD_LIBRARY_PATH (and LD_LIBRARY_PATH on other unices) provides search paths for the loader, to resolve linked libraries at runtime. LIBRARY_PATH is the relevant var for providing paths that the compiler will pass to the linker at link time.
However, OS X's linker ld64 has no way to prefer static linking over dynamic in the presence of both kinds of libraries, which means your only option is to pass the full path to the archive anyway.
gcc count_words.o lexer.o /opt/local/lib/libfl.a -o count_words
Which is really all that -l does after it searches the paths and expands the lib name.
make does not search for the library at all. make just invokes other tools that do that. (ld, which is invoked by gcc) All you need to do is pass the proper flags to gcc from make. Possibly, this just means adding
LDFLAGS=-L/opt/local/lib
to your Makefile (or editing the command directly, as it appears you have done during testing), but it is difficult to tell without seeing the Makefile.
Probably this question Library not found for -lfl is relevant. For some reason if you try -ll instead of -lfl it works on OS X. Also see http://linux-digest.blogspot.hk/2013/01/using-flex-on-os-x.html
I am new with using gcc and so I have a couple of questions.
What do the following switches accomplish:
gcc -v -lm -lfftw3 code.c
I know that lfftw3 is an .h file used with code.c but why is it part of the command?
I couldn't find out what -lm does in my search. What does it do?
I think I found out -v causes gcc to display programs invoked by it.
-l specifies a library to include. In this case, you're including the math library (-lm) and the fftw3 library (-lffw3). The library will be somewhere in your library path, possibly /usr/lib, and will be named something like libffw3.so
From GCC's man page:
-v Print (on standard error output) the commands executed to run the
stages of compilation. Also print the version number of the
compiler driver program and of the preprocessor and the compiler
proper.
-l library
Search the library named library when linking. (The second
alternative with the library as a separate argument is only for
POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option;
the linker searches and processes libraries and object files in the
order they are specified. Thus, foo.o -lz bar.o searches library z
after file foo.o but before bar.o. If bar.o refers to functions in
z, those functions may not be loaded.
The linker searches a standard list of directories for the library,
which is actually a file named liblibrary.a. The linker then uses
this file as if it had been specified precisely by name.
The directories searched include several standard system
directories plus any that you specify with -L.
Normally the files found this way are library files---archive files
whose members are object files. The linker handles an archive file
by scanning through it for members which define symbols that have
so far been referenced but not defined. But if the file that is
found is an ordinary object file, it is linked in the usual
fashion. The only difference between using an -l option and
specifying a file name is that -l surrounds library with lib and .a
and searches several directories.
libm is the library that math.h uses, so -lm includes that library. You might want to get a better grasp of the concept of linking. Basically, that switch adds a bunch of compiled code to your program.
-lm links your program with the math library.
-v is the verbose (extra ouput) flag for the compiler.
-lfftw3 links your program with fftw3 library.
You just include headers by using #include "fftw3.h". If you want to actually include the code associated to it, you need to link it. -l is for that. Linking with libraries.
arguments starting with -l specify a library which is linked into the program. Like Pablo Santa Cruz said, -lm is the standard math library, -lfftw3 is a library for fourier transformation.
Try man when you're trying to learn about a command.
From man gcc
-v Print (on standard error output) the commands executed to run the
stages of compilation. Also print the version number of the
com-
piler driver program and of the preprocessor and the compiler
proper.
As Pablo stated, -lm links your math library.
-lfftw3 links in a library used for Fourier transforms. The project page, with more info can be found here:
http://www.fftw.org/
The net gist of all these statements is that they compile your code file into a program, which will be named the default (a.out) and is dependent on function calls from the math and fourier transform libs. The -v statement just helps you keep track of the compilation process and diagnose errors should occur.
In addition to man gcc which should be the first stop for questions about any command, you can also try the almost standard --help option. Even for commands that don't support it, an unsupported option usually causes it to print an error containing usage information that should hint at a similar option. In this case, gcc will display a terse (for gcc, its only about 50 lines long) help summary listing the small number of options that are understood by the gcc program itself rather than passed on to its component programs. After the description of the --help option itself, it lists --target-help and -v --help as ways to get more information about the target architecture and the component programs.
My MinGW GCC 3.4.5 installation generates more than 1200 lines of output from gcc -v --help on Windows XP. I'm pretty sure that doesn't get much smaller in other installations.
It would also be a good idea to read the official manual for GCC. It is also helpful to read the documentation for the linker (ld) and assembler (often gas or just as, but it may be some platform specific assembler as well); aside from a platform-specific assembler, these are documented as part of the binutils collection.
General familiarity with the command line style of Unix tools is also helpful. The idea that a single-character option's value might not be delimited from the option name is a convention that goes back essentially as far as Unix does. The modern convention (promulgated by GNU) that multiple-character option names are introduced by -- instead of just - implies that -lm might be a synonym for -l m (or the pair of options -l -m in some conventions but that happens not to be the case for gcc) but it is probably not a single option named -lm. You will see a similar pattern with the -f options that control specific optimizations or the -W options that control warnings, for example.