How to use static library(.a file) instead of a group of object files(.o) to create a shared library

Shared libraries libfoo.so should contain PIC code and static libraries libfoo.a contain ordinary non PIC code. So you cannot create a shared library from a static one.

^{Shared libraries want Position Independent Code because their segment(s) is mmap(2)-ed at nearly arbitrary and variable addresses - without MAP_FIXED ... See also ASLR.}

You could in principle build a static library from PIC object files, but nobody does that in practice.

You might (if you really insist) make an ELF shared object made of non-PIC code, but the result would have very bad performance; the dynamic linker would have a lot of relocations, so most segments would be unshared and the dynamic linking would be very slow.

To compile foo.cc for a shared library into a PIC object file foo.pic.o :

g++ -Wall -c -O foo.cc  -fPIC -o foo.pic.o

To compile it for a static library int an ordinary non-PIC object file foo.o :

g++ -Wall -c -O foo.cc -o foo.o 

To make a shared library of foo.pic.o and bar.pic.o into libfoobar.so linking in some libdep.so shared library:

g++ -shared foo.pic.o bar.pic.o -ldep -o libfoobar.so

^{You often want to add more linking options when making a shared library like above, e.g. -Wl,-rpath,... or -Wl,-soname,....}

BTW, it is not possible to link an archive libfoobar.a (even if it is made of PIC files) into a libfoobar.so because no name is undefined and requires linking some object files from libfoobar.a (maybe you could try to undefine some symbol symb with -u symb but I don't recommend doing that).

To make a static library of foo.o and bar.o into libfoobar.a :

ar cv libfoobar.a foo.o bar.o

Notice that ranlib (creating an index of the archive) is no more necessary since GNU ar does its job.

Read also ld.so(8), ldd(1), ld(1), ar(1), objdump(1), readelf(1), dlopen(3) (often, you need to link the main program with -rdynamic if it loads dlopen-ed plugins at runtime, to enable the plugin to find some symbols in the main program).

NB: I would just build a shared library and not care about static linking at all. Notice that on some systems, PIC has a slight cost (slightly bigger and/or slower code). AFAIK, PIC overhead is less costly on x86-64 than on 32 bits Linux x86 code. On some architectures and ABIs PIC may have negligible overhead (or perhaps even be more efficient than non position independent code).

References: Drepper's paper: How to Write Shared Libraries & Levine's book: Linkers and Loaders & Program Library HowTo