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.
Related
For a predefined function where are the declaration and definition stored?
And is the declaration stored in libraries? If so, then why it is named library function?
This is an imprecise question. The best answers we can give are:
The declaration of standard library functions can best be thought of as being stored in their header files.
Depending on how you want to think about it, the definition of standard library files is either in the source files for those libraries (which may be invisible to you, a trade secret of your compiler vendor), or in the library files themselves (.a, .so, .lib, or .dll).
These days, knowledge of standard library functions is typically built in to the compiler, also. For example, if I write the old classic int main() { printf("Hello, world!\n"); }, but without any #include directives, my compiler says, "warning: implicitly declaring library function 'printf'" and "include the header <stdio.h>".
There are two sides of this story:
The code that calls a library/external function: The compiler generates a reference in your compiled module that encodes which function prototype you expect to exist elsewhere.
The pre-compiled library files against which your code must be linked: A library file contains both the coded prototypes of its functions as well as the actual compiled binary (i.e. the definition/implementation) for these function.
When your code uses an external function, the compiler generates a reference to this function that it assumes will be resolved later during the linking phase.
During the linking process lists of function references are build up. The linker expects to find the 'definition'/implementation of each of the used references.
The header file contains the declaration of built-in functions and the library contains the definition of the functions.
The name library is because, in my opinion, as the actual library which contains books, these libraries contain the classes, functions, variables etc.
I have a static library project (written in C language) and another sample project (written in C language) under Visual Studio 2015. I can use the functions located at the library in the sample project without any problem. My problem is that I have a macro in one of the header files in the static library project and I can't see (or use) this macro in the sample project. I receive this error: "unresolved external symbol ADD1 referenced in function main". How can I use this macro in the sample project?
Note: I use the library file in the sample project thanks to this pragma this pragma: #pragma comment(lib, "mylib.lib")
I do not want to include any of the header files of the static library project. They are not supposed to be seen by other projects.
I think there is some confusion.
To make use of any library, you must know about its functions, datatypes (e.g: enum, struct, typedef), macros, etc... This all comes together to form the library's 'API'.
Most libraries (not all) will have some internal headers. You are correct, these are not supposed to be seen by other projects, and will be used strictly internally.
All libraries will have some 'public' headers that define their API. A code base Without a public API is either useless, or actually an application that stands on its own.
Include your header with the #include directive, not with some pragma.
A header should be written so that it is the public interface to your library, even if the library code itself may not be open. Either the macro is public and can then be declared in the header, or it is not public in which case you should encapsulate it inside the library.
If the library code is pre-compiled and delivered as a binary, either declare it in a C file or in a H file that the caller does not have access to.
I am an intermediate "C" learner. I have written a simple function in c,compiled(Released) sucessfully.
I learned that adding extern "C" to function prohibits compiler from mangling it's name. so, i added extern "C" to my function but after dropping it to ida pro why i could not locate my function name ?
It contains few function but with some sub prefix other are compiler specific,i could not find the function i compiled.
If my way of disassembling function is wrong then please suggest it, I know it could be done in Visual editor while building but i want it other way.
It sounds like you're building an executable. Names get preserved for exported items only, when you are building a library. When you build an executable, the names (mangled or not) can be discarded (by the compiler and linker) because they are no longer needed - references to functions and variables within the executable are all done numerically.
If you build your code as a library (.dll/.so/.dylib depending on platform) and mark your functions as exported, you will see the names.
You can also see the names if you use IDA to look at the intermediate object files (.o/.obj). Those still contain names because the linker needs them to find functions by name during the linking process.
Finally, there is one way you can get function names to appear in IDA - build your executable with symbols enabled (i.e. produce a .pdb file if you're using MS tools). IDA will notice and offer to load the symbols, which will associate names with functions.
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.
Say I have 2 static libs
ex1.a
ex2.a
In both libs I will define 10 same functions
When Compiling a sample test code say "test.c" , I link with both static libs ex1.a and ex2.a
In "test.c" I will call only 3 functions, then I will get the
linker error "same symbols deifned in both ex1.a and ex2.a libraries" This is Ok.
My Question here is :
1. Why this error only display 3 functions as multiple defined.. Why not it list all 10 functions
In VC8 How can I list all multiple defined symbols without actualy calling that function in test code ...
Thanks,
Thats because, linker tries to resovle a symbol name, when it compiles and links a code which has the function call. Only when the code has some function calls, linker would try to resolve it in either the test code or the libraries linked along and thats when it would find multiple definitions. If no function called, then I guess no problem.
What you experience is the optimizing part of the linker: By default it won't include code that isn't referenced. The compiler will create multiple object files with most likely unresolved dependencies (calls that couldn't be satisfied by the code included). So the linker takes all object files passed and tries to find solutions for the unresolved dependencies. If it fails, it will check the available library files. If there are multiple options with the same exact name/signature it will start complaining cause it won't be able to decide which one to pick (for identical code this won't matter but imagine different implementations using different "behind the scenes" work on memory, such as debug and release stuff).
The only (and possibly easiest way) I could think of to detect all these multiple definitions would be creating another static library project including all source files used in both static libs. When creating a library the linker will include everything called or exported - you won't need specific code calling the stuff for the linker to see/include everything as long as it's exported.
However I still don't understand what you're actually trying to accomplish as a whole. Trying to find code shared between two libraries?