Sample Header Ad - 728x90

Understanding LD_ASSUME_KERNEL usage

0 votes
1 answer
795 views
I am trying to make sense of the env variable LD_ASSUME_KERNEL on my system (Debian/bullseye+bpo). Accoring to :
$ man pthreads
I should be able to run something like this, however on my system here is what I get:
% LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls
/bin/bash: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
This is somewhat too low level for me to understand what is going on. I fail to understand if LD_ASSUME_KERNEL implementation is somewhat broken on my system, or if I fail to read the documentation properly. Some other failed attempts:
% LD_TRACE_LOADED_OBJECTS=1 LD_ASSUME_KERNEL=2.2.5 ldd
        linux-vdso.so.1 (0x00007ffe3f7e0000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f5399001000)
        libdl.so.2 => not found
        libc.so.6 => not found
        libc.so.6 => not found
and
% LD_TRACE_LOADED_OBJECTS=1 LD_ASSUME_KERNEL=2.4.19 ldd
        linux-vdso.so.1 (0x00007ffeaacb9000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f861cb18000)
        libdl.so.2 => not found
        libc.so.6 => not found
        libc.so.6 => not found
While:
% LD_TRACE_LOADED_OBJECTS=1 ldd
        linux-vdso.so.1 (0x00007ffc929a9000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007fa319a29000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa319a23000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa31985e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa319aaa000)
References: $ man pthreads [...] Selecting the threading implementation: LD_ASSUME_KERNEL On systems with a glibc that supports both LinuxThreads and NPTL (i.e., glibc 2.3.x), the LD_ASSUME_KERNEL environment variable can be used to override the dynamic linker's default choice of threading implementation. This variable tells the dynamic linker to assume that it is running on top of a particular kernel version. By specifying a kernel version that does not provide the support required by NPTL, we can force the use of LinuxThreads. (The most likely reason for doing this is to run a (broken) application that depends on some nonconformant behavior in LinuxThreads.) For example: bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \ awk '{print $3}' ) | egrep -i 'threads|nptl' linuxthreads-0.10 by Xavier Leroy Same goes for: $ man ld.so [...] LD_ASSUME_KERNEL (since glibc 2.2.3) Each shared object can inform the dynamic linker of the minimum kernel ABI version that it requires. (This requirement is encoded in an ELF note section that is viewable via readelf -n as a section labeled NT_GNU_ABI_TAG.) At run time, the dynamic linker determines the ABI version of the running kernel and will reject loading shared objects that specify minimum ABI versions that exceed that ABI version. LD_ASSUME_KERNEL can be used to cause the dynamic linker to assume that it is running on a system with a different kernel ABI version. For example, the following command line causes the dynamic linker to assume it is running on Linux 2.2.5 when loading the shared objects required by myprog: $ LD_ASSUME_KERNEL=2.2.5 ./myprog On systems that provide multiple versions of a shared object (in different directories in the search path) that have different minimum kernel ABI version requirements, LD_ASSUME_KERNEL can be used to select the version of the object that is used (dependent on the directory search order). Historically, the most common use of the LD_ASSUME_KERNEL feature was to manually select the older LinuxThreads POSIX threads implementation on systems that provided both LinuxThreads and NPTL (which latter was typically the default on such systems); see pthreads(7).
% apt-cache policy manpages
manpages:
  Installed: 5.10-1
  Candidate: 5.10-1
  Version table:
 *** 5.10-1 500
        500 http://deb.debian.org/debian  bullseye/main amd64 Packages
        500 http://deb.debian.org/debian  bullseye/main i386 Packages
        100 /var/lib/dpkg/status
--- As a side note, the output is always the same for:
/lib/x86_64-linux-gnu/libc.so.6
LD_ASSUME_KERNEL=2.2.5 /lib/x86_64-linux-gnu/libc.so.6
LD_ASSUME_KERNEL=2.4.19 /lib/x86_64-linux-gnu/libc.so.6
I get:
GNU C Library (Debian GLIBC 2.31-13+deb11u3) stable release version 2.31.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 10.2.1 20210110.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
.
Asked by malat (3429 rep)
Mar 30, 2022, 12:18 PM
Last activity: Mar 30, 2022, 12:43 PM