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.
Related
I am watching a seminar on writing 2D games in C, on YouTube here:
https://www.youtube.com/watch?v=yFLa3ln16w0&t=654s
The instructor says to install the SDL software packages, using apt-get install. I already have these files. I checked, and they are in the C search path, in the directory /usr/include/SDL2. The instructor has a GitHub with example code that demonstrates the basics of SDL. Here is the GitHub repository:
https://github.com/tlively/sdl_seminar
Here is SDL's website:
https://www.libsdl.org/
The problem is, when I try to compile the file hello1_sdl.c (in the GitHub repoistory) using gcc -o hello1_sdl hello1_sdl.c, it gives me an error. I looked up what it meant, and it's a linker error. I don't understand why this is happening, as the header files are in the appropriate place.enter image description here
How do I fix this?
The include files for the C/C++ compilers are only half the story. You also need to tell the linker to use the library! If you have everything set up properly, all you should need to do is add -lSDL2 to your final command line (the one with -o that does the linking.)
See more examples at: Lazy Foo' Productions
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?
Im working on a program for my studies, that uses an open source library. It is meant to run on Raspberry Pi (Raspbian Kernel). Because of my intention to be also able to load it on a PLC i used mostly pure C. The Library itself comes with suitable header and .c files.
When i use the pre installed GCC compiler on the Raspberry my program compiles without any errors and works fine. Now here comes my problem:
I tried to get this projekt to work on windows using code::blocks IDE with MinGW installed. I revisited the library and downloaded the zip for windows (apperently same header and .c file, but also .lib and .dll included).
I set the search directories and linker settings within the project and included the header as usual with #include "header.h" for the relative path. It doesn't compile and gives alot multible definition and first defined here which usually indicate wrong linking and inclusion.
As i tried to identify some of this definitions i noticed that the functions which cause errors are defined one time in the library.c file. At the beginning of this .c file it also includes the header one time.
Short summary:
This works with raspbian GCC:
$ gcc -sdt=c99 main.c library.c -o executable
but gives errors with Windows IDE + MinGW
Am i missing something serious? The dynamic link lib should only be used by the executable afterwards. I thought maybe the libraby.c gets replaced by the library.lib but if i remove one of them the project doesn't know the functions. I also searched for wrong inclusions. I'm really at the end of my knowledge here, and also searched for posts that would help me, but those were mostly "where is the linker path" or "inclusion of .c files". It seems so an simple problem which i overlooked.
Any help Would be appriciated. I will supply more details if needed.
Thanks!
Edit (2):
obj\Debug\open62541.o:open62541.c:(.text+0x3152a): undefined reference to `__imp_shutdown'
obj\Debug\open62541.o:open62541.c:(.text+0x3153f): undefined reference to `__imp_closesocket'
obj\Debug\open62541.o:open62541.c:(.text+0x315a7): undefined reference to `__imp_send'
obj\Debug\open62541.o:open62541.c:(.text+0x315b9): undefined reference to `__imp_WSAGetLastError'
.....
Edit (3)
Answer 1!
Compiled good now, thanks everyone.
It looks like your library is open62541.
There are two ways to include the library in your source:
Build a shared/static lib and link it to your code
Enable Amalgamation which generates a single .c and .h file which you can directly compile with your code
You are combining both methods on mingw which adds the whole library two times.
Probably you only want to link the .c file without the .lib, thus your compile command should look something like this:
gcc -sdt=c99 main.c open62541.c -o test
Additionally, since open62541 needs the ws2_32 library on windows, the compiler should be called with:
gcc -std=c99 main.c open62541.c -o test -lws2_32
I am attempting to follow the besic guide given here on embedding lua into C. I copied the code verbatim into my own embed.c file and executed the exact compiler command listed:
cc -o embed embed.c \
-I/usr/local/include \
-L/usr/local/lib \
-llua -llualib
I get the error:
embed.c:19:14: error: invalid storage class for function ‘openlualibs’
After which I moved the functions outside of main, compiled again, and got:
/usr/bin/ld: cannot find -llualib
I am at a loss for why I cannot compile this. lua is installed properly. has anyone else encountered these problems? If this is a bad tutorial, please feel free to simply direct me to a batter one.
On some Linux distributions you may need to install the lua-devel (or similar named) package, in order to get the proper header files and library symlinks required for compiling and linking projects against the package. If you do have a liblualib-<version>.so.<version>, for example liblualib-5.so.5.0, you may need to install the devel package.
Starting with lua 5.1, liblualib does not exist. Here is the release announcement: http://lua-users.org/lists/lua-l/2005-05/msg00186.html
I've had somewhat similar problems when embedding Lua. What I found that works for me is linking the dynamic link library (dl) and the math library (m). The math library may not be necessary if you're not using the lmath standard library.
cc -o embed embed.c -I/usr/local/include -L/usr/local/lib -llua -lm -ldl
This, of course, assumes that /usr/local/ is where the Lua files are installed, which is probably true.
As for the tutorial you linked to, I think it may be very out of date. Besides liblualib no longer existing, there are individual functions to open each standard library. These are the luaopen_* functions. Here's the relevant 5.1 reference manual entry. (I assume you're using 5.1, since that seems to be the version available in the packages) As for a better tutorial, I suggest the Programming in Lua book. Unfortunately, it was written for Lua 5.0. It is still mostly relevant, but I suggest you look over the relevant sections of the 5.1 reference manual, too.
Let me start out by saying that I'm not a C developer and I know very little about actually writing real world C code. I've been doing some research to find a xUnit framework that I can use to write tests for C code and based on what I've found it seems like Unity is the one that I want to go with. It seems simple enough, but I really just don't know what to do after I download the zip file from Unity's website. It doesn't seem to have the normal configure/make/make install, and if it did, I'm not sure that is what I should be using anyway. It does, however, ship with some rake tasks, but none of those seemed to be any kind of "install" task. As a last resort I tried to just copy the 3 source files in with my code (which I really hope is not the right thing to do), but when I try that I get an error trying to compile my c file with gcc, but I think this should be working. Here is my set up:
src/
mycode.c
unity.c
unity.h
unity_internals.h
Here is the source for mycode.c
/* mycode.c */
#include "unity.h"
void test_sample(void)
{
TEST_ASSERT_EQUAL_INT(0, 0);
}
When I run gcc mycode.c I get:
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
"_UnityAssertEqualNumber", referenced from:
_test_sample in ccyHByv6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
(I get a similar error when I try to compile unity.c with gcc). Which I assume means that the code that ships with unity requires a different compiler than what I have which is:
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
or that maybe unity is not compatible with a 64 bit processor... (I'm running on Mac OS 10.7.3 with a 2.4 GHz Intel Core 2 Duo processor - another thing that may or may not be relavent is that I've got XCode Version 4.3 (4E109) and also Command Line Tools for XCode) At this point I'm just grasping at straws and I'm in way over my head.
My question is, what is the correct process to go through to take a 3rd party C library, such as Unity, and make it available to my C code? Do I need to install something like in Python or Ruby or add something to my path like in Java or something else? Shouldn't just dropping unity's code in with mine work? Am I doing something wrong or is Unity or both? I really just want to be able to test drive C code using Unity. Any help would be greatly appreciated. Thanks in advance!
First, try 'gcc *.c -o mytest'. This will compile all of the C source files into object files, and then link them together into the binary 'mytest'. Keep in mind that all C source files have to be compiled to object files before they can be linked together. (A library is just a bunch of packaged object files.)
If you had a unity library installed in /usr/lib, you could do something like 'gcc mycode.c -lunity -o mytest'. If you had a unity library sitting in the current directory, you might do 'gcc mycode.c ./unity.a -o mytest'. This tells the compiler to look for a file named 'unity.a' in the current directory. Some libraries build .so files ('shared object' files, similar to DLLs in Windows). Replacing 'unity.a' with 'unity.so' should work if that is the case. (I'm assuming a Unix/Linux environment here.)
As an alternative to Unity, look at Google Test, which can be used with C code. I know it is supported on the Mac as well. The primary benefit is a large and active community. More information on Google Test from another SO question: Is Google Test OK for testing C code?
I figured out my problem. It turns out that unity requires you to define a setup and a teardown function and if you do not, you will get errors similar to the one that I was running into.