Вопрос по linux, pthreads, gcc, glibc – Почему библиотеки glibc и pthread определяют одни и те же API?

11

Почему библиотеки glibc и pthread определяют одни и те же API? Вот снимок

[email protected]:/lib$ objdump -T /lib/i386-linux-gnu/libc.so.6 |grep pthread_cond_signal
000f8360 g    DF .text  00000039  GLIBC_2.3.2 pthread_cond_signal
0012b940 g    DF .text  00000039 (GLIBC_2.0)  pthread_cond_signal

[email protected]:/lib$ objdump -T /lib/i386-linux-gnu/libpthread.so.0 |grep pthread_cond_signal
0000b350 g    DF .text  0000007c (GLIBC_2.0)  pthread_cond_signal
0000af90 g    DF .text  000000fc  GLIBC_2.3.2 pthread_cond_signal

Ваш Ответ

1   ответ
12

libpthread.so также является частью glibc, и они оба содержат(identical) определения некоторых символов.

Если вы ищетеpthread_create вместо этого вы увидите, что он присутствует только вlibpthread.so - это означает, что программы должны ссылаться наlibpthread.so на самом деле создавать темы, but can use mutexes and condition variables in single-threaded programs that only link to libc.so. That's useful for interprocess mutexes and interprocess condition variables that live in shared memory and are used to synchronise with separate processes, (исправления благодаря комментарию Zan Lynx ниже).

Нет проблем связать обаlibpthread.so а такжеlibc.so хотя они оба определяют символ. Линкеры ELF позволяют нескольким совместно используемым библиотекам содержать определения одного и того же символа, и компоновщик выберет первый, который видит, и использует его для всех ссылок на этот символ, это называетсярасположение символов, Еще одна особенность, которая позволяет определять несколько символов, если одна библиотека содержитслабые символы который будет переопределен неслабыми символами с тем же именем. В этом случае определения вthe two libraries are identical, so it doesn't matter which is used libpthread.so переопределить те вlibc.so, Если вы используетеLD_DEBUG and change the order of arguments to the linker вы должны увидеть, в какой библиотеке находится символ.

Помимо двух библиотек, определяющих один и тот же символ, каждая библиотека имеет два определения символа с разнымиверсии символов, GLIBC_2.0 а такжеGLIBC_2.3.2, Это управление версиями символов позволяет сосуществовать нескольким определениям в одной и той же библиотеке, чтобы новые улучшенные версии функции можно было добавить в библиотеку, не нарушая код, связанный со старой реализацией. Это позволяет одной и той же общей библиотеке работать для приложений, использующих LinuxThreads, и приложений, использующих NPTL. Символ по умолчанию, с которым будет связана ссылка при ссылке на библиотеку,[email protected]_2.3.2 что соответствуетNPTL реализация этой функции (NPTL был впервые включен в glibc 2.3.2). Более старый символ,[email protected]_2.0, является более старой реализацией LinuxThreads, которая использовалась по умолчанию до предоставления NPTL. Приложения, связанные с более ранними (до 2.3.2) версиями glibc, будут связаны с[email protected]_2.0 и будет использовать этот символ.

Я не верю, что этот ответ является полностью правильным. Определения в glibc являются только заполнителями и содержат только пустые определения бездействия для операций pthread. Определения в libpthread.so переопределяют их. Это для использования библиотеками, которые хотят быть быстрыми в однопоточных, но поточно-ориентированными в многопоточных программах.
Вы правы, pthread_create не определен в libc.so.6. Но почему мы не получаем множественную ошибку определения для pthread_cond_signal при компоновке? Lunar Mushrooms
ответ обновлен для описанияsymbol interposition
@ ZanLynx, ах, я думаю, ты прав - мой плохой, - подумал яpthread_mutex_lock и аналогичные функции можно использовать без ссылки на libpthread, но, похоже, они не работают.

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