I have a situation where I recently added a bunch of pcap functionality to a shared library that I've written to do some packet sniffing/injecting stuff.
I installed the pcap stuff, i.e.
sudo apt-get install libpcap-dev
wrote all the code, then tried to build it with my makefile
All compiled and linked no problem
But when I looked more closely I noticed I hadn't specified -lpcap as a library dependency
But the linker hasn't complained about any undefined references..
So the question is how is the linker finding those pcap functions that I've called in my library code?
I was aware that if you use socket.h functions they're contained within the standard C runtime lib so you don't need to explicitly specify a library dependency. Is it the same for pcap?
Is there a way of querying where the linker has found its functions, i.e. where it found the pcap functions in this instance? I'd like to understand whats going on, rather than just being glad it worked..
To clarify, can you find the specific library file (.so or .a) that the linker has used when linking to a function that my code references?
possibly a verbose option to see exactly what the linker is doing?
Related
I am attempting to run an old program that uses tcl as well as legacy opengl. I managed to link the opengl libraries successfully; however, I cannot seem to get the tcl linker to work. For context, the program I am using came with include and lib folder. The lib folder contains tclstub86_32.lib, tclstub86_64.lib, and tkstub86.lib as well as opengl .libs. The include folder contains two folders: tcl_include and tk_include, which obviously contain all the .c and .h files for tcl and tk. The following pictures show my settings from using project -> build options:
The error I receive when compiling is:
C:\Users\amlut\Downloads\C\tkogl\curve.c|18|undefined reference to `_imp__Tcl_Free'|
And here is the bit of code that is throwing the error:
if (*line != NULL) Tcl_Free((char*)*line);
I am not sure what I am doing wrong here, any help is appreciated. Thank you.
The problem is that the code is apparently linking against the Tcl stub library (an ABI/API adaptor library) but isn't compiling to use that library but rather to use a full Tcl library instead. When building an extension package, using the stub library is a good thing as it means that the resulting code is not bound to an exact version of the Tcl (and Tk) library but rather to a version of the Tcl ABI which has a much longer support cycle.
The fix is to define the USE_TCL_STUBS and USE_TK_STUBS (that has the identical issue; you have just hit the Tcl version of it first) C preprocessor symbols when building; set them both to 1 and recompile. This is done under the Compiler Settings tab in Code::Blocks apparently.
I have a Eclipse project using C programming language. I have been stuck with a problem related to linker error since two days now. I have checked various forums to find a solution. Tried a lot of the suggestions but could not resolve it. So as a last resort, i am asking question here. My main program MotorRun.c has code which calls functions in the static library FtMscLib_Static_LIBCMT_Release.Lib which is in Libs folder in the path C:\FT-Project\Common\Libs. I am using MinGW gcc compiler.
When i run the makefile, it generates an error:
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:\FT-Project\Common\Libs\FtMscLib_Static_LIBCMT_Release.Lib
collect2.exe: error: ld returned 1 exit status
The code run by the makefile is
gcc "-LC:\\FT-Project\\Common\\Libs" -shared -o libRoboCopMinGW.exe "src\\MotorRun.o" "-lC:\\FT-Project\\Common\\Libs\\FtMscLib_Static_LIBCMT_Release.Lib"
By looking at the execution code, we can see that the paths and library name has been set correctly, but the linker just cannot find it so that it can link the library with my MotorRun.o object file. Hope someone can help me in finding a solution.
The program MotorRun.c is a very simple one, so i am not posting it here. But if necessary i can update it later. Thanks in advance!
The correct linker syntax is typically something like:
-Lpath_to_library_directory -lname
where the library filename (for a Windows static library) would be name.lib. So your above linker line needs to lose the .lib part. You may also need to prefix the -l argument with another argument -static, to instruct the linker to search for the static library FtMscLib_Static_LIBCMT_Release.Lib otherwise it might try to find the DLL instead.
By the way, there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW, so feel free to search for these also. The MinGW web pages also have numerous tips on the same topic.
TL;DR - I need to compile archive.a with test.o to make an executable.
Background - I am trying to call a function in a separate library from a software package I am modifying but the function (a string parser) is creating a segmentation violation. The failure is definitely happening in the library and the developer has asked for a test case where the error occurs. Rather than having him try to compile the rather large software package that I'm working on I'd rather just send him a simple program that calls the appropriate function (hopefully dying at the same place). His library makes use of several system libraries as well (lapack, cblas, etc.) so the linking needs to hit everything I think.
I can link to the .o files that are created when I make his library but of course they don't link to the appropriate system libraries.
This seems like it should be straight forward, but it's got me all flummoxed.
The .a extension indicates that it is a static library. So in order to link against it you can use the switches for the linking stage:
gcc -o myprog -L<path to your library> main.o ... -larchive
Generally you use -L to add the path where libraries are stored (unless it is in the current directory) and you use -l<libname> to sepecify a library. The libraryname is without extension. If the library is named libarchive.a you would still give -larchive.
If you want to specify the full name of the library, then you would use i.e. -l:libname.a
update
If the libraypath is /usr/lib/libmylibrary.a you would use
-L/usr/lib -lmylibrary
I am working on a multi-platform C program. The makefile has become pretty complicated because of all the different compilers, library locations, etc. on each machine. I figured Autoconf/Automake would be a good solution, though my previous experience using those tools was minimal.
My Makefile.am has the line LIBS=-lX11, but linking fails with the error "/usr/bin/ld: cannot find -lX11". I can work around this by adding "-L/usr/X11R6/lib/" to the definition of LIBS, but should I really need to do that? When I run ./configure, it says:
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
So it seems like Automake should know where to find it. Is there a way I can reference its location in Makefile.am without having to hardcode it, since the X11 libs will be in a different place on each machine?
Your Makefile.am should not set LIBS. If you need to link with a library, configure.ac should include a check for the library and the configure script will set LIBS accordingly. Also, Makefile.am should not specify paths to libraries. Each system should be configured so that the precompiler can find the headers and the linker can find the libraries. If the system is not set up so that the linker can find a library, the correct solution is for the user to specify the location in LDFLAGS rather than hard coding something in Makefile.am. (eg, rather than adding -L/p/a/t/h to a Makefile, you should add LDFLAGS=-L/p/a/t/h to the invocation of configure.)
I have to use LU decompostion to fit a simple model to some data (simulated) in C. An example of what I need to do is here:
However, I'm stuck with a more basic problem: how do I install packages in C and call them in my code?
I'm new in C and I'm used to R. But I have this assingment to do some tests about Matrix inversion, LU decomposision and the professor suggested using Lapack to easy things (thus, I don't need to code myself the LU decomposition etc.). But I don't know how to install the package and call it in my code, in order to use the functions of LAPACK.
I have a windows 7 64 bits and I'm using compiler Code Blocks 8.02
Thanks for any help.
Normally you don't "install" C libraries in that sense. Normally, in Windows you have three types of files. The header files, typically ending in .h, the dynamic library, .dll, and most likely some linker files (typically, .lib, .a or something). The linker and compiler will need to be able to find these files somewhere. Normally you set the include directory paths, and library directory paths.
E.g. Let's say you downloaded a library called foo, and you extract it to C:\foo.
In that folder, libfoo.a, foo.dll and foo.h reside. In Code::Blocks you will have to point include directory path to C:\foo and library path to C:\foo so that the linker and compiler know where to look for these files. Since you're linking against the foo library, you will also have to set -lfoo or something similiar in linker command line. This is GCC syntax, but I think Code::Blocks uses GCC compiler behind the scenes anyways.
In the C code you can just #include <foo.h> and the compiler will find it for you.
You need to install that library and it might actually supply a tool for that. Check their documentation (e.g. a file INSTALL or README in their distributed sources). If the library uses only headers you might only need to copy it's headers to some directory on your system, but their buildsystem might be able to do that for you.
Once that is done you would tell your IDE on where to look for the sources and if the library uses not just headers to link against the actual library file. See the documentation in the Code::Blocks Wiki on how this is done for some example cases and adapt for your library.
The simplest thing to do in your situation is to install Cygwin. You can use the setup.exe installer to install the GCC and the LAPACK libraries. When you want to use the LAPACK library, you will add the -llapack option to your GCC command line.