Почему библиотеки glibc и pthread определяют одинаковые API?

Question

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

ubuntu@ubuntu:/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

ubuntu@ubuntu:/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

Answer 1

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

Если вы ищете pthread_create вместо этого вы увидите, что он присутствует только в libpthread.so - это означает, что программы должны ссылаться на libpthread.so на самом деле создавать потоки , но могут использовать взаимные исключения и условные переменные в однопоточных программах, которые ссылаются только на libc.so , Это полезно для межпроцессных мьютексов и межпроцессных переменных состояния, которые находятся в общей памяти и используются для синхронизации с отдельными процессами. (исправления благодаря комментарию Zan Lynx ниже).

Это не проблема, чтобы связать оба libpthread.so а также libc.so хотя они оба определяют символ. Линкеры ELF позволяют нескольким совместно используемым библиотекам содержать определения одного и того же символа, и компоновщик выберет первый, который он увидит, и будет использовать его для всех ссылок на этот символ, это называется взаимозаменением символов. Другая особенность, которая позволяет определять несколько символов, - это если одна библиотека содержит слабые символы, которые будут переопределены неслабыми символами с одинаковыми именами. В этом случае определения в двух библиотеках идентичны, поэтому не имеет значения, какой используется libpthread.so переопределить те в libc.so, Если вы используете LD_DEBUG и измените порядок аргументов на компоновщик, в котором вы сможете увидеть, в какой библиотеке находится символ.

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