Code
Libraries on Linux - Posix system
Scope of this article is to see possibilies of libraries on linux - posix system : 
static libraries shared libraries dynamically loaded libraries (DLL).
For portable libraries, you should look two tools:
GNU Libtool http://www.gnu.org/software/libtool/libtool.html
Glib http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html
STATIC LIBRARIES
Static libraries are a collection of ordinary object files; conventionally, static libraries end with the ``.a’’ suffix. This collection is created using the ar (archiver) program. Static libraries are often useful for developers if they wish to permit programmers to link to their library, but don’t want to give the library source code.
To create a static library, or to add additional object files to an existing static library, use a command like this: ar rcs libmy_library.a file1.o file2.o Static library is invoking as part of the compilation and linking when creating the program executable.
g++ -Wall -o DemoStaticLibrary DemoStaticLibrary.cc -lmy_library.a
See attached sources.
SHARED LIBRARIES
Shared libraries are libraries that are loaded by programs when they start. All programs that start afterwards automatically use the new shared library. It’s actually much more flexible and sophisticated than this, because shared libraries permits you to: update libraries and still support programs that want to use older, non-backward-compatible versions of those libraries; override specific libraries or even specific functions in a library when executing a particular program. do all this while programs are running using existing libraries.
The list of directories to be searched shared libraries is stored in the file /etc/ld.so.conf. You can also custom with export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
Create a Shared Library:
First, create the object files that will go into the shared library using the g++ -fPIC flag. The -fPIC enable ``position independent code’’
g++ -fPIC -g -c -Wall Module1.cc g++ -fPIC -g -c -Wall Module2.cc
Second, use
g++ -shared -Wl to create shared library.
g++ -shared -Wl,-soname,libSharedModule.so.1 -o libSharedModule.so.1.0.1 Module1.o Module2.o
Install shared library:
ldconfig DirectorySharedLibraries.
or
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
Use shared library:
Link with -L -l options of g++
See attached sources Don’t forget to export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH before running ./DemoShared
DYNAMICALLY LOADED LIBRARIES - PLUGIN
Plugin provide flexibility and expandability to your program.
Plugin is implemented with Dynamically Loaded (DL) Libraries features. Programming interface use dlopen, dlerror, dlclose, dlsym ,dladdr , dlvsym functions.
dlopen The function dlopen() loads the dynamic library file
dlerror The function dlerror() returns a human readable string describing the most recent error
dlsym The function dlsym() takes a "handle" of a dynamic library returned by dlopen
dlclose The function dlclose() decrements the reference count on the dynamic library handle handle. If the reference count drops to zero and no other loaded libraries use symbols in it, then the dynamic library is unloaded.
dladdr The function dladdr() takes a function pointer and tries to resolve name and file where it is located.
dlvsym The function dlvsym() does the same as dlsym() but takes a version string as additional argument.
Conforming POSIX 1003.1-2003 only dlclose, dlerror, dlopen, dlsym are describes, so dladdr and dlvsym don’t used in this article.
DL is a C library. So DL library doesn’t know C++ "name mangling"[1]. C++ don’t have ability to retrieve plugin function. We have only 2 solutions:
use extern "C" block in the .cc file which defines plugin function. write a C++ version of libdl. A verry good exercise !
For our example we use extern “C” block. We define class Cplugin to encapsulate all dl functions. void * Cplugin::vSymbol(const char *symbol) return address to use defined symbol.
See attached sources Don’t forget to export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH before running ./PluginDemo
Conclusion
We have seen libraries on linux - posix system. For dynamically loaded libraries we seen problem with name mangling . This problem can be solve. But it’s an inheritance of C. Perhaps, we will seen in future a DL C++ library that manage directly dynamically loaded libraires under C++ .
Note [1] Name mangling is what the compiler has to do to store C++ symbols in a normal .o file. Normal C symbols don’t have any type information along with them; only names. Since C++ has polymorphism, you have to be able to have multiple symbols with different types. For instance, you might have void foo(int bar) and void foo(char* bar). What would you get when you asked for "foo"? Anyhow, if you do an "nm" on the test.o file you will see that the name is mangled.
When you add the extern "C" block, you are telling the compiler to make it so that a C program can link with your .o file and call your functions as if they were C functions. You have to list each thing you want to export in the block.
See Stroustrup, "The C++ Programming Language" third edition for good explanations of this and other C++ issues.
Reference
http://www.tldp.org/HOWTO/Program-Library-HOWTO/index.html
http://linuxgazette.net/issue84/bradley.html
http://www.tldp.org/HOWTO/C++-dlopen/index.html
man dlopen
http://www.tldp.org/HOWTO/GCC-HOWTO/
man ar
man gcc, man g++
man ldconfig
Author : hackervalley@free.fr http://hackervalley.free.fr
Copyright (c) 2003 hackervalley Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
CPPLibrairies.tar.bz2
BZip - 12.5 kb