2

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.

genpfault
  • 51,148
  • 11
  • 85
  • 139
Basmah
  • 829
  • 3
  • 13
  • 25

2 Answers2

3

Since the GCC C++ ABI conventions did slightly change (in particular because of C++ standard libraries evolution, or name mangling convention) from one GCC version to the next (e.g. from g++-4.4 to g++-4.6) your shared library may be dependent upon the version of g++ used to build it

(In practice, the changes are often small inside g++, so you might be non affected)

If you want a symbol to be publicly accessible with dlsym you should preferably declare it extern "C" in your header files (otherwise you should mangle its name).

Regarding how to make a shared library, read documentation like Program Library Howto.

See also this question

And I suggest building your shared libraries with ordinary command-line tools (eg Makefile-s). Don't depend upon a complex IDE like NetBeans/ Eclipse to build them (they are invoking command-line utilities anyway).

Community
  • 1
  • 1
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Why not use Netbeans/Eclipse? They make things easy. Visual Studio uses a command line underneath as well, but I've never heard a recommendation that someone compile and link anything on windows from the command line. – Mooing Duck Apr 12 '12 at 22:06
  • Yes, but this thread is about shared code/libraries on unix/linux, where it is common practice to compile from the command line. Although in practice the specific compile commands are in a make file, and it just the make utility that is started from the command line, usually with a very trivial command such as `make' – vyudh Dec 06 '12 at 20:53
2

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.

vyudh
  • 91
  • 4