Building of shared libs which depend on each other (Linux)

Question

I have a very complex bunch of libs and executables taken over (Linux). The whole system was developed using static libraries in the past, then a couple years ago the libs are migrated to be shared libraries (-fPIC etc). Checking the dependencies I found out, that there are two shared libs: libA and libB:

libA calls some functions from libB
libB calls some functions from libA

I would like to build the libs having proper dependencies: libA depends on libB and libB depends on libA. But I can't give "-llibB" to the linker, because the lib is not yet existing at the build time of libA

If I build libA without the dependancy of libB (creating unresolved symbols), I have to keep in mind if I use libA I have to link libB also, because of undefined symbols in libA. That's annoing!

What I'm looking for is a possibility to build libA and telling to the linker to create dependancy to libB WITHOUT having libB at this time, is that possible?

How can I solve my problem without merging libA and libB together?

Regards, peters

Edit: I found out, that I can directly generate an empty lib (without writing a source code):

gcc -shared -Wl,-soname,libB.so.$(MAJOR) -o libB.so

then I can build libA adding: -lB to the build command. After that I removed the libB.so. Finally, after installation the libB refers to libA and libA refers to libB.

Of course the MAJOR number must match the MAJOR of the libB, this is so, because the major number is common for all libs.

I'm just asking myself if there is more suitable way to do it?

I believe it is a design mistake. `libA.so` and `libB.so` should be *merged* into a single `libAB.so` — Basile Starynkevitch, Jan 08 '15 at 11:56
No, they can live independent one of each other. Se my answer below. — Luis Colorado, Jan 08 '15 at 11:57
They perhaps can "be independent" can but they should not (since actually they both depend on the other one). — Basile Starynkevitch, Jan 08 '15 at 11:57
Yes, you are right, perhaps other reasons mandate them to be independent. I'm trying to imagine one scenario, but it's not trivial to demonstrate either. — Luis Colorado, Jan 08 '15 at 12:52

Luis Colorado · Answer 1 · 2015-01-08T12:03:53.040

Dependencies between shared libraries aren't resolved until load time, so you can link with the following line:

gcc -shared -Wl,-soname,libA.so.$(AMAJOR) -o libA.so
gcc -shared -Wl,-soname,libB.so.$(BMAJOR) -o libB.so

and then

gcc -o myProgram a.o b.o c.o libA.so libB.so

when you load(run) myProgram, the dynamic loader will follow the unsatisfied dependencies and look for the symbols in both shared objects. The -shared option is actually a non-complaint-about-unresolved-symbols flag that allows to construct an ELF file without all resolved symbols.

Another thing that can be happening here is that the libreries are not installed. You are trying to execute them without the proper paths and get unresolved symbols (from myProgram) when executing it. One solution is to run myProgram with:

LD_LIBRARY_PATH=. myProgram

or

export LD_LIBRARY_PATH=/path/to/libraries
myProgram

In linux, libraries are cached in a system database, so loading of shared libraries is fast. Database is indexed by soname, and to regenerate the database you have to use command ldconfig(8) as root

ldconfig

Other environments may not use ldconfig(8) at all (solaris being an example)

Building of shared libs which depend on each other (Linux)

1 Answers1