This tutorial covers the basics of compiling a shared library on UNIX like systems using The GNU C Compiler. The server is blocking "g c c" so I am using the cc command instead. cc is simply a smbolic link for the other one.
Having shared libraries allows you to create programs that can break down functions into several different binary files. If there were no shared libraries all the programs would be a single, massive binary file. Updating programs would be pain because the entire project would have to be recompiled.
Also, shared libraries allow programmers to reuse existing binary files so that standard functions don't have to be recompiled again and again. Imagine having to wait for the stdio or stdlib to compile every single time you had a simple program.

Alright, now for the meat of the tutorial.
Create a simple function in a file. I'm going create an add function.

#include "add.h"
int add(int a, int b)
{
return a + b;
}

Now, make a header file called add.h and put this line in it:

int add(int,int);

You should create another file to use the add function. I'm going to call it testadd.c

The compilation process is slightly platform dependent. Linux and Mac have a different way of doing this, and I can't speak for Windows, which is why this is for UNIX like systems
Linux:cc -o libadd.so add.c -shared
Mac:cc -o libadd.dylib add.c -dynamiclib

To compile the driver code, type:cc -o add testadd.c -ladd -L.
The “-l” option tells the compiler to look for a file called libsomething.ext The something is specified by the argument immediately following the “-l”. The extension depends on your system. On linux, it looks for a file ending in “.so” but on Mac it looks for a file ending in “.dylib”. The “-L” option tells the compiler where to find the library. If no “-L” is specified, the compiler will search the usual locations. You can specify as many “-l” and “-L” options as you like. In this case I only needed one of each. The compiler will look for a file called “libadd.so” or “libadd.dylib” in the current directory.
You can see what libraries programs need by typingldd add
This does not work on Mac, because ldd does not exist.

Here you can see that the linker didn't find libadd.so. You have two choices. You can move the libadd.so to your "/usr/lib" directory, or you can set "LD_LIBRARY_PATH" to be the current directory.export LD_LIBRARY_PATH=.
Then recompile the binary with:cc -o add add.c -ladd
You don't need the "-L" option because the linker searches the directories in LD_LIBRARY_PATH.

OR if you put the library in your /usr/lib directory, the command would be:cc -o add add.c -ladd
You don't need the "-L" option because "/usr/lib" is automatically searched by the linker.
Then, the ouptut of ldd add
is

You should know that there are two types of shared libraries. There are dynamic and static libraries. A separate instance of a static library is loaded into memory every time a program needs it. A dynamic library is loaded into memory just once no matter how many programs need it. In linux, you must use the “-fPIC” option to compile dynamic libraries. The “PIC” stands for position independent code. That means that no matter where the library is in memory, every program that needs it can access it. In mac, the “-dynamiclib” option takes care of that for you.

I hope that helps people who are wondering how to compile shared libraries, and I'm sorry about not being able to work in how to do it under Windows, but I don't have access to a Windows computer, so I can't test everything to make sure it's working properly.

The header file is the library interface. When you compile code that uses the library it needs to know what the function is.

Kartik, on 13 April 2010 - 08:52 AM, said:

Hello sir,

I was wondering how to use class in shared library?could u explain on it.?

Are you asking how to use C++ classes in shared libraries? The c++ templates are done at compile time, meaning the function must be fully defined in a header file. This is so that the compiler knows which functions/operators to use for that specific type. There are probably other features of C++ that need to be done at compile time as well, and all of those would also have to be fully defined in a header file. Other that than, the process should be the same. You'll have to use the c++ command instead of cc, or something equivalent.

Nice tutorial. It was pretty straight forward, but I have never done anything with custom libraries before so it was a good place to start.

I do however have a question/ request for a follow-up tutorial. How would you notice when the shared library has changed an do a state refresh on the code currently running?

For instance, if I have a class in the shared library and am making changes to it while the system is running and get to the point where I want to test it out without losing program state. I believe it is possible to reload the library and basically "refresh" the objects as needed (perhaps with a little additional code in the main program). How would this be done?