Отношение между файлом объектного файла и общего объекта

Question

Отношение между файлом объектного файла и общего объекта

Фанат @The

я вполне уверен, которым window.onload назовут снова, когда пользователь поразит кнопку "Назад" в IE, но не становится позвонившим снова в Firefox. (Если они недавно не изменили его).

В Firefox, onload назван, когда DOM закончил загружаться независимо от того, как Вы перешли к странице.

25

c++ linker shared-libraries object-files

задан Mike 30 November 2012 в 15:30

2 ответа

Другие вопросы по тегам:

c++ linker shared-libraries object-files

Похожие вопросы:

score 1 · Answer 1

.so аналогичен .dll в Windows. .O - это то же самое, что .obj в Visual Studio.

1

ответ дан 28 November 2019 в 18:05

score 71 · Answer 2

Допустим, у вас есть следующий исходный файл на C, назовите его name.c

#include <stdio.h>
#include <stdlib.h>

void print_name(const char * name)
{
    printf("My name is %s\n", name);
}

Когда вы его компилируете, с cc name.c вы генерируете name.o . .O содержит скомпилированный код и данные для всех функций и переменных, определенных в name.c, а также индекс, связанный их именами с фактическим кодом. Если вы посмотрите на этот указатель, скажем, с помощью инструмента nm (доступного в Linux и многих других Unix), вы заметите две записи:

00000000 T print_name
         U printf

Что это означает: есть два символа (имена функций или переменных, но не имен классов, структур или каких-либо типов), хранящихся в .o. Первый, помеченный T , фактически содержит его определение в name.o . Другой, помеченный U , является просто ссылкой . Код для print_name можно найти здесь, а код для printf - нет. Когда ваша фактическая программа будет запущена, ей нужно будет найти все символы, которые являются ссылками, и найти их определения в других объектных файлах, чтобы связать их вместе в полную программу или полную библиотеку. Следовательно, объектный файл - это определения, найденные в исходном файле, преобразованные в двоичную форму и доступные для размещения в полной программе.

Вы можете связывать вместе файлы .o один за другим, но вы этого не делаете: обычно они Их много, и они являются деталью реализации. Вы бы действительно предпочли, чтобы все они были собраны в связки связанных объектов с хорошо узнаваемыми именами. Эти пакеты называются библиотеками и бывают двух видов: статической и динамической.

Статическая библиотека (в Unix) почти всегда имеет суффикс .a (примеры включают libc.a , которая является основной библиотекой C, ] libm.a , математическая библиотека языка Си) и так далее. Продолжая пример, вы создадите свою статическую библиотеку с помощью ar rc libname.a name.o . Если вы запустите nm в libname.a , вы увидите следующее:

name.o:
00000000 T print_name
         U printf

Как видите, это в первую очередь большая таблица объектных файлов с поиском индекса all имена в нем. Как и объектные файлы, он содержит символы, определенные в каждом .o , и символы, на которые они ссылаются. Если бы вы связали в другой .o (например, с date.o до print_date ), вы бы увидели другую запись, подобную приведенной выше.

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

динамическая или разделяемая библиотека - это с суффиксом .so . Он, как и его статический аналог, представляет собой большую таблицу объектных файлов, относящуюся ко всему скомпилированному коду. Вы бы построили его с помощью cc -shared libname.so name.o . Однако взгляд на нм несколько отличается от статической библиотеки. В моей системе он содержит около двух дюжин символов, только два из которых - print_name и printf :

00001498 a _DYNAMIC
00001574 a _GLOBAL_OFFSET_TABLE_
         w _Jv_RegisterClasses
00001488 d __CTOR_END__
00001484 d __CTOR_LIST__
00001490 d __DTOR_END__
0000148c d __DTOR_LIST__
00000480 r __FRAME_END__
00001494 d __JCR_END__
00001494 d __JCR_LIST__
00001590 A __bss_start
         w __cxa_finalize@@GLIBC_2.1.3
00000420 t __do_global_ctors_aux
00000360 t __do_global_dtors_aux
00001588 d __dso_handle
         w __gmon_start__
000003f7 t __i686.get_pc_thunk.bx
00001590 A _edata
00001594 A _end
00000454 T _fini
000002f8 T _init
00001590 b completed.5843
000003c0 t frame_dummy
0000158c d p.5841
000003fc T print_name
         U printf@@GLIBC_2.0

Общая библиотека отличается от статической в одном очень важном отношении: она не встраивается в ваш окончательный исполняемый файл. Вместо этого исполняемый файл содержит ссылку на эту общую библиотеку, которая разрешается не во время компоновки, а во время выполнения. Это дает ряд преимуществ:

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

Есть некоторые недостатки:

Требуется время, чтобы связать программу вместе. В разделяемых библиотеках часть этого времени откладывается на каждый запуск исполняемого файла.
Процесс более сложный. Все дополнительные символы в совместно используемой библиотеке являются частью инфраструктуры, необходимой для связывания библиотеки во время выполнения.
Вы рискуете незначительной несовместимости между различными версиями библиотеки. В Windows это называется «адом DLL».