information about .so files

Question

I am new in C programing.I have no Idea about .so files. what is the need of it ? how can I create it ? how to bind my C code or Binary with it ? If I don't make any .so file and directly make executable binary of C code what are the PROS and CONS of it ? need a detail description of it.

Answer 1

.so files are shared objects. Usually shared libraries are made as .so.

By making a library a .so you achieve efficiency in memory usage. i.e. when multiple applications which use the library are running, the library is loaded into the memory only once as opposed to the case of static libraries.

Creation of dynamic library:

gcc -Wall -fPIC -c *.c
gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o

-fPIC: Compiler directive to output position independent code, a characteristic required by shared libraries.

-shared: Produce a shared object which can then be linked with other objects to form an executable.

You can find more information here.

Answer 2

.so stands for Shared Object. In Windows world, this is known as DLL.

You can use it pretty much the same way as DLLs are used - you can link your application dynamically to it.

If your library is called libblah.so, you can link to it using gcc like this:

gcc myprog.c -lblah -o myprog

Shared libraries are useful to factor out common functionality into separate files.

However, using shared libraries can lead to phenomenon known as DLL Hell. While this problem originated in Windows world, it can be applicable in Linux systems as well, unless you pay very close attention to exact version of shared library used and enforce strict versioning. For example, it is typical that if you compile your application using shared libraries (even system shared libraries, not the ones you have created), and then you try to run the same executable on another Linux box (with substantially different Linux version or distro), it may fail to run - because shared libraries used are not the same.

So, if you want your executable be portable to maximum number of Linux systems without recompilation, it may make sense to compile it statically. While this makes your executable bigger, it does reduce problems typically attributed to DLL Hell.

Answer 3

In addition of the other answers, notice that to build a shared object (or shared library) you'll better compile the relevant source files in position independent code mode like

   gcc -Wall -O -fPIC src.c -c -o src.pic.o

^{It is always useful to ask for all warnings with -Wall when compiling some source code.}

then you can link all these *.pic.o files into a .so using

   gcc -shared src1.pic.o src2.pic.o -o shared.so

and you can even link some shared library libfoo.so into that shared object using

   gcc -shared src1.pic.o src2.pic.o -lfoo -o shared.so

At last shared objects can be dynamically loaded into a process using dlopen; this is useful to get plugins. (and then define a convention for them and get important symbols in them using dlsym)

See also the program library howto and the Executable & Link Format & shared library wikipages

When make your shared library, better name it libfoo.so where foo is some arbitrary name. Then, at link time, use also the -L option to gcc (actually to the linker) to tell about the directory containing it, and link it using -lfoo option. For example, name your library libnewbie.so when making it, and pass -L. (if it is in the current directory) before -lnewbie when linking it, e.g. gcc -Wall myprog.c -L. -lnewbie -o myprog