目前编译glibc库时发现 glibc中已定义的libpthread库函数？同时查看当前server下glibc以及pthread库，发现也是都定义了同样的函数。那如果这样的话，gcc 编译时同时引入 glbc以及libpthread不会报错吗？但是实际上不会！！
参考这个讨论话题：why-glibc-and-pthread-library-both-defined-same-apis
libpthread.so is part of glibc too, and they both contain (identical)
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
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.
1、这个问题可以让人想起“ week symbol”--->hook malloc 怎样写内存泄露检测工具
2、对于查看glbc版本有：如下方法
strings /lib/x86_64-linux-gnu/libc.so.6 |grep GLIBC_
objdump -s /lib/x86_64-linux-gnu/libc.so.6 |grep GLIBC_
- nm：列出目标文件中的符号。
- objdump：显示目标文件中的详细信息。
- readelf：显示关于 ELF 目标文件的信息。
http代理服务器（3-4-7层代理）-网络事件库公共组件、内核kernel驱动 摄像头驱动 tcpip网络协议栈、netfilter、bridge 好像看过！！！！ 但行好事 莫问前程 --身高体重180的胖子