Предполагается, что у вас есть исходный код для всех общих объектов:
При условии, что нет конфликтов пространства имен (которых не должно быть, если два сосуществуют как есть), было бы не слишком страшно встроить их в один общий объект.
Если разделяемые библиотеки сами зависят от кода из другой библиотеки, порядок будет иметь значение. Настоящая работа - это просто проработка зависимостей в make-файле. Я никогда не видел циклических зависимостей в ссылках SO, поэтому я сомневаюсь, что они у вас есть. То есть foo () зависит от bar (), который зависит от foo ().
Я делал это несколько раз, хотя сами библиотеки были тривиальными. Я взял части из ustr (обработчик строк), обработчик файла конфигурации, некоторых других пользовательских синтаксических анализаторов и других служебных функций и создал собственное смешение.
Реальная боль заключается в том, чтобы вносить улучшения в верхний уровень после каждого их объединения, однако я не уверен, является ли это проблемой для вас.
Так что если у вас есть:
libfoo.so: $(LIB_FOO_OBJECTS) $(LIB_BAR_OBJECTS) $(LIBFOOBAR_OBJECTS)
Где:
LIB_FOO_OBJECTS = \
$(libfoo)/foo.o \
$(libfoo)/strings.o
LIB_BAR_OBJECTS = \
$(libbar)/bar.o
....
... и порядок правильный .. остальное довольно просто. Обратите внимание, что я не показывал заголовки, все делают это по-своему. Они важны при создании гибридных приложений, так как вы, вероятно, захотите избегать перекомпиляции всей библиотеки каждый раз, когда изменяется один заголовок.
NB: Если все три проекта используют автоинструменты ... ваша задача в геометрической прогрессии стала значительно (или сложнее) в зависимости.
Если у вас нет исходного кода
Если есть статическая версия каждой библиотеки, вы можете извлечь объекты и использовать их. I.e.:
$ cp /usr/lib/foo.a ./foo.a
$ ar x foo.a
$ gcc -fPIC -shared *.o -o foo.so
Конечно, это немного сложнее, чем показано.
Я никогда не пробовал этого и не знаю, как обращаться с SO, которые имеют main (), когда дело доходит до линковки в этом случае.