Question

My requirement is to work on some interface .h files. Right now I have .h and .cpp/.cc files in my project.

I need to compile it into shared 64-bit linux compatible library (*.so), using NetBeans/ Eclipse on Linux Fedora.

Answer 1

If you are compiling a library from the 3 C++ source files called a.cc, b.cc, and c.cc respectively;

g++ -fpic -Wall -c a.cc

g++ -fpic -Wall -c b.cc

g++ -fpic -Wall -c c.cc

g++ -shared -Wl,-soname,libmylib.so.0 -o libmylib.so.0.0.0 a.o b.o c.o

Then you install the library using ldconfig, see

man 8 ldconfig

you can then compile the program that uses the libary as follows (but be sure to prefix

extern "C"

before the class declarations in the header files included in the source code using the library.)

g++ -o myprog main.cc -lmylib

I have tried these compile options with my own sample code, and have been successful.

Basically What is covered in Shared Libraries applies to C++, just replace gcc with g++.

The theory behind all of this is;

Libraries are loaded dynamically when the program is first loaded, as can be confirmed by doing a system call trace on a running program, e.g. strace -o trace.txt ls which will dump a list of the system calls that the program made during execution into a file called trace.txt. At the top of the file you will see that the program (in this case ls) had indeed mmapped all the library’s into memory.

Since libraries are loaded dynamically, it is unknown at link time where the library code will exist in the program’s virtual address space during run time. Therefore library code must be compiled using position independent code – Hence the -fpic option which tells the translation stage to generate assembly code that has been coded with position independent code in mind. If you tell gcc/g++ to stop after the translation stage, with the -S (upper case S) option, and then look at resulting ‘.s’ file, once with the -fpic option, and once without, you will see the difference (i.e. the dynamic code has @GOTPCREL and @PLT, at least on x86_64).

The linker, of course must be told to link all the ELF relocatatable object types into executable code suitable for use as a Linux shared library.