I am trying to use a callback function. This has worked fine when the caller and the called function were in the same file. I have lately decided to make the called function part of a library, so I have it declared in a header file, defined in its own file. I #include the new header in the calling source file, linking to the new library, and now I get an "Undefined reference" error to the callback function.
Is there something special I have to do to make this work? I notice when I use the same thing in pthread libraries for example, the callback function is defined as a pointer function.
Edit: I am linking to the library, and I can call other functions in the library just fine.
Possible problems:
the definition of the function (in the .c file) does not coincide with its declaration (in the .h file) and the code using this function essentially tells the linker to go and find what's in the header file and not what's actually in the library.
you have forgotten to compile the file implementing the function or put the resulting object file into the library and so the linker can't find the function in the library.
you have some source files open and unsaved and while they look fine and complete in the editor, their on-disk contents is different and something is amiss when you try to compile the code.
you are having some issues with make (bad makefile?) making it think that either the file implementing the function does not need to be compiled or it has already been compiled and needs no recompilation. Fixing the makefile and/or deleting the object and library files will fix the problem.
you have mixed C and C++ code and are having issues because of C++ name mangling. Using extern "C" { } may help here.
you have defined that function as static and so it's invisible in other modules (.c files) at link time. Removing static will help.
Turns out the problem was my header had the definition in there twice, one with static, one without.
You need to link to the actual code that implements the callback, including a header isn't enough.
So, it sounds as if your application needs to link to the library, which it of course already should be doing in order to call functions in the library.
Related
When I include some function from a header file in a C++ program, does the entire header file code get copied to the final executable or only the machine code for the specific function is generated. For example, if I call std::sort from the <algorithm> header in C++, is the machine code generated only for the sort() function or for the entire <algorithm> header file.
I think that a similar question exists somewhere on Stack Overflow, but I have tried my best to find it (I glanced over it once, but lost the link). If you can point me to that, it would be wonderful.
You're mixing two distinct issues here:
Header files, handled by the preprocessor
Selective linking of code by the C++ linker
Header files
These are simply copied verbatim by the preprocessor into the place that includes them. All the code of algorithm is copied into the .cpp file when you #include <algorithm>.
Selective linking
Most modern linkers won't link in functions that aren't getting called in your application. I.e. write a function foo and never call it - its code won't get into the executable. So if you #include <algorithm> and only use sort here's what happens:
The preprocessor shoves the whole algorithm file into your source file
You call only sort
The linked analyzes this and only adds the source of sort (and functions it calls, if any) to the executable. The other algorithms' code isn't getting added
That said, C++ templates complicate the matter a bit further. It's a complex issue to explain here, but in a nutshell - templates get expanded by the compiler for all the types that you're actually using. So if have a vector of int and a vector of string, the compiler will generate two copies of the whole code for the vector class in your code. Since you are using it (otherwise the compiler wouldn't generate it), the linker also places it into the executable.
In fact, the entire file is copied into .cpp file, and it depends on compiler/linker, if it picks up only 'needed' functions, or all of them.
In general, simplified summary:
debug configuration means compiling in all of non-template functions,
release configuration strips all unneeded functions.
Plus it depends on attributes -> function declared for export will be never stripped.
On the other side, template function variants are 'generated' when used, so only the ones you explicitly use are compiled in.
EDIT: header file code isn't generated, but in most cases hand-written.
If you #include a header file in your source code, it acts as if the text in that header was written in place of the #include preprocessor directive.
Generally headers contain declarations, i.e. information about what's inside a library. This way the compiler allows you to call things for which the code exists outside the current compilation unit (e.g. the .cpp file you are including the header from). When the program is linked into an executable that you can run, the linker decides what to include, usually based on what your program actually uses. Libraries may also be linked dynamically, meaning that the executable file does not actually include the library code but the library is linked at runtime.
It depends on the compiler. Most compilers today do flow analysis to prune out uncalled functions. http://en.wikipedia.org/wiki/Data-flow_analysis
The short version:
I'm trying to use a function in a shared library that hasn't been declared in a header file. Is it possible? If so, how?
The long version:
I'm trying to use GNU readline-7.0 as a shared library. Unfortunately it will echo input by default unless you turn it off with an api call. Sadly this api call wasn't declared in their header, because someone forgot. see details here Note: I can't update to a newer readline, so I'm stuck with this library. How do I use this undeclared function?
As noted in the linked bug, there is no external declaration in the header file even though the function exists in the implementation.
The link also shows the fix with the added declaration:
extern int rl_tty_set_echoing PARAMS((int));
So you can add this in your code right after #include <readline.h>
The sort answer is yes!!!
Just use the library -ldl with function dlopen(3), etc. This library allows you to load a shared object and search for identifiers that you know nothing about. Of course, the static typing nature of C forces to declare the interface of those functions with a prototype, so once you get a (void *) to the object you can cast it to something like int (*t)() and jump to it with a t(); call.
In the manual page you will get the details, dlopen allows you to search a shared object for symbols passed as strings. It returns pointers to the places those identifiers have been loaded in memory. You can even do this with your own program.
On the other hand, this is a feature of ELF shared loaded modules. If you are running a.out executables or otherwise, it is now waranteed that you'll have a dlopen(3) library for it, or that it will work that way.
Using VS2012 C/C++:
I created and linked a static lib called "libtools" to my project.
Calls to functions in the libtools lib worked as expected.
I created and linked a second static lib called "shunt" to my project.
But when I incorporate a call to a function in shunt, I am getting a c3861 "Identifier not found"
I added both libs to my project in the same way. I added a ref to each one in the Framework and References, and added the full path in the C/C++ Additional directories.
How can I fix this?
C++ uses something called name mangling when it creates symbol names. It's needed because the symbol names must contain the complete function signature.
When you use extern "C" the names will not be mangled, and can be used from other programming languages, like C.
You clearly make the shunt library in C++, which means that the shuntfunc function isn't actually named that way once it passed the compiler. As the actual application using the library is made in C (guessing based on the tag and information) it can't find the shuntfunc symbol, not without telling the C++ compiler to not mangle the symbol name.
That it works for the other library is probably because it's made in C as well.
Suppose I have a header file abc.h which defines a function foo(). How can I use the function foo() in the header file abc.h without using #include<abc.h> in my program?
I could come up with the following solutions
Copy the function from the header file into the program manually. But this would fail for most of the cases where the function definition has been pre-compiled into object files. Because in that case copy pasting function prototype won't do any good because unresolved references to the function couldn't be resolved.
Don't do anything in case of standard libraries as IDE can take care of that. But this is obviously undefined behaviour and would depend on IDE. Also for non-standard libraries it would surely fail.
So how can I use a function in a header file(not necessarily from the standard library) without including the header file?
This was an interview question so it is essentially a trick question. Not real use.
I believe the key word here is "defined" in the header file, not just declared. The header would have to be compiled to an object. To use it, you'd "declare" the function in your source and link with the object file.
That said, I hate interview questions like this since you're never really sure if that's what they are looking for because no one in their right mind would do this in practice.
But this would fail for most of the cases where the header has been pre-compiled into object files
This sentence makes no sense. A header can be used to compile an object file, but they never get compiled into object files; they are always used externally.
I have a static library of C files, compiled with g++ on Cygwin. I wish to unit test one function that is defined in the library. That function calls another function defined in that library and I wish to override the dependency to replace it with my own version of that function. I can't modify what's in the static library, so this solution [ Override a function call in C ] doesn't apply.
Usually, I can write a .cpp file and include the .c file containing the function I want to unit test, which essentially extends that file with the code I add. It's a dirty trick I'd never use for production code but it's handy for unit testing C files, because it gives my test code access to static things in that C file. Then, I can write in my fake version of the dependency, and my unit test function that calls the function I'm testing. I compile my.cpp to get my.o, then link it with the static library. In theory, since the linker has found a definition for the dependency already (the one I provide) it won't look in the library and there will be no conflict. Usually this works, but now I'm getting a "multiple definition" error where the linker first finds my fake and then finds the real one. I don't know what might cause this and don't know what to look for. I also can't boil this down to a simple example because my simple examples don't have this problem.
Ideas please?
One possibility (admittedly, and ugly one, but...) is to extract the individual object files from the static library. If the function you're calling and the function it's calling are in separate object files, you can link against the object file containing the function you need to call, but not against the one containing the function it calls.
This only gives you granularity on the level of complete object files though, so if the two functions involved are both in the same object file, it won't work. If you really need to get things to work, and don't mind making a really minor modification to the object file in question, you may be able to use a binary editor to mark the second function as a weak external, which means it'll be used in the absence of any other external with the same name, but if another is provided, that will be used instead.
Whether that latter qualifies as "modifying the library" or not depends a bit on your viewpoint. It's not modifying the code in the library, but is modifying a bit of the object file wrapper around that code. My guess is that you'd rather not do it, but it may still be the cleanest way out of an otherwise untenable situation.
It turns out the reason the linker found both defintions of the function is that the faked function's source file defined a variable which is extern'ed in its header file. That unresolved external in the header file caused the linker to link the faked function's object file (the whole thing) to the tested function's file inside the library. So, it's impossible to extract the definition of the tested function without the definition for the dependency.
What I ended up doing was similar to Override a function call in C where I used a different function name instead of the same one, and a preprocessor directive to swap the two. I put the preprocessor directive and the fake function in a separate file which can be included in a unit test, so the production code in the library does not have to be touched. Plus, if I want to fake that same function for another unit test somewhere else, I can re-use the new file.
Depending on your platform and performance requirements, you might be able to use pin to dynamically modify the application and replace one function with another at runtime.
There's no direct example in the manual, but you could easily modify one of the sample pin tools to do this.