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.
Related
I am building a range of C libraries to improve separation of code in a large codebase.
I would like to enforce strict separation using minimal public library interfaces.
The libraries consists of several modules (c + h files), some with internal references.
Currently, the library header files contain both prototypes related to the library interface functions and the public functions that are used internally in the library (in between the library modules).
I would like to somehow filter out the public interfaces which should not be accessible through the library interface (the internal public functions used in between the library modules).
I have come up with the following possible solutions, but I do not feel confident that any of these are optimal:
Maintain two header files for each module. One header file with internal interfaces used within the library and one header file containing the public library interfaces which may be used by the users of the library
Use include guards + a c pre-processor to filter out sections of the header files - with the resulting pre-processed header file only containing the library public functions
Write a custom script to filter the header files based on some syntax using c-style comments e.g. // Lib func \n void function1 ( int test ); For this solution I would be using some standard tool to parse the c header files (such as clang / LibClang).
I expect that this is a standard “problem” building libraries and wonder why it is not possible to find anything on the topic on SOF or google.
Any suggestions to how this can be effectively achieved is highly appreciated.
Thanks
Also, you can use "static const func()" in this case the domain of the function will be the only current .c file. In the fact need an only static function(), but realization static const func() will be better(correct me if I'm wrong in it).
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.
I know that, when we call any library function in our source code, The function definitions will be loaded into RAM (assuming dynamic linking) at run time.
But where exactly the definitions of library functions stored.
If they are not in .c format, how they are stored??
If you need to get any function definition, you need to check the source code [That was obvious].
To get the function definitions which are part of a library, [ex - glibc], you've to get the source code of the library and browse through that. Usually, the library source codes, [.c format, if you mean] will be compiled to produce a library, either
static [usually, noted by .a]
dynamic [Usually, noted by .so, shared object]
to be linked with some source code to produce the final binary.
So, yes, they are in .c format (least, human readable format, I better say) which you can browse through.
Note: An online browsable version of glibc.
P.S - Sorry, if my answer is biased towards linux implementations however, it is still valid for windows(xp) PC
The header file contain the definition. Inside the header file named alloc.h, we can find that header file in the folder include. you have to specify the environment you are using.it is saved with extention. .h
You can find an example Windows implementation of malloc here. On Windows, it's mostly a wrapper for WinAPI functions such as HeapAlloc. You can find other implementations of this and other functions in various opensource libraries.
Note that on Windows, a compiler doesn't have to provide implementations for the standard C functions, as they are all available in msvcrt.dll. You can't get the source code of these implementations, but you can still disassemble the DLL and look at the assembly.
What does include and link REALLY do? What are the differences? And why do I need to specify both of them?
When I write #include math.h and then write -lm to compile it, what does #include math.h and -lm do respectively?
In my understanding, when linking a library, you need its .h file and its .o file. Does this suggest #include math.h means take in the .h file while -lm take in the .o file?
The reason that you need both a header (the interface description) and the library (the implementation) is that C separates the two clearer than languages like C# or Java do. One can compile a C function (e.g. by invoking gcc -c <sourcefile>) which calls library code even when the called library is not present; the header, which contains the interface description, suffices. (This is not possible with C# or Java; the assemblies resp. class files/jars must be present.) During the link stage though the library must be there, even when it's dynamic, afaik.
With C#, Java, or script languages, by contrast, the implementation contains all information necessary to define the interface. The compiler (which is not as clearly separated from the linker) looks in the jar file or the C# assembly which contain called implementations and obtains information about function signatures and types from there.
Theoretically, that information could probably be present in a library written in C as well — it's basically the debug information. But the classic C compiler (as opposed to the linker) is oblivious to libraries or object files and cannot parse them. (One should remember that the "compiler" executable you usually use to compile a C program , e.g. gcc, is a "compiler driver" which interprets the command line arguments and calls the programs which actually do stuff, e.g. the preprocessor, actual compiler and actual linker, to create the desired output.)
So in theory, if you have a properly annotated library in a known location, you could probably write a compiler which compiles a C function against it without having function declarations and type definitions; the compiler would have to produce the proper declarations. The compiler would have to know which library to parse (which corresponds to setting a C# project "Reference" in VS or having a class path and name/class correspondence in Java).
It would probably be easiest to use a well-known debugging format like stabs or dwarf and extract the interface definitions from it with a little helper program which uses the API for the debug format, extracts the information and produces a C header which is prepended to every source file. That would be the job of the compiler driver, and the actual compiler would still be oblivious to that.
It's because headers files contain only declaration and .o files (or .obj, .dll or .lib) contain definitions of methods.
If you open an .h file, you will not see the code of methods, because that is in the libraries.
One reason is commercial, because you need to publish your code and have the source code in your company. Libraries are compiled, so you could publish it.
Header files only tell compiler, what classes and methods it can find in the library.
The header files are kind of a table-of-contents plus a kind of dictionary for the compiler. It tells the compiler what the library offers and gives special values readable names.
The library file itself contains the contents.
What you are asking are entirely two different things.
Don't worry , i will explain them to you.
You use # symbol to instruct the preprocessor to include the math.h header files which internally contain the function prototypes of fabs(),ceil() etc..
And you use -lm to instruct the linker, to include the pre-compiled function definitions of fabs(),ceil() etc. functions in the exe file .
Now, you may ask why we have to explicitly link library file of math functions unlike for other functions and the answer is ,it is due to some undefined historical reasons.
Since the files i include are simply copied into the file I include from, I can call any function that the header file implements.
static declarations won't help either as far as I understand.
How can I publish some header file and prevent the user's main C file from calling some functions in my header?
(Of course not really hide because he can just look at the source, but help him not to use functions that are not intended to be called directly)
Don't really hide them (BTW, making your library free software is usually worthwhile. You could use the LGPL license....). But put these internal functions in a separate header, e.g. foo-internals.h which is #included from the public foo.h and comment these functions as internal only!
Also, define some naming conventions, e.g. use some general foo_ prefix for public functions, and foointernal_ for "private" functions. Use once-only headers when needed.
You could use visibility pragmas and function attributes (set the visibility to hidden), at least on Linux or with GCC.
An API is not only defined by header files, but also by convention and by documentation. An undocumented function, or a function commented to be internal, should not be expected to be part of the API.
Take your inspiration by studying source code of real existing free software libraries (e.g. GTK, Posix libc such as MUSL libc or GNU libc, etc....).