What are the basic conditions to use other people's library in C/C++ coding?
Here I do not mean the compiling step, but at the step of writing source code (from scratch in a way!).
When using Standard C/C++ Library normally the header (.h/hpp) and corresponding implementation (.c/.cpp) files are included in the source code, then the multiple files are compiled.
I could not find a good tutorial/textbook on how to use other people's libraries except this one so far.
For example, gzlib is quite commonly used to handle compressed files, but I am blank how to use it in my own code. Also when people says libXYZ is needed for his code I become lost too. I think I understand "a 'library' is a collection of compiled functions and class declarations". So, my question is:
What is the general condition (suggestions) to use an non-standard library from a third party?
At this moment, I restrict my question to GCC/G++ in GNU-Linux or Unix-based CLI, not any GUI tools or other GUI-based IDE etc.
How to do this with a pretend zlib path -- you need to change it to whatever code you are trying to run in your C/C++ code. C examples:
you have to get the header files into your code
Steps:
A. gcc -I /path/to/zlib # when compiling. This adds a directory to the include search path
B. In your C code you have to include the "foreign" header file just like you would do for standard C header files:
#include <zlib.h>
You have to use -L path/to/zlib/libraries also on the gcc command line. To compile:
Finally you need to have added (or created) an environment variable LD_LIBRARY_PATH which knows where the special shared libraries live on a particular system.
This has to be there (along with the zlib shared libraries in a directory) on every system
you want to run you code one. This is the biggest source of error for this kind of development.
You can find it because the ldd command does not know where zlib libraries are - meaning at runtime the link and run step fails. Which creates all kinds of user complaints and problems. This variable has to be created everywhere for every user who will execute the code. The LD_LIBRARY_PATH definition systemwide .profile file is a possible choice, it may have security issues.
It's simpler than you think. The compiler only needs to know that these functions exist to use them.
Which is why a proper C header file is full of declarations like this:
int functionname(int x, long y, void *z);
...along with the data types they need, of course.
C++ ones will look a little more like:
class myclassname {
public:
// Most functions won't be defined right in the declaration
myclassname();
// Smaller functions may be defined here but MUST be inline
inline int myfunction(void) { function_contents(); }
};
#include <header.h> for the compiler, and -lsomelibraryname for the linker, are really all that's required in the vast majority of cases. The compiler generates the giant pile of names the linker needs to look for, and the linker searches through all default plus requested libraries to turn these name-stubs into addresses a program can use.
Thanks!
Your replies calrified lots of my confusion to use third party library.
I think I understand the -IXYZ is for the compiling step. To confirm:
Scenario 1): Using all the source code at compiling time. Skip this case. Scenario 2): Using the .so/.a file. This is what my original post referred.
#include <header.h> for the compiler, and -lsomelibraryname for the linker, are really all that's required in the vast majority of cases.
Do you mean only the header files (.h) is needed and be included in my code? In other words, is the header (.h) file along with the .so file enough for the implementation of the functions in my code?
Thanks a lot!
Yes, -I is for compilation step. It controls where #include <something.h> statements look. By default gcc/g++ look in /usr/include/something.h. If you have a header file installed into /usr/local/include you must use, you can do -I /usr/local/include
-I has no effect on #include "local.h" statements, which look in the source file's directory.
That's always true, really. Mark it down as a rule:
The compiler needs only the header files.
And the reason that's true cuts to the heart of what compilation and linking are.
Compilation: This turns your code and only your code into assembly language. Any functions (even your own), any global variables, any libraries you use, are all left as generic stubs to fill in later.
Linking: This loads all those little assembly programs at the same time, builds a table of their names, and converts all those generic stubs into locations in that table. With everything hardwired into actual memory addresses, it can create an executable that will run.
"All those little assembly programs" include not just your code, but also the generic code necessary to initialize any C program, default libraries like libc, and anything you specify with -l.
.
P.S. .a files are archive files - they literally contain the big pile of .o files needed to make a .so file. Linking to zlib.a is like dumping all of zlib's .c files in your source code. If you link to the .a file you don't need the .so. This will make your executable a lot bigger though.
You seem to not understand how executable code is produced from source code. Here is the short version and it is the same for every compiled language:
When a compiler translates source code it produces so-called object code, also called a "relocatible file". Basically this is executable code but without the provisions to use external functions. What are external functions. For instance, when you use the printf() -function in your code it has to come from somewhere. This somewhere is a (standard-)library. More on that later.
Once you have created object files from all of your source code files you want to create the executable itself. This is done by a linker (the precise name is "linkage editor"), which searches the libraries for i.e. the object code for the printf() -function and adds it to the executable so that it can run independently. This is called "static linking". You need to tell the linker which path(es) to search for eligible libraries, this is where i.e. the "-L" switch comes into play.
It is also possible to create the executable so that the code for the printf() -function is not included into the executable. Since many programs use that function they would all have to incorporate it. It would be easier to just put a reference into the executable and this would load the code at runtime from the library. The advantage is that instead of every executable containing a copy of the function you have it only once on your disk. The drawback is that the executable won't run on its own without the library being present. This is called "dynamic linking" and the libaries that allow for this are called "shared libraries" in UNIX and derived systems, "dynamic link libraries" (DLLs) in Windows. You need to tell the executable at runtime where these libraries are to be found. This is what the environment variables LIBPATH, LD_LIBRARY_PATH, etc. are for.
Finally you can create libraries on your own from your object files: this makes sense if you want to use a function in several programs. You use the command ar to manage libraries: you can add, extract or otherwise manipulate object files to/from libraries with it. In Windows (there is no pendant to ar in Windows) a linker is used for this.
At last: how to use libraries. In most languages a "function" (or "procedure") is a black box: you give it some data in a certain format and it dows something with it, then gives back a return value (and has maybe changed the data, this is called a "side effect" and should usually be avoided). How this is done should not be your concern. (This in fact is one of the tenets of structured programming.) In C there are header files telling you (and the compiler) which "interface" every function has. That is: which data it expects and what it gives back. So, to answer your question: you "need" the header filles and the library itself. Of course you need to know what the functions do, so some text documentation is also necessary.
Thanks Bakunin! That helps a lot. "You seem to not understand how executable code is produced from source code." Have some ideas about it, but not much practical experience.Never tried dissection of the executable code from source code. However, this is not what I want to learn.
That is: which data it expects and what it gives back. That fits exactly what I'm struggling with, as I know the raw data I have at hand and what I expect to get with the raw data.Believe this is all the programs do.
you "need" the header filles and the library itself. Of course you need to know what the functions do, so some text documentation is also necessary. This gives me more information on my question. I need more practice to get my feet wet, and soaked!
"What does a compiler and linker do?", and "How do executables work?" are pretty much the same question. An intimate knowledge of assembly language isn't required, though. Do you remember those old choose-your-own-adventure books? "If you say yes, go to page 37, if you say no, go to page 17", etc?
Imagine trying to write one of those. You would not write "go to page 37" in your draft - you have no idea what page 37 will be, that's your publisher's job. So you write "go to 'grisly death page'".
The publisher sets out all your pages in arbitrary order. They must make sure the beginning goes first, but otherwise the order really doesn't matter since the reader is supposed to jump around anyway. They number each page. And lastly, they change every reference to 'grisly death page' into 'page 37'.
That's exactly what a linker does, except it numbers by bytes, not pages.
If you want to add compilation to this analogy, just imagine that your publisher is Russian, and makes you send all your writing to a translator first.