Разница между .o, .a, .lo и .so.
Резюме
- .o обычно представляет собой объектный файл не PICиспускается компилятором (перед этапом компоновщика) При связывании с exe-кодом код будет включен в исполняемый файл - мы связываемся во время компоновки.
- .a обычно представляет собой архивную библиотекусодержащий один или несколько файлов .o [не PIC].При связывании с exe-файлы определенные файлы * .o в архиве будут вставлены в исполняемый файл.
- .lo обычно представляет собой «объект библиотеки», который содержит код PIC,скомпилированные вручную с помощью gcc -fPIC или с использованием libtool .
- .so - это файлы "общего объекта".Они содержат объекты PIC.
Примечание:
- Если вам нужны статические исполняемые файлы, используйте файлы ".o" и ".a".
- Если вам нужны / нужны динамические исполняемые файлы, связанные с библиотеками во время выполнения, используйте файлы .lo и .so .
Введение
Хотя мне нравятся ответы выше, они не охватывают форму библиотеки .a / archive.Поэтому здесь я расскажу обо всех трех аспектах с бонусом добавления в формате библиотеки .so.Кроме того, в духе stackexchange, я буду использовать больше текста на случай, если ссылки будут повреждены (обратите внимание, что мне не нужны ссылочные ссылки для этого).
Filetype .o
При компиляции .o file - это объектный файл, содержащий объектный код, выданный компилятором для целевой платформы.Чтобы создать файл .o :
gcc -c filename.c <==== creates filename.o
Обратите внимание, что в этом примере не был создан независимый от позиции код (PIC).Мы считаем это объектом для возможного включения в статическую библиотеку или исполняемый файл.То есть, когда мы связываем исполняемый файл с файлом .o , код в файле .o вставляется в исполняемый файл - он связывается во время сборки, а не во время выполнения.Это означает, что исполняемый файл можно распространять без включения файла .o.Предупреждение: считается, что файл .o считается не PIC.Мы обычно называем объектные файлы PIC с расширением .lo .
Тип файла .a
Тип файла .a - "архив"библиотека.Он содержит один или несколько файлов .o и обычно используется для создания статических исполняемых файлов.
Мы используем команду ar для управления архивными библиотеками.Ниже в примере, который (1) создает архивную библиотеку из .o файлов, затем (2) перечисляет содержимое одного.
Создать библиотеку
$ ls *.o
a.o b.o c.o <=== the files going in the archive
$ ar q libmyStuff.a *.o <=== put *.o files in an archive (or new one)
ar: creating libmyStuff.a
$ ls *.a <=== just show the library created
libmyStuff.a
Отображение содержимого архивной библиотеки
$ ar t libmyStuff.a
a.o
b.o
c.o
Тип файла .lo
Использование .lo являетсясоглашение, которое часто используется для позиционно-независимых объектных файлов.В текущем каталоге команда libtool compile создает как файл .lo , так и файл .o , один с кодом PIC, а другой без кода PIC.Смотрите вывод ниже:
$ libtool compile gcc -c a.c
libtool: compile: gcc -c a.c -fPIC -DPIC -o .libs/a.o <== PIC code
libtool: compile: gcc -c a.c -o a.o >/dev/null 2>&1 <== Not-PIC code
$ ls a.lo a.o
a.lo a.o <=== a.lo contains the PIC code.
Также обратите внимание, что подкаталог .libs был создан с ao в нем.Этот файл является кодом PIC, несмотря на название. Libtool переместил этот файл в текущий каталог и изменил расширение на .lo .
. Вы всегда можете вручную создать .lo файлы, простоиспользование опции PIC для gcc при компиляции.Переместите получившиеся файлы .o в .lo расширение.
Тип файла .so
По соглашению .so подразумевает файл библиотеки "общего объекта",Мы помещаем объектные файлы PIC в разделяемые библиотеки.В контракте с файлами .o и .a , когда мы связываемся с файлами .so , код не включается в полученный скомпилированный файл.То есть мы используем привязку во время выполнения (как в случае .lo ).Существует более одной формы привязки во время выполнения, но мы не будем вдаваться в подробности.