Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why glibc and pthread library both defined same APIs?

Why glibc and pthread library both defined same APIs ? Here is the snapshot

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
like image 943
Lunar Mushrooms Avatar asked Jun 22 '12 17:06

Lunar Mushrooms


People also ask

Is pthread part of glibc?

The recent 2.34 release of the GNU C library, glibc, removes libpthread as a separate library.

What is the difference between Lpthread and pthread?

-pthread tells the compiler to link in the pthread library as well as configure the compilation for threads. Using the -lpthread option only causes the pthread library to be linked - the pre-defined macros don't get defined. Bottom line: you should use the -pthread option.

What library is pthread in?

POSIX thread (pthread) libraries. The POSIX thread libraries are a standards based thread API for C/C++. It allows one to spawn a new concurrent process flow.

What is pthread in Linux?

POSIX Threads, commonly known as pthreads, is an execution model that exists independently from a language, as well as a parallel execution model. It allows a program to control multiple different flows of work that overlap in time.


1 Answers

libpthread.so is part of glibc too, and they both contain (identical) definitions of some symbols.

If you look for pthread_create instead you'll see that it's only present in libpthread.so -- this means programs must link to libpthread.so to actually create threads, 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. (corrections thanks to Zan Lynx's comment below).

It's not a problem to link to both libpthread.so and libc.so even though they both define the symbol. ELF linkers allows several shared libraries to contain definitions of the same symbol and the linker will choose the first one it sees and use it for all references to that symbol, this is called symbol interposition. Another feature that allows multiple symbols to be defined is if one library contains weak symbols which will be overidden by non-weak symbols with the same name. In this case the definitions in the two libraries are identical, so it doesn't matter which is used libpthread.so override those in libc.so. If you use LD_DEBUG and change the order of arguments to the linker you should be able to see which library the symbol actually gets found in.

As well as the two libraries defining the same symbol, each library has two definitions of the symbol, with different symbol versions, GLIBC_2.0 and GLIBC_2.3.2. This symbol versioning allows multiple definitions to co-exist in the same library so that new, improved versions of the function to be added to the library without breaking code that is linked against the old implementation. This allows the same shared library to work for applications using LinuxThreads and applications using NPTL. The default symbol that a reference will be bound to when linking to the library is pthread_cond_signal@GLIBC_2.3.2 which corresponds to the NPTL implementation of that function (NPTL was first included in glibc 2.3.2). The older symbol, pthread_cond_signal@GLIBC_2.0, is the older LinuxThreads implementation that was the default before NPTL was provided. Applications linked against older (pre-2.3.2) versions of glibc will be bound to pthread_cond_signal@GLIBC_2.0 and will use that symbol.

like image 197
Jonathan Wakely Avatar answered Oct 27 '22 12:10

Jonathan Wakely