This assumes you have the source code to all shared objects:
Provided there are no name space conflicts (which there should not be if the two co-exist as it is), it would not be too terribly hard to build them into one shared object.
If the shared libraries themselves depend on code from another library, order is going to matter. The real work is just getting the dependencies worked out in the makefile. I ve never seen circular dependencies in SO s successfully link, so I doubt that you have them to begin with. I.e. foo() depends on bar() which depends on foo().
I ve done this several times, though the libraries themselves were trivial. I took parts from ustr (string handler), a configuration file handler, some other custom parsers and other utility functions and created a custom mash up.
The real pain is bringing in upstream improvements to each once you have combined them, however I m not sure if that s an issue for you.
So if you have:
libfoo.so: $(LIB_FOO_OBJECTS) $(LIB_BAR_OBJECTS) $(LIBFOOBAR_OBJECTS)
Where:
LIB_FOO_OBJECTS =
$(libfoo)/foo.o
$(libfoo)/strings.o
LIB_BAR_OBJECTS =
$(libbar)/bar.o
....
... and the order is correct .. the rest is pretty easy. Note I didn t show header deps, everyone does that a little differently. They are important when making mash-ups though, as you d probably want to avoid recompiling the whole library every time one header changes.
NB: If all three projects are using autotools .. your task just got exponentially easier (or harder) depending.
If you DON T have the source code
If there is a static version of each library, you may be able to extract the objects and use them. I.e.:
$ cp /usr/lib/foo.a ./foo.a
$ ar x foo.a
$ gcc -fPIC -shared *.o -o foo.so
Of course its quite a bit more involved than illustrated.
I have never tried that and don t know how to handle SOs that have main() when it comes to linking in that case.
