2009-11-19 4 views
6

У меня есть библиотеки .so, которые я хотел бы объединить в одну общую библиотеку, чтобы она больше не зависела от исходных файлов .so.Как объединить общие библиотеки?

Файлы .so имеют зависимости друг от друга.

Как я могу это сделать? Я могу сделать это?

+0

Это похоже на связь: http://stackoverflow.com/questions/386579/pack-shared-libraries-into-the-elf – Inshallah

+1

@Inshallah: Windows - которую я должен поддерживать - не поддерживает ELF. –

ответ

8

Это предполагает, что вы есть исходный код для всех общих объектов:

Прилагается нет пространства имен конфликтов (которые не должны быть, если два сосуществуют как она есть), это не было бы слишком сложно создать их в один общий объект.

Если общие библиотеки сами зависят от кода из другой библиотеки, порядок будет иметь значение. Реальная работа - это просто получение зависимостей, разработанных в 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 
.... 

... и порядок правильный .. остальное довольно легко. Примечание. Я не показывал заголовки заголовков, каждый делает это немного по-другому. Они важны при создании mash-ups, хотя, как вы, вероятно, захотите избежать перекомпиляции всей библиотеки каждый раз, когда изменяется один заголовок.

NB: Если все три проекта используют autotools .. ваша задача просто экспоненциально проще (или сложнее) в зависимости.

Если у вас нет исходного кода

Если есть статическая версия каждой библиотеки, вы можете быть в состоянии извлечь объекты и использовать их. I.e .:

$ cp /usr/lib/foo.a ./foo.a 
$ ar x foo.a 
$ gcc -fPIC -shared *.o -o foo.so 

Конечно, это довольно немного более активное участие, чем показано.

Я никогда не пробовал это и не знаю, как обращаться с SO, у которых есть main(), когда дело доходит до ссылки в этом случае.

+0

Что он хочет - «libstuff.so: libfoo.so libbar.so», это не так? Я думаю, что проблема в том, что у него нет объектных файлов. –

+0

@Jamie Soriano: Лучшее, что нужно сделать (во всех учетных записях) - это скомпилировать объекты, которые делают отдельные общие объекты в один большой общий объект.Если вы просто сделаете один большой SO, который зависит от остальных, вы ничего не сделали, чтобы решить проблему зависимости, которая заставила вас сделать это в первую очередь. –

+0

@Jaime Soriano: Это то, что я действительно хотел. Но я даже не был уверен, что это возможно. –

Смежные вопросы