почему gcc связывается динамически при использовании -l?

Question

Я сделал программу "Hello World", используя библиотеку pthread .Я скомпилирую его следующим простым способом:

$ gcc main.c -lpthread

Согласно документации gcc (раздел «Параметры связывания»):

-l библиотека [...] Компоновщик ищет в стандартном списке каталогов библиотеку, которая на самом деле является файлом с именем lib library .a.Затем компоновщик использует этот файл, как если бы он был указан точно по имени.[...]

Итак, я понимаю: gcc ищет libpthread.a .Учитывая конец .a, это должна быть статическая библиотека.

Однако это динамически связано:

$ ldd a.out
        linux-vdso.so.1 =>  (0x00007fffde3c3000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb345820000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb345456000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb345a3d000)

Чего мне не хватает?

Answer 1

Документация опции -l|--library в руководстве по GCC вводит в заблуждение, тем, что он не определяет поведение опции в системах, которые поддерживают разделяемые библиотеки, или предупредите нас, что это не так.

Опция -l передается компоновщику, обычно GNU ld (или альтернативе drop-in). Документация опции в ld руководстве является превосходным и дает понять, что разделяемая библиотека будет удовлетворять опции -l предпочтительнее статической библиотеки.

-l namespec

- библиотека = namespec

Добавить архив или объектный файл, указанный в namespec, в список файлов для ссылки. Эта опция может использоваться любое количество раз. Если namespec имеет форму: имя файла, ld будет искать путь к библиотеке для файла с именем filename, иначе он будет искать> путь к библиотеке для файла с именем libnamespec.a.

В системах, которые поддерживают общие библиотеки, ld может также искать файлы, отличные от libnamespec.a. В частности, в системах ELF и SunOS ld будет искать в каталоге библиотеку с именем libnamespec.so, прежде чем искать библиотеку с именем libnamespec.a . (По соглашению расширение .so обозначает общую библиотеку.) Обратите внимание, что это поведение не относится к: filename, который всегда указывает файл с именем filename.

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

...

(мой акцент)