problem statement. There are two shared libraries, libA.so and libB.so, both expose the same set of functions. Now, I have many little programs(say 100) that need to link to either libA.so or libB.so.
option 1. build two sets of these programs, one set links to libA.so, and another set links to libB.so.
option 2. create a thin wrapper shared library libMy.so and link as:
gcc -shared -o libMy.so libA.so
gcc -o main1 -L. -lMy main1.o
The idea is that the same built main1, main2 can be used by swapping in a different version of libMy.so (based on libA.so or libB.so) by setting LD_LIBRARY_PATH.
The problem is that at the link time, main1, main2, ... still reference libA.so, additional to libMy.so, as the command readelf -D main1 show.
The question is, what kind of linker options to make main1 only directly depends on libMy.so, and libMy.so directly depends on libA.so or libB.so, to achieve swappable providers.
The real example, libA.so and libB.so are two odbc drivers, one for oracle and another for postgresql. how to link executable files in the database-independent way?
You indeed need to make a thin wrapper library which provides the same interface as
libA.so/libB.so. This library would internally load the real implementation viadlopen, locate implementation of methods in it viadlsymand dispatch calls to them at runtime. Your application will need to link only againstlibwrapper.soand would be unaware of real implementations.Such wrapper library can be written manually or via Implib.so wrapper generator:
macallbackcallback will decide which library to load: