I'm trying to run a program in Code::Blocks, and in my program I have used the hash functions, such as hsearch and hcreate, but Code::Blocks seems to not allow them.
I have the header:
#include <search.h>
included already, but errors such as "undefined reference to 'hsearch' " still comes up.
Is there anyway to allow these functions to run in Code::Blocks at all?
Header files are just containing the declarations. You need to have the libraries installed, which are containing the implementation.
And that what it is telling you. It found the declarations just fine, however the linker did not find the libraries, hence the linkage error.
On Linux, the search.h and its implementation is part of the libc, so it is already ready to use. On Windows, however, you need to get a binary version of it, set up the library path for Code::Blocks, and use the linker options in the settings.
Related
This may seem a little stupid:) But it's been bothering a while. When I include some header files which are written by others in my C++/C program, how does the compiler know where is the implementation of the class member function declared in the header files?
Say I want to write some program which takes advantage of the OpenCV library. Normally I would want to use:
#include <opencv2/core/core.hpp>
#include <opencv2/imgproc/imgproc.hpp>
#include <opencv2/highgui/highgui.hpp>
However, these are just header files which, as far as I can tell, only declares functions but without implementation. Then how does the compiler know where to find the implementation? Especially when I want to build a .so file.
There is a similar post. Basically it said thrid-party library, esp. commercial product don't release source code, so they ship the lib file with the header. However, it didn't make clear how does the compiler know where to find the lib file. In addition, The answer in that post mentioned if I want to compile the code of my own, I would need the source code of the implementation of those header files. Does that mean I cannot build a .so file without the source of the implementation?
In general, the implementation is distributed as form of pre-compiled libraries. You need to tell the compiler where they are located.
For example, for gcc, quoting the online manual
-llibrary
-l library
Search the library named library when linking. [...]
and,
-Ldir
Add directory dir to the list of directories to be searched for -l.
Note: you don't need to explicitly specify the standard libraries, they are automatically linked. Rather, if you don't want them to be linked with you binary, you need to inform the compiler by passing the -nostdlib option.
The exact answer is platform specific, but in general I'd say that some libraries are in fact header-only, and others include the implementation of the library's methods in binary object files. I believe OpenCV belongs to the second kind, i.e. provides the implementation in object files, for either dynamic or static linking, and your program links against them. If your build works, then it is already configured to link against those libraries. At this point the details become very much platform and build-system specific.
Note that for common platforms like Windows, Mac and Linux you seldom need to build popular libraries like OpenCV yourself. You mentioned .so files, which implies dynamic linking on Linux. This library is open-source so in theory you could build it yourself, but in practice I'd much rather use my distribution's package installation tool (e.g. apt-get or yum) to install opencv-dev (or something similar) from my distribution's repository.
As the others already explained, you need to tell your compiler where to look for the files.
This implies that you should know which path to specify for your compiler.
Some components provide a mechanism where you don't need to know the exact path but can automatically retrieve it from your system.
For example if you want to compile using GTK+3 you need to specify these flags for your compiler:
CFLAGS:= -I./ `pkg-config --cflags gtk+-3.0`
LIBS:= -lm `pkg-config --libs gtk+-3.0`
This will automatically result in the required include and library path flags for GCC.
The compiler toolchain contains at least two major tools: the compiler and the link editor (it is very common to name compiler the whole chain, but strictly speaking it is wrong).
The compiler is in charge of producing object code from the available source code. In that phase the compiler knows where to locate standard headers, and can be told to use non-standard dirs to locate headers. For example, gcc uses -I to let you specify some more alternate dirs that may contains headers.
The link editor is in charge of producing executable files (its basic common usage) from object codes. To produce an executable it needs to find every implementation of declared things at compile-time for which you didn't provide source code. These can be other object codes, object codes in libraries, etc. The link editor knows where are located standard libraries and can be told to let you specify non-standard dirs. For example you can tell the gcc toolchain to use alternate dirs with L that may contain libraries. You may be aware that link edition is now usually a two phase process: location-and-name-resolution at link-time and real link-edition at run-time (dynamic libraries are very common).
Basically a library is just a collection of object code. Consult internet to see how you can easily build libraries either from source code of from object code.
It seems we are free to use Windows API simply by including header files needed. However, i couldn't make myself understand how this is possible given that header files do not have function definitions but declarations, which is supposed to be considered as an error in that it lacks implementation details. In what way does a compiler locate an implementation detail and map it into memory?
The Windows API is implemented in DLLs that are installed when you install Windows. Those DLLs are in the System directory and have names like User32.dll, Kernel32.dll, etc.
As you correctly noted, the Windows API header files supplied with your compiler contain only the declarations. When your C program calls one of those functions (or any other function that's identified in a header file but not actually compiled with your project), the compiler places a record in the generated object file that says, in effect, "I need to call a function called GetWindowRect (or whatever the name of the function you called)."
The linker is what actually resolves the names. If you look at your linker options, you'll see that it's linking some libraries like User32.lib, Kernel32.lib, etc. Those libraries contain compiled functions that are little more than stubs--code that causes the corresponding DLL to be loaded, and then calls the function in the DLL.
It's a little bit more involved than that, but that's the general idea. In summary:
You include the Windows API header files.
Your code makes a call to one or more Windows API functions that are declared in those header files.
The compiler makes a note for the linker to resolve those API function calls.
The linker resolves the calls by finding the stub functions in the libraries that you specify on the linker command line.
At runtime, a call to one of those functions causes the corresponding DLL to be loaded, and then control is branched to the function in the DLL.
It works the same as any other library, for example C stdlib - your program only needs to 'know' the prototypes of functions (and thus the underlying symbol names). After compilation comes linking - that's when the symbols (function definitions) that are missing get 'linked' with a correct library.
This is for my company, so I'm leery of being too specific, but I'll try.
I am attempting to add support for some existing ANSI C code to our platform. I am using GCC 4.7.2 as well as the GNU linker. We use part of newlib, but also some other C libraries, specifically libc.a. The end goal of this is to get an EXE or ELF image (this is for a PowerPC architecture micro) to put into the micro's RAM. This is being done on Windows XP. I am simply using a batch file, not a build environment or toolchain.
One of my build errors is a multiple definition problem of malloc/free functions. The cmd window spits out the error that there are definitions of these in both malloc.o and mallocr.o. Both of these are within libc.a. I've been told the "r" in mallocr.o is for reentrancy. I've also been told our platform does not support reentrancy.
I'm trying to resolve this error by preventing the linking of mallocr.o from within libc.a. This is the part where I am lost, I don't know how to do this. Google hasn't turned up anything helpful, and I haven't found a question on this site yet that answers my problem. I don't know if this is even possible.
There is really no specific code snippet to include in this question. Below is the error from the cmd window. I've *'d out company specific things I am not comfortable sharing.
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(mallocr.o): In function `free':
mallocr.c:(.text+0x19c): multiple definition of `free'
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(malloc.o):malloc.c:(.text+0x28): first defined here
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(mallocr.o): In function `malloc':
mallocr.c:(.text+0x468): multiple definition of `malloc'
c:\***\platform\2_2_0_r2013-2_x86-32\tools\gcc_4_7_2\ppc\bin\..\powerpc-eabi\lib\libc.a(malloc.o):malloc.c:(.text+0x0): first defined here
I am developing a bare metal C applications on an ST ARM-Cortex-M3. I have also developed libraries that are usable across all these applications.
I used to use Keil ARM-MDK, but want to move over to GNU-GCC. I thus downloaded the latest version of GCC and started recompiling the code.
Although similar questions to this one have been answered, it does not solve my problem ans therefore I am posting my question.
I have a problem with the following:
Lib_Flash has a function Read_Flash(). Lib_AppCfg links in Lib_Flash as it uses Read_Flash().
My application (App) links in both Lib_Flash and Lib_AppCfg. App also uses Read_Flash() for some specific FLASH checks.
In Keil MDK-ARM it worked fine.
With GCC, when functions using Lib_AppCfg are built, I get errors stating that Read_Flash() is an "undefined reference".
I am not sure where the problem lies. Is it in the linking of the Lib_Appcfg is built or is the problem when I link App?
Please advise. If you need additional information, please let me know.
The GNU linker by default searches the libraries once in the order listed on the command line. So if a library later in the list has a reference to symbol defined in an earlier library or object file, then it cannot be resolved.
The simple solution is to use library grouping; this causes the linker to repeatedly search a list of libraries until no further synbols can be resolved. If you are invoking the linker (ld) separately, then the linker options are:
--start-group _Flash _AppCfg --end-group
or the alternative form
-( _Flash _AppCfg -)
See the GNU linker manual for details. If driving the linker indirectly through gcc you pass linker options via the -Wl option, something like:
-Wl,-(,_Flash,_AppCfg,-)
I think.
It sounds to me like you have got an ordering problem in your libraries. Some linkers will rescan all the libraries on the command line till all references are resolved (or can't be resolved). Other linkers work sequentially along the link line.
In particular, this means that if library A defines a symbol SYM_A and library B which comes after library A references this symbol, it won't be resolved on the 2nd type of linker, and your link will fail.
To get round this, you can do one or more of the following
Reorder the libraries
Replicate libraries on the link line where
necessary
Refactor your libraries so there aren't mutual
dependencies between them (that is A references symbol SYMB, which
is defined in B, but B references SYMA)
I am trying to static link lua into a FreePascal application. I have fixed all of the errors during the linking except this one.
Undefined Symbol: __strtod
All of the other Undefined Symbols I was able to link in via libkernel32.a, libuser32.a and libmsvcr.a from the MinGW compiler which I used to compile the liblualib.a that I am linking in in place of using the dll.
I would like to have this static linked and not dynamic linked. So, would anyone happen to know which .a lib file ___strtod is defined in or know how I can search and find this out.
To my knowledge it is a C99 function and MinGW, GCC support it. So, I would think that it would be in one of the lib (.a) files that come with it.
Thanks,
Turns out that I never came back and answered my question when I got it to work.
I searched online for the function in C and then compiled it to a static library using MinGW. With the libstrtod.a file that I created I was able to static link it into the program compiled by FreePascal.
I have since had to give up the source for this project since it was on contract, I will try to remember to make an example of this to share.
Thanks for all of the responses and suggestions.
to be continued...
It's part of the C library, libc. However I don't know you can statically link to it. (Are there yet systems which provide static versions of libc?)
Libc should be linked by default in a C program.
Just create a make file that uses a static version of the library.
The static libraries are normally much bigger than the dynamic ones.
You could download newlib and compile the source directly with the lua runtime,
I'm guessing that newlib works with MinGW.
I hope this helps.