Home/ Questions/Q 8107717
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T00:52:10+00:00

Context: I am currently debugging an issue where the binaries generated in one machine

  • 0

Context: I am currently debugging an issue where the binaries generated in one machine (liked with lpthread) causes pthread related bugs when tried in another machine.

libtest.so is a shared library which seems to contain multiple versions of GLIBC_ . Is that expected ?. How it happens ? It was linked using “-shared -lpthread -fPIC -soname=xxxx” option.

$objdump -T libtest.so | grep GLIBC_

... 
00000000      DF *UND*  0000008d  GLIBC_2.1   popen
...
00000000      DF *UND*  0000002c  GLIBC_2.0   syslog
00000000      DF *UND*  00000020  GLIBC_2.0   pthread_exit
00000000      DF *UND*  0000009f  GLIBC_2.0   __xstat
00000000      DF *UND*  000000bb  GLIBC_2.3.2 pthread_cond_signal
00000000      DF *UND*  000000c9  GLIBC_2.0   vsprintf
...
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Each symbol has its own history.

    When a symbol hasn’t be modified (signature, behavor) it keeps the default version eg. GLIBC_2.0.
    Symbols modified are attributed the current version of the library at that time, for example popen() behavor was modified in GLIBC_2.1, pthread_cond_signal() was modified in GLIBC_2.3.2.

    Your program get linked with the latest version of each symbol. The version is recorded, and if you run your program against a newer GLIBC, your program will not use newer symbol version, but the one available at link time: this ensure to have the expected behavor at runtime: no surprise.

    • 0