I have spent some time searching online but none of what I found seems to help. I'm running CentOS 6 64bit and would like to compile Apache with mod_ssl and need to link it to my own OpenSSL build (which is newer than the OS provided version). OpenSSL 1.1.0i is configured with: ./config --prefix=/opt/openssl-1.1.0 --openssldir=/opt/openssl-1.1.0 shared Apache 2.4 is configured with: ./configure --enable-layout=mycustomlayout \ --prefix=/opt/httpd-2.4.34 \ --exec-prefix=/opt/httpd-2.4.34 \ --with-mpm=prefork \ --enable-so \ --enable-ssl \ --with-ssl=/opt/openssl-1.1.0 \ --enable-cgi \ --enable-http2 \ --enable-proxy-http2 \ --with-included-apr It appears to compile just fine but mod_ssl isn't aware of where OpenSSL 1.1.0 is installed: [root@host .libs]# ldd ./mod_ssl.so | grep -iP 'ssl|crypto' libssl.so.1.1 => not found libcrypto.so.1.1 => not found And so only works when you explicitly tell it where to look: [root@host .libs]# export LD_LIBRARY_PATH=/opt/openssl-1.1.0/lib:$LD_LIBRARY_PATH [root@host .libs]# ldd ./mod_ssl.so | grep -iP 'ssl|crypto' libssl.so.1.1 => /opt/openssl-1.1.0/lib/libssl.so.1.1 (0x00007f069149a000) libcrypto.so.1.1 => /opt/openssl-1.1.0/lib/libcrypto.so.1.1 (0x00007f069100a000) Even building mod_ssl statically into httpd binary with --enable-mods-static=ssl doesn't help. I tried --enable-ssl, --enable-ssl --enable-ssl-staticlib-deps, and --enable-ssl --enable-ssl-staticlib-deps --enable-mods-static=ssl and still the same result: libssl.so.1.1 => not found libcrypto.so.1.1 => not found Also tried, without luck, setting these variables before ./configure: export PKG_CONFIG_PATH=/opt/openssl-1.1.0/lib/pkgconfig:$PKG_CONFIG_PATH \ LD_LIBRARY_PATH=/opt/openssl-1.1.0/lib:$LD_LIBRARY_PATH \ LDFLAGS="-L/opt/openssl-1.1.0/lib" I know I can just add to /etc/ld.so.conf.d to autoload the new OpenSSL library or adjust Apache's init script to add to LD_LIBRARY_PATH but I'd much prefer to have it working properly, have the program where to look for libssl.so / libcrypto.so, just like my PHP build: [root@host php]# export PKG_CONFIG_PATH=/opt/openssl-1.1.0/lib/pkgconfig:$PKG_CONFIG_PATH \ LD_LIBRARY_PATH=/opt/openssl-1.1.0/lib:$LD_LIBRARY_PATH \ LDFLAGS="-L/opt/openssl-1.1.0/lib" \ PHP_PREFIX=/opt/php-7.2.9 \ EXTENSION_DIR=$PHP_PREFIX/usr/lib64/php/modules [root@host php]# ./configure […] \ --with-imap=shared \ --with-imap-ssl \ --with-openssl=shared \ --with-openssl-dir=/opt/openssl-1.1.0/bin [root@host php]# make [root@host php]# unset PKG_CONFIG_PATH LD_LIBRARY_PATH LDFLAGS [root@host modules]# ldd ./openssl.so | grep -iP 'ssl|crypto' libssl.so.1.1 => /opt/openssl-1.1.0/lib/libssl.so.1.1 (0x00007fc2220a6000) libcrypto.so.1.1 => /opt/openssl-1.1.0/lib/libcrypto.so.1.1 (0x00007fc221c17000) What am I doing wrong? Could this be a bug?

I have an executable app, which depends on a library libbar.so and loads it via RPATH with $ORIGIN like this: $ readelf -d app Dynamic section at offset 0xe08 contains 26 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libbar.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib/] It would be nice to run it in the appropriate directory structure, made with symlinks to the executable and the libbar.so: $ ls -R .: app@ lib/ ./lib: libbar.so@ -- but **the linker follows symlinks to the original file of the executable, sets $ORIGIN to the directory of the executable file and resolves the dependency paths from there. Is it possible to make it not do this?** So that directory-path-wise, in the search for lib files, the symlinks are treated as real files of the filesystem ("end-points" of the search). Also, some reasoning to this problem: 1. It is convenient to have binaries set up to **search for dependencies in a couple relational directories**, for instance in the $ORIGIN/ of a binary itself and also in $ORIGIN/appname_dependencies/ (so that one can just copy the binary and its' dependencies into one directory and run it, but also has a fall-back for a more complicated set-up with multiple versions of the same binary in the system). 2. Due to the requirement of **several dependency search paths, RPATH is the search method to use**: a "slashed" name of dependency (NEEDED Shared library: [./libbar.so]) sets only 1 search path. Also, for simplicity the dependency resolution paths should be in the binary itself. 3. It's nice to be able to combine all binaries (the application and all its' dependencies) into the **full dependency graph with links**, instead of copying the files. And **symbolic links are more resilient** than hard links: they link across filesystems. In fact, I have this problem in one academic environment of a linux cluster, where a hard link to parent directory cannot be done: $ ln ../afile ln: creating hard link ./afile' => ../afile': Invalid cross-device link

This is not a duplicate because this is dealing with a peculiarity I noticed when I use /etc/ld.so.conf. To get the paths that the dynamic linker searches in for libraries, I run the command ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". When /etc/ld.so.conf has no paths listed in it. The output from the previous command is /lib /usr/lib I figured that it searches /lib first and then /usr/lib. When I add a new path, such as /usr/local/lib, to /etc/ld.so.conf and then remake /etc/ld.so.cache, the output from ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g" becomes /usr/local/lib /lib /usr/lib I find this strange because if I am correct that the order that the listed directories are searched in is from top to bottom, then additional directories are searched before /lib and /usr/lib. That the additional directories are searched before the trusted directories is not strange on its own, but when /lib is searched before /usr/lib, that is strange because /bin & /sbin are searched after /usr/bin & /usr/sbin in PATH. Even if the paths listed by ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g" were searched from bottom to top, it would still be a skewed ordering because additional directories would be searched after the trusted ones while /lib would be searched after /usr/lib. So, what is the order that ld.so searches paths for libraries in? Why is /lib searched before /usr/lib? If it's not, then why are additional directories searched after /lib?

After having deactivated ASLR, with: echo 0 | sudo tee /proc/sys/kernel/randomize_va_space I used ldd /path/to/binary to get the address of the shared library that my binary (written in C) was using, and I got the next output :

linux-vdso.so.1 (0x00007ffff7fc4000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007ffff7da5000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc6000)

The reason I did that is because I'm using [gdb-pwndbg](https://github.com/pwndbg/pwndbg) to understand how the binary is working in order to exploit it. And in order to exploit the binary i needed the libc address that the binary had in use. But after running the binary and breaking within execution, I wanted to check that things were working, so I printed out the contents of the /usr/lib/libc.so.6 address and got the following:

pwndbg> x 0x00007ffff7da5000
0x7ffff7da5000:

That shouldn't haven been occurring. I was supposed to get : 0x7ffff7da5000: "\177ELF\002\001\001\003" Or something similar. And that is Crazy! So I remembered that I had I similar file which too needed the use of the /usr/lib/libc.so.6 address, so went to that file and ran ldd and got 0x00007ffff7daa000 as the address. And like before i printed the contents of that address within an execution break of the binary which i wanted to exploit :

pwndbg> x 0x00007ffff7daa000
0x7ffff7daa000:	"\177ELF\002\001\001\003"

After that I was capable of use the address to exploit the binary. So i don't know what happens with that binary, even after having recompiled the binary a couple of times, it didn't have any effects. So I'm curious, or how can I fix this or prevent it?

When I'm compiling my elf, it is "best practice" to make it link against the oldest version of glibc I can, so it will work both on new and old versions of glibc. i.e. if I use realpath, which in readelf output of glibc we can see has both a GLIBC_2.0 version and a GLIBC_2.3 version, I want to use the old version so my ELF would work on glibc 2.0/1/2. But the GLIBC_2.3 version was probably developed and upgraded since it was published, and I guess GLIBC_2.0 version hasn't changed since glibc 2.3 has been published. So I guess I want my elf to use GLIBC_2.3 version when it is present, and when not, to fallback to the GLIBC_2.0 version. Is is possible? Or what don't I understand?

I want to find out the list of dynamic libraries a binary loads when run (With their full paths). I am using CentOS 6.0. How to do this?

I've been running the same 32-bit, 3rd-party, closed-source binary since 2018. This week on debian trixie/testing servers (possible due to a libc6 transition?) the program began to crash on startup. Unfortunately, I'm not able to get the original vendor to re-compile it for me. The only hint I have are these lines printed on stdout:

Start of process LocalCtrl...
SL - error in dlopen(libDSS_Operator.so):
LocalCtrl initialization failed...

I either need to get this working, or I need to commit to supporting Deb12 forever. What's the best way to troubleshoot/repair this? I can reproduce this in a more sterile environment with this sample program:

#include 
#include 

int main() {
    void* so = dlopen(
        "/opt//Cots/OPERATOR/libDSS_Operator.so", 
        RTLD_NOW
    );

    if (so == NULL) {
        printf("dlopen() failed: %s\n", dlerror());
        return 1;
    } 
    printf("Success\n");
    dlclose(so);
    return 0;
}

I took a look at ldd, strace, LD_DEBUG=libs, and readelf. On a Deb11 machine, where the process is working fine, I get:

$ dpkg --print-foreign-architectures
i386

$ sudo apt install gcc-multilib

$ gcc main.c -m32 -ldl

$ file a.out
a.out: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=eabedb331eafcdef4e2f839f71df7fc7330069d2, for GNU/Linux 3.2.0, not stripped

$ ./a.out
Success

$ ldd /opt//Cots/OPERATOR/libDSS_Operator.so
	linux-gate.so.1 (0xf7f25000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d1b000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7c17000)
	/lib/ld-linux.so.2 (0xf7f27000)

$ file /opt//Cots/OPERATOR/libDSS_Operator.so
/opt//Cots/OPERATOR/libDSS_Operator.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

$ strace ./a.out
execve("./a.out", ["./a.out"], 0x7ffeb7d8e5b0 /* 22 vars */) = 0
[ Process PID=13616 runs in 32 bit mode. ]
brk(NULL)                               = 0x5851f000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f78000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=102958, ...}) = 0
mmap2(NULL, 102958, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f5e000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libdl.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\21\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=17924, ...}) = 0
mmap2(NULL, 20596, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7f58000
mmap2(0xf7f59000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xf7f59000
mmap2(0xf7f5b000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0xf7f5b000
mmap2(0xf7f5c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0xf7f5c000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\260\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1987668, ...}) = 0
mmap2(NULL, 1996648, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7d70000
mprotect(0xf7d89000, 1871872, PROT_NONE) = 0
mmap2(0xf7d89000, 1392640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0xf7d89000
mmap2(0xf7edd000, 475136, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16d000) = 0xf7edd000
mmap2(0xf7f52000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e1000) = 0xf7f52000
mmap2(0xf7f55000, 10088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7f55000
close(3)                                = 0
set_thread_area({entry_number=-1, base_addr=0xf7f794c0, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=12)
mprotect(0xf7f52000, 8192, PROT_READ)   = 0
mprotect(0xf7f5c000, 4096, PROT_READ)   = 0
mprotect(0x56648000, 4096, PROT_READ)   = 0
mprotect(0xf7faa000, 4096, PROT_READ)   = 0
munmap(0xf7f5e000, 102958)              = 0
brk(NULL)                               = 0x5851f000
brk(0x58540000)                         = 0x58540000
brk(0x58541000)                         = 0x58541000
openat(AT_FDCWD, "/opt//Cots/OPERATOR/libDSS_Operator.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0X\6\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=4398, ...}) = 0
mmap2(NULL, 6844, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7f76000
mmap2(0xf7f77000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xf7f77000
mprotect(0xf7faa000, 2636, PROT_READ|PROT_WRITE) = 0
mprotect(0xf7faa000, 2636, PROT_READ)   = 0
mprotect(0xffa54000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0
close(3)                                = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=102958, ...}) = 0
mmap2(NULL, 102958, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7d56000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i386-linux-gnu/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\241\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1058344, ...}) = 0
mmap2(NULL, 1060976, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7c52000
mmap2(0xf7c5c000, 790528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0xf7c5c000
mmap2(0xf7d1d000, 225280, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xcb000) = 0xf7d1d000
mmap2(0xf7d54000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x101000) = 0xf7d54000
close(3)                                = 0
mprotect(0xf7d54000, 4096, PROT_READ)   = 0
mprotect(0xf7f76000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0xf7f76000, 4096, PROT_READ|PROT_EXEC) = 0
munmap(0xf7d56000, 102958)              = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x4), ...}) = 0
write(1, "Success\n", 8Success
)                = 8
munmap(0xf7f76000, 6844)                = 0
munmap(0xf7c52000, 1060976)             = 0
exit_group(0)                           = ?
+++ exited with 0 +++


$ LD_DEBUG=libs ./a.out
     13617:	find library=libdl.so.2 ; searching
     13617:	 search cache=/etc/ld.so.cache
     13617:	  trying file=/lib/i386-linux-gnu/libdl.so.2
     13617:	
     13617:	find library=libc.so.6 ; searching
     13617:	 search cache=/etc/ld.so.cache
     13617:	  trying file=/lib/i386-linux-gnu/libc.so.6
     13617:	
     13617:	
     13617:	calling init: /lib/i386-linux-gnu/libc.so.6
     13617:	
     13617:	
     13617:	calling init: /lib/i386-linux-gnu/libdl.so.2
     13617:	
     13617:	
     13617:	initialize program: ./a.out
     13617:	
     13617:	
     13617:	transferring control: ./a.out
     13617:	
     13617:	find library=libm.so.6 ; searching
     13617:	 search cache=/etc/ld.so.cache
     13617:	  trying file=/lib/i386-linux-gnu/libm.so.6
     13617:	
     13617:	
     13617:	calling init: /lib/i386-linux-gnu/libm.so.6
     13617:	
Success
     13617:	
     13617:	calling fini: /opt//Cots/OPERATOR/libDSS_Operator.so 
     13617:	
     13617:	
     13617:	calling fini: /lib/i386-linux-gnu/libm.so.6 
     13617:	
     13617:	
     13617:	calling fini: ./a.out 
     13617:	
     13617:	
     13617:	calling fini: /lib/i386-linux-gnu/libdl.so.2 
     13617:

On the Deb13 servers, where I am running into the problem, the outputs are much shorter:

$ dpkg --print-foreign-architectures
i386

$ sudo apt install gcc-multilib

$ gcc main.c -m32 -ldl

$ file a.out
a.out: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=ab5677099dd8d392861f817ee098264a76a16792, for GNU/Linux 3.2.0, not stripped

$ ./a.out 
dlopen() failed: /opt//Cots/OPERATOR/libDSS_Operator.so: cannot enable executable stack as shared object requires: Invalid argument

$ ldd /opt//Cots/OPERATOR/libDSS_Operator.so 
	linux-gate.so.1 (0xf7ed4000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7c70000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7b53000)
	/lib/ld-linux.so.2 (0xf7ed6000)

$ file /opt//Cots/OPERATOR/libDSS_Operator.so
.../libDSS_Operator.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

$ strace ./a.out
execve("./a.out", ["./a.out"], 0x7ffccb5bca20 /* 24 vars */) = 0
[ Process PID=8276 runs in 32 bit mode. ]
brk(NULL)                               = 0x57fac000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f4a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=122402, ...}) = 0
mmap2(NULL, 122402, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f2c000
close(3)                                = 0
openat(AT_FDCWD, "/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0O\2\0004\0\0\0"..., 512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=2315004, ...}) = 0
mmap2(NULL, 2349360, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7cee000
mmap2(0xf7d11000, 1609728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23000) = 0xf7d11000
mmap2(0xf7e9a000, 544768, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ac000) = 0xf7e9a000
mmap2(0xf7f1f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x231000) = 0xf7f1f000
mmap2(0xf7f22000, 39216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7f22000
close(3)                                = 0
set_thread_area({entry_number=-1, base_addr=0xf7f4b500, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=12)
set_tid_address(0xf7f4b568)             = 8276
set_robust_list(0xf7f4b56c, 12)         = 0
rseq(0xf7f4b480, 0x20, 0, 0x53053053)   = 0
mprotect(0xf7f1f000, 8192, PROT_READ)   = 0
mprotect(0x56575000, 4096, PROT_READ)   = 0
mprotect(0xf7f86000, 8192, PROT_READ)   = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
munmap(0xf7f2c000, 122402)              = 0
getrandom("\x81\x4a\xa4\xb7", 4, GRND_NONBLOCK) = 4
brk(NULL)                               = 0x57fac000
brk(0x57fcd000)                         = 0x57fcd000
brk(0x57fce000)                         = 0x57fce000
openat(AT_FDCWD, "/opt//Cots/OPERATOR/libDSS_Operator.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0X\6\0\0004\0\0\0"..., 512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=4398, ...}) = 0
mmap2(NULL, 6844, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf7f48000
mmap2(0xf7f49000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xf7f49000
close(3)                                = 0
munmap(0xf7f48000, 6844)                = 0
statx(1, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFCHR|0620, stx_size=0, ...}) = 0
write(1, "dlopen() failed: /opt/..."..., 153dlopen() failed: /opt//Cots/OPERATOR/libDSS_Operator.so: cannot enable executable stack as shared object requires: Invalid argument
) = 153
exit_group(1)                           = ?
+++ exited with 1 +++

$ LD_DEBUG=libs ./a.out
      8277:	find library=libc.so.6 ; searching
      8277:	 search cache=/etc/ld.so.cache
      8277:	  trying file=/lib/i386-linux-gnu/libc.so.6
      8277:	
      8277:	
      8277:	calling init: /lib/ld-linux.so.2
      8277:	
      8277:	
      8277:	calling init: /lib/i386-linux-gnu/libc.so.6
      8277:	
      8277:	
      8277:	initialize program: ./a.out
      8277:	
      8277:	
      8277:	transferring control: ./a.out
      8277:	
dlopen() failed: /opt//Cots/OPERATOR/libDSS_Operator.so: cannot enable executable stack as shared object requires: Invalid argument
      8277:	
      8277:	calling fini:  
      8277:	
      8277:	
      8277:	calling fini: /lib/i386-linux-gnu/libc.so.6 
      8277:	
      8277:	
      8277:	calling fini: /lib/ld-linux.so.2 
      8277:

The patchelf --print-needed, objdump -p, the readelf -a of the library on both machines is *nearly* identical and surprisingly succinct. I did a diff and the only difference between the deb11 and deb13 output was readelf's symbol table's LOCAL entries only have a populated "Name" column in deb13. This might not be terribly interesting. Here is the deb13 output:

$ patchelf --print-needed /opt//Cots/OPERATOR/libDSS_Operator.so
libc.so.6
libm.so.6

$ objdump -p /opt//Cots/OPERATOR/libDSS_Operator.so

/opt//Cots/OPERATOR/libDSS_Operator.so:     file format elf32-i386

Program Header:
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
         filesz 0x000009e0 memsz 0x000009e0 flags r-x
    LOAD off    0x000009e0 vaddr 0x000019e0 paddr 0x000019e0 align 2**12
         filesz 0x000000dc memsz 0x000000dc flags rw-
 DYNAMIC off    0x00000a2c vaddr 0x00001a2c paddr 0x00001a2c align 2**2
         filesz 0x00000090 memsz 0x00000090 flags rw-

Dynamic Section:
  NEEDED               libc.so.6
  NEEDED               libm.so.6
  HASH                 0x00000094
  STRTAB               0x0000034c
  SYMTAB               0x0000015c
  STRSZ                0x00000121
  SYMENT               0x00000010
  REL                  0x00000470
  RELSZ                0x000001e8
  RELENT               0x00000008
  TEXTREL              0x00000000
  RELCOUNT             0x0000003c




$ readelf -a /opt//Cots/OPERATOR/libDSS_Operator.so 
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x658
  Start of program headers:          52 (bytes into file)
  Start of section headers:          2940 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         3
  Size of section headers:           40 (bytes)
  Number of section headers:         17
  Section header string table index: 14

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .hash             HASH            00000094 000094 0000c8 04   A  2   0  4
  [ 2] .dynsym           DYNSYM          0000015c 00015c 0001f0 10   A  3  14  4
  [ 3] .dynstr           STRTAB          0000034c 00034c 000121 00   A  0   0  1
  [ 4] .rel.dyn          REL             00000470 000470 0001e8 08   A  2   0  4
  [ 5] .text             PROGBITS        00000658 000658 000244 00  AX  0   0  4
  [ 6] .rodata           PROGBITS        000008a0 0008a0 000140 00   A  0   0 16
  [ 7] .data             PROGBITS        000019e0 0009e0 000040 00  WA  0   0 32
  [ 8] .got              PROGBITS        00001a20 000a20 00000c 04  WA  0   0  4
  [ 9] .dynamic          DYNAMIC         00001a2c 000a2c 000090 08  WA  3   0  4
   .sbss             PROGBITS        00001abc 000abc 000000 00   W  0   0  1
   .bss              NOBITS          00001abc 000abc 000000 00  WA  0   0  4
   .comment          PROGBITS        00000000 000abc 000036 00      0   0  1
   .note             NOTE            00000000 000af2 000014 00      0   0  1
   .shstrtab         STRTAB          00000000 000b06 000076 00      0   0  1
   .symtab           SYMTAB          00000000 000e24 000240 10     16  19  4
   .strtab           STRTAB          00000000 001064 0000ca 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x009e0 0x009e0 R E 0x1000
  LOAD           0x0009e0 0x000019e0 0x000019e0 0x000dc 0x000dc RW  0x1000
  DYNAMIC        0x000a2c 0x00001a2c 0x00001a2c 0x00090 0x00090 RW  0x4

 Section to Segment mapping:
  Segment Sections...
   00     .hash .dynsym .dynstr .rel.dyn .text .rodata 
   01     .data .got .dynamic 
   02     .dynamic 

Dynamic section at offset 0xa2c contains 13 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000004 (HASH)                       0x94
 0x00000005 (STRTAB)                     0x34c
 0x00000006 (SYMTAB)                     0x15c
 0x0000000a (STRSZ)                      289 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000011 (REL)                        0x470
 0x00000012 (RELSZ)                      488 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x00000016 (TEXTREL)                    0x0
 0x6ffffffa (RELCOUNT)                   60
 0x00000000 (NULL)                       0x0

Relocation section '.rel.dyn' at offset 0x470 contains 61 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0000068f  00000008 R_386_RELATIVE   
0000069f  00000008 R_386_RELATIVE   
000006cb  00000008 R_386_RELATIVE   
000006db  00000008 R_386_RELATIVE   
000006f6  00000008 R_386_RELATIVE   
00000736  00000008 R_386_RELATIVE   
00000772  00000008 R_386_RELATIVE   
000007a7  00000008 R_386_RELATIVE   
000007b7  00000008 R_386_RELATIVE   
000007e3  00000008 R_386_RELATIVE   
000007f3  00000008 R_386_RELATIVE   
0000080e  00000008 R_386_RELATIVE   
0000084e  00000008 R_386_RELATIVE   
0000088a  00000008 R_386_RELATIVE   
000008a0  00000008 R_386_RELATIVE   
000008a4  00000008 R_386_RELATIVE   
000008a8  00000008 R_386_RELATIVE   
000008ac  00000008 R_386_RELATIVE   
000008b0  00000008 R_386_RELATIVE   
000008b4  00000008 R_386_RELATIVE   
000008c0  00000008 R_386_RELATIVE   
000008c4  00000008 R_386_RELATIVE   
000008c8  00000008 R_386_RELATIVE   
000008cc  00000008 R_386_RELATIVE   
000008d0  00000008 R_386_RELATIVE   
000008d4  00000008 R_386_RELATIVE   
000008e0  00000008 R_386_RELATIVE   
000008e4  00000008 R_386_RELATIVE   
000008e8  00000008 R_386_RELATIVE   
000008ec  00000008 R_386_RELATIVE   
000008f0  00000008 R_386_RELATIVE   
000008f4  00000008 R_386_RELATIVE   
00000900  00000008 R_386_RELATIVE   
00000904  00000008 R_386_RELATIVE   
00000908  00000008 R_386_RELATIVE   
0000090c  00000008 R_386_RELATIVE   
00000910  00000008 R_386_RELATIVE   
00000914  00000008 R_386_RELATIVE   
00000920  00000008 R_386_RELATIVE   
00000924  00000008 R_386_RELATIVE   
00000928  00000008 R_386_RELATIVE   
0000092c  00000008 R_386_RELATIVE   
00000930  00000008 R_386_RELATIVE   
00000934  00000008 R_386_RELATIVE   
00000940  00000008 R_386_RELATIVE   
00000944  00000008 R_386_RELATIVE   
00000948  00000008 R_386_RELATIVE   
0000094c  00000008 R_386_RELATIVE   
00000950  00000008 R_386_RELATIVE   
00000954  00000008 R_386_RELATIVE   
000019e0  00000008 R_386_RELATIVE   
000019e4  00000008 R_386_RELATIVE   
000019e8  00000008 R_386_RELATIVE   
000019ec  00000008 R_386_RELATIVE   
000019f0  00000008 R_386_RELATIVE   
000019f4  00000008 R_386_RELATIVE   
000019f8  00000008 R_386_RELATIVE   
000019fc  00000008 R_386_RELATIVE   
00001a00  00000008 R_386_RELATIVE   
00001a04  00000008 R_386_RELATIVE   
00000665  00000f01 R_386_32          000019e0   listOperators
No processor specific unwind information to decode

Symbol table '.dynsym' contains 31 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000094     0 SECTION LOCAL  DEFAULT    1 .hash
     2: 0000015c     0 SECTION LOCAL  DEFAULT    2 .dynsym
     3: 0000034c     0 SECTION LOCAL  DEFAULT    3 .dynstr
     4: 00000470     0 SECTION LOCAL  DEFAULT    4 .rel.dyn
     5: 00000658     0 SECTION LOCAL  DEFAULT    5 .text
     6: 000008a0     0 SECTION LOCAL  DEFAULT    6 .rodata
     7: 000019e0     0 SECTION LOCAL  DEFAULT    7 .data
     8: 00001a20     0 SECTION LOCAL  DEFAULT    8 .got
     9: 00001a2c     0 SECTION LOCAL  DEFAULT    9 .dynamic
    10: 00001abc     0 SECTION LOCAL  DEFAULT   10 .sbss
    11: 00001abc     0 SECTION LOCAL  DEFAULT   11 .bss
    12: 00000000     0 SECTION LOCAL  DEFAULT   12 .comment
    13: 00000000     0 SECTION LOCAL  DEFAULT   13 .note
    14: 000007fc    61 FUNC    GLOBAL DEFAULT    5 op_inv_rev
    15: 000019e0    40 OBJECT  GLOBAL DEFAULT    7 listOperators
    16: 00001a2c     0 OBJECT  GLOBAL DEFAULT  ABS _DYNAMIC
    17: 000007c0    59 FUNC    GLOBAL DEFAULT    5 op10_rev
    18: 00000658    19 FUNC    GLOBAL DEFAULT    5 getListOperator
    19: 0000083c    57 FUNC    GLOBAL DEFAULT    5 op_inv2_rev
    20: 000006e4    61 FUNC    GLOBAL DEFAULT    5 op_inv
    21: 00000784    59 FUNC    GLOBAL DEFAULT    5 op3_rev
    22: 00001abc     0 OBJECT  GLOBAL DEFAULT  ABS __bss_start
    23: 00000724    57 FUNC    GLOBAL DEFAULT    5 op_inv2
    24: 00000760    35 FUNC    GLOBAL DEFAULT    5 op_refresh
    25: 000006a8    59 FUNC    GLOBAL DEFAULT    5 op10
    26: 0000066c    59 FUNC    GLOBAL DEFAULT    5 op3
    27: 00000878    35 FUNC    GLOBAL DEFAULT    5 op_refresh_rev
    28: 00001abc     0 OBJECT  GLOBAL DEFAULT  ABS _edata
    29: 00001a20     0 OBJECT  GLOBAL DEFAULT  ABS _GLOBAL_OFFSET_TABLE_
    30: 00001abc     0 OBJECT  GLOBAL DEFAULT  ABS _end

Symbol table '.symtab' contains 36 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000094     0 SECTION LOCAL  DEFAULT    1 .hash
     2: 0000015c     0 SECTION LOCAL  DEFAULT    2 .dynsym
     3: 0000034c     0 SECTION LOCAL  DEFAULT    3 .dynstr
     4: 00000470     0 SECTION LOCAL  DEFAULT    4 .rel.dyn
     5: 00000658     0 SECTION LOCAL  DEFAULT    5 .text
     6: 000008a0     0 SECTION LOCAL  DEFAULT    6 .rodata
     7: 000019e0     0 SECTION LOCAL  DEFAULT    7 .data
     8: 00001a20     0 SECTION LOCAL  DEFAULT    8 .got
     9: 00001a2c     0 SECTION LOCAL  DEFAULT    9 .dynamic
    10: 00001abc     0 SECTION LOCAL  DEFAULT   10 .sbss
    11: 00001abc     0 SECTION LOCAL  DEFAULT   11 .bss
    12: 00000000     0 SECTION LOCAL  DEFAULT   12 .comment
    13: 00000000     0 SECTION LOCAL  DEFAULT   13 .note
    14: 00000000     0 SECTION LOCAL  DEFAULT   14 .shstrtab
    15: 00000000     0 SECTION LOCAL  DEFAULT   15 .symtab
    16: 00000000     0 SECTION LOCAL  DEFAULT   16 .strtab
    17: 00000000     0 FILE    LOCAL  DEFAULT  ABS operator.c
    18: 00000658     0 NOTYPE  LOCAL  DEFAULT    5 gcc2_compiled.
    19: 000007fc    61 FUNC    GLOBAL DEFAULT    5 op_inv_rev
    20: 000019e0    40 OBJECT  GLOBAL DEFAULT    7 listOperators
    21: 00001a2c     0 OBJECT  GLOBAL DEFAULT  ABS _DYNAMIC
    22: 000007c0    59 FUNC    GLOBAL DEFAULT    5 op10_rev
    23: 00000658    19 FUNC    GLOBAL DEFAULT    5 getListOperator
    24: 0000083c    57 FUNC    GLOBAL DEFAULT    5 op_inv2_rev
    25: 000006e4    61 FUNC    GLOBAL DEFAULT    5 op_inv
    26: 00000784    59 FUNC    GLOBAL DEFAULT    5 op3_rev
    27: 00001abc     0 OBJECT  GLOBAL DEFAULT  ABS __bss_start
    28: 00000724    57 FUNC    GLOBAL DEFAULT    5 op_inv2
    29: 00000760    35 FUNC    GLOBAL DEFAULT    5 op_refresh
    30: 000006a8    59 FUNC    GLOBAL DEFAULT    5 op10
    31: 0000066c    59 FUNC    GLOBAL DEFAULT    5 op3
    32: 00000878    35 FUNC    GLOBAL DEFAULT    5 op_refresh_rev
    33: 00001abc     0 OBJECT  GLOBAL DEFAULT  ABS _edata
    34: 00001a20     0 OBJECT  GLOBAL DEFAULT  ABS _GLOBAL_OFFSET_TABLE_
    35: 00001abc     0 OBJECT  GLOBAL DEFAULT  ABS _end

Histogram for bucket list length (total of 17 buckets):
 Length  Number     % of total  Coverage
      0  7          ( 41.2%)
      1  4          ( 23.5%)     23.5%
      2  5          ( 29.4%)     82.4%
      3  1          (  5.9%)    100.0%

No version information found in this file.

Displaying notes found in: .note
  Owner                Data size 	Description
  01.01                0x00000000	NT_VERSION (version)

I reduced some verbosity with patchelf --remove-rpath to remove unnecessary searching, but there was no change on either machine.

Has anyone used the gold linker before? To link a fairly large project, I had to use this as opposed to the GNU ld, which threw up a few errors and failed to link. How is the gold linker able to link large projects where ld fails? Is there some kind of memory trickery somewhere?

I was trying to understand Visibility values in ELF file , and I couldn't Understand the difference between STV_HIDDEN and STV_INTERNAL . After some reseach I found that this may be related to how symbols are exported in symbol table , am not sure whether that is correct or not but if some one explain the story behind the difference it will be helpful for me . Possible Duplicate : https://unix.stackexchange.com/questions/472660/what-are-difference-between-the-elf-symbol-visibility-levels But from the answer there I still couldn't get the difference , perhaps more explaination may help me . Thanks

I downloaded the source code for UW-IMAP/imap-2007f_upstream from the URL below.
https://github.com/uw-imap/imap/archive/refs/tags/imap-2007f_upstream.tar.gz I compiled it, but libc-client.so.2007 was not generated.
I compiled it by executing the following command:
make lnp PASSWDTYPE=pam SSLTYPE=unix EXTRACFLAGS=-fPIC The OS environment is AlmaLinux8.10. I want libc-client.so.2007 that links to the latest OpenSSL3.4.0, not the libc-client.so.2007 that links to OpenSSL1.1.1. That's why I'm compiling it from source code. Is there any way to get libc-client.so.2007 by compiling?

I'm trying to build GCC 12.4.0 on Oracle Linux 9.4 (sorry about that... not my choice of distribution), as a non-root user. So, I've downloaded and built my relevant prerequisites: gmp, mpfr, mpc, isl, installing them into their own separate directories. I now try:

-bash
./configure --disable-ada --disable-gnat --disable-fortran --disable-bootstrap \
    --disable-bootstrap --enable-languages=c,c++  \
    --prefix=$HOME/opt/versions/gcc/12.4.0 --with-gmp=$HOME/opt/gmp \
    --with-mpfr=$HOME/opt/mpfr --with-mpc=$HOME/opt/mpc --with-isl=$HOME/opt/isl

but this gives me:

--- snip ---
/home/lh156516/src/gcc/gcc-12.4.0/host-x86_64-pc-linux-gnu/gcc/xgcc -B/home/lh156516/src/gcc/gcc-12.4.0/host-x86_64-pc-linux-gnu/gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../.././gcc/testsuite/selftests
/home/lh156516/src/gcc/gcc-12.4.0/host-x86_64-pc-linux-gnu/gcc/xgcc -B/home/lh156516/src/gcc/gcc-12.4.0/host-x86_64-pc-linux-gnu/gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../.././gcc/testsuite/selftests
/home/lh156516/src/gcc/gcc-12.4.0/host-x86_64-pc-linux-gnu/gcc/cc1: error while loading shared libraries: libisl.so.23: cannot open shared object file: No such file or directory
make: *** [../.././gcc/c/Make-lang.in:128: s-selftest-c] Error 1
make: *** Waiting for unfinished jobs....
/home/lh156516/src/gcc/gcc-12.4.0/host-x86_64-pc-linux-gnu/gcc/cc1plus: error while loading shared libraries: libisl.so.23: cannot open shared object file: No such file or directory
make: *** [../.././gcc/cp/Make-lang.in:206: s-selftest-c++] Error 1
make: *** [Makefile:4619: all-gcc] Error 2
make: *** [Makefile:1034: all] Error 2

All of the prerequisite libraries have been built and installed to their specified ~/opt subdirectories, and I've verified that I indeed have $HOME/opt/isl/lib/libisl.so.23. So, why am I getting this error?

I'm trying to use a Qt6-based program, namely NVIDIA's Nsight Compute UI , on a machine running SLES 15 SP5 (SUSE Enterprise Linux 2015, service pack 5). No, I can't switch distributions, it's not my decision :-( Anyway, the program used to run fine in all its versions from 2023, but with more recent versions, I get:

- Error: libxcb-cursor.so.0: cannot open shared object file: No such file or directory

(for the long version, see below). Now, I can install packages on this machine, but - there is no libxcb-cursor package; there are a bunch of other libxcb-whatevers, but not that particular one. So, how can I satisfy the library requirement for my application? ----------- Long version of the error message:

qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb, wayland, offscreen, wayland-egl.

Application could not be initialized!
    This is likely due to missing Qt platform dependencies.
    For a list of dependencies, please refer to https://doc.qt.io/qt-6/linux-requirements.html 
    To view missing libraries, set QT_DEBUG_PLUGINS=1 and re-run the application.

Warning: OpenGL Version check failed. Falling back to Mesa software rendering.
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb, wayland, offscreen, wayland-egl.

################# ERROR: CrashReporter #################
CrashReporter

Qt initialization failed

Failed to load Qt platform plugin: "xcb"
 - Library path: /opt/versions/nvidia/nsight-compute/2024.3/host/linux-desktop-glibc_2_11_3-x64/Plugins/platforms/libqxcb.so
 - Error: libxcb-cursor.so.0: cannot open shared object file: No such file or directory

Please check if libxcb-cursor.so.0 has been installed on your system
See https://doc.qt.io/qt-6/linux-requirements.html  for more details.
Application is going to abort
Warning: Missing charsets in String to FontSet conversion
/opt/versions/nvidia/nsight-compute/2024.3/host/linux-desktop-glibc_2_11_3-x64/ncu-ui: line 26: 26176 Aborted

I have an sample application and an make file. * main.c file contents

-c
    #include 
    
    /*int mainentry_entry(int argc, char *argv[]) {*/
    int main(int argc, char *argv[]) {
        int i;
        printf("argc = %d\n", argc);
        for (i = 0; i  /lib/i386-linux-gnu/libc.so.6 (0xea200000)
        /usr/lib/libc.so.1 => /lib/ld-linux.so.2 (0xea48e000)

My Linux distribution (openSUSE Slowroll) accidentally shipped some incompatible libraries recently due to its experimental nature, lacking adequate automated testing using openQA, that caused the desktop environment and other programs like flatpak to crash on startup. The relevant errors:

Oct 10 09:05:09 suse-pc gnome-shell: JS ERROR: GLib.Error g-invoke-error-quark: Could not locate g_settings_bind_with_mapping_closures: 'g_settings_bind_with_mapping_closures': /lib64/libgio-2.0.so.0: undefined symbol: g_settings_bind_with_mapping_closures
Oct 14 03:07:36 suse-pc atomic-update: flatpak: symbol lookup error: /lib64/libgobject-2.0.so.0: undefined symbol: g_sort_array

I have a simple program I use to perform atomic updates, so I was wondering if there was a way to detect these undefined symbols in shared libraries/objects, so the faulty update can be discarded instead of being applied. Thanks! --- EDIT 1: I found an easy way to detect incompatible libraries was to print the version string for the program being tested:

pavin@suse-laptop:~/Downloads> gnome-control-center --version
gnome-control-center: symbol lookup error: /lib64/libgoa-backend-1.0.so.2: undefined symbol: adw_button_row_get_type, version LIBADWAITA_1_0

As @MarcusMüller said in the comments, this may not work always. So it is necessary to perform the check for a list of all essential programs you need.

I am writing a real-time linux application where I need to prevent any page faults from occuring after the initial startup of my application. My initial thought was just to call mlockall(MCL_CURRENT | MCL_FUTURE);. Calling this function returns no error code, but if I inspect my process's pages, it looks like there are still many pages that have the Locked: size at 0 (which I assume means those pages can still cause a page-fault).

$ cat /proc//smaps |  grep -B 21 -A 2 "Locked:                0 kB"  | grep -B 1 "^Size:" | grep -v "Size" | grep -v "^\-\-"
7effd0021000-7effd4000000 ---p 00000000 00:00 0 
7effd4021000-7effd8000000 ---p 00000000 00:00 0 
7effd80c6000-7effdc000000 ---p 00000000 00:00 0 
7effddf02000-7effddfa0000 rw-s 00000000 00:05 368                        /dev/some_char_device
7effddfa0000-7effde1a0000 rw-s f0000000 00:05 368                        /dev/some_char_device
7effde1c1000-7effde1c2000 ---p 00000000 00:00 0 
7effde1c6000-7effde1ca000 rw-s f7c00000 00:05 368                        /dev/some_char_device
7effde1ca000-7effde1cb000 ---p 00000000 00:00 0 
7effe221b000-7effe221c000 ---p 00000000 00:00 0 
7effe2220000-7effe2223000 rw-s 00000000 00:05 90                         /dev/another_char_device
7effe22df000-7effe22e0000 ---p 00013000 08:02 2234654                    //shared_library1.so
7effe22fd000-7effe22fe000 ---p 0000c000 08:02 2231701                    //shared_library2.so
7effe23fc000-7effe23fd000 ---p 0001c000 08:02 2234652                    //shared_library3.so
7effe2e15000-7effe2e16000 ---p 00215000 08:02 1957                       /usr/lib/x86_64-linux-gnu/libc.so.6
7effe2e40000-7effe2e41000 ---p 00011000 08:02 2234649                    //shared_library4.so
7effe2f14000-7effe2f15000 ---p 00046000 08:02 2232115                    //shared_library5.so
7effe321a000-7effe321b000 ---p 0021a000 08:02 855                        /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7effe3258000-7effe3259000 ---p 0001f000 08:02 2234643                    //shared_library6.so
7effe327d000-7effe327e000 ---p 00021000 08:02 2234641                    //shared_library7.so
7effe328a000-7effe328b000 ---p 00009000 08:02 2232116                    //shared_library8.so
7effe348e000-7effe348f000 ---p 00102000 08:02 91759                      //shared_library9.so
7effe34c6000-7effe34c8000 r--p 00000000 08:02 175                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7effe34f2000-7effe34fd000 r--p 0002c000 08:02 175                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffc1d1b0000-7ffc1d1b4000 r--p 00000000 00:00 0                          [vvar]
7ffc1d1b4000-7ffc1d1b6000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

# Some attempts and some questions... ## Attempt: Move the location of mlockall in the initialization function My main function has a bunch of dlopen calls. Previously the mlockall call was *after* the calls to dlopen. Moving the call to mlockall *before* the dlopen calls seems to lock in the memory of the shared libraries that are loaded after it. However, it does not lock in the memory of shared libraries loaded *before* the call to mlockall (those shared libraries are linked at compile-time and specified in the executable). **Why doesn't MCL_CURRENT lock in already-loaded libraries?**

$ cat /proc//smaps |  grep -B 21 -A 2 "Locked:                0 kB"  | grep -B 1 "^Size:" | grep -v "Size" | grep -v "^\-\-"
7fef0c021000-7fef10000000 ---p 00000000 00:00 0 
7fef10021000-7fef14000000 ---p 00000000 00:00 0 
7fef140c6000-7fef18000000 ---p 00000000 00:00 0 
7fef1875d000-7fef187fb000 rw-s 00000000 00:05 368                        /dev/some_char_device
7fef187fb000-7fef189fb000 rw-s f0000000 00:05 368                        /dev/some_char_device
7fef18a0a000-7fef18a0b000 ---p 00000000 00:00 0 
7fef1ca2e000-7fef1ca2f000 ---p 00000000 00:00 0 
7fef1ca33000-7fef1ca37000 rw-s f7c00000 00:05 368                        /dev/some_char_device
7fef1ca37000-7fef1ca38000 ---p 00000000 00:00 0 
7fef1ca3c000-7fef1ca3f000 rw-s 00000000 00:05 90                         /dev/another_char_device
7fef1d615000-7fef1d616000 ---p 00215000 08:02 1957                       /usr/lib/x86_64-linux-gnu/libc.so.6
7fef1da1a000-7fef1da1b000 ---p 0021a000 08:02 855                        /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7fef1dcea000-7fef1dceb000 ---p 00102000 08:02 91760                      //shared_library9.so
7fef1dd22000-7fef1dd24000 r--p 00000000 08:02 175                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7fef1dd4e000-7fef1dd59000 r--p 0002c000 08:02 175                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffece1c4000-7ffece1c8000 r--p 00000000 00:00 0                          [vvar]
7ffece1c8000-7ffece1ca000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

## Attempt: Use madvise to prefault pages I tried calling this prefault function (inspired from here ), but madvise seems to return a -1 or EPERM code on the pages with permissions ---p. If I understand correctly, those pages are mapped with MAP_PRIVATE and are supposed to be allocated in physical memory only when written to (as per the Copy-On-Write pattern). However, madvise does not seem to trigger the allocation, and just returns an error instead. **How can I pre-fault pages mapped with MAP_PRIVATE?**

void prefault()
{
    const pid_t pid = getpid();
    
    FILE *fp;
    char path[PATH_MAX];
    char buf;

    (void)snprintf(path, sizeof(path), "/proc/%" PRIdMAX "/maps", (intmax_t)pid);

    fp = fopen(path, "r");

    volatile uint8_t val;

    while (fgets(buf, sizeof(buf), fp)) {
        void *start, *end, *offset;
        int major, minor, n, ret;
        uint64_t inode;
        char prot;

        n = sscanf(buf, "%p-%p %4s %p %x:%x %" PRIu64 " %s\n",
            &start, &end, prot, &offset, &major, &minor,
            &inode, path);

   
        if (n = end) { continue; /* invalid addresse range */ }

        ret = madvise(start, (size_t)((uint8_t *)end - (uint8_t *)start), MADV_POPULATE_WRITE);
    }

    (void)fclose(fp);
}

I have an executable which loads /lib64/libpython3.so at runtime. (I am on fedora 40 right now). As far as I can tell this library loads my default python version installed, currently this links to libpython3.12.so.1.0. The binary I am trying to execute does not like this new version though, so I have to run it on python 3.9. I can install an old interpreter via dnf install python3.9, however it does not ship with the top level libpython3.so (this is another package python3-libs). I can install usr/bin/python3 via alternatives however I am unsure on how to achieve the same thing for the library. Any ideas how to get this working? I also tried conda but this does not work either.

When we run ldd on some file, there are two possible results: If the file is dynamic executable, the shared dependencies are shown, for example:

# ldd /usr/bin/sleep
        linux-vdso.so.1 (0x00007ffff7fc7000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007ffff7dd6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc9000)

Or, if the file is either a static executable or not an executable at all, we see not a dynamic executable, for example

# ldd /usr/bin/toybox
        not a dynamic executable
# ldd /etc/shadow
warning: you do not have execution permission...
        not a dynamic executable

But I have also discovered a special case! It takes place if you ever happen to invoke ldd on /usr/sbin/ldconfig. Then, ldd will **explicitly** say that the binary is statically linked!

# ldd /usr/sbin/ldconfig
        statically linked

I'm very interested to know why this happens, what's so special about the ldconfig binary? Thanks.

/* dlsym-main.c */

#include 

void doSomething(char const *msg)
{
    fprintf(stderr, "Main program is doing %s\n", msg);
}

void (*fnptr)(char const *) = doSomething;

int main() {

    fnptr("some printing");
    return 0;
}

/* dlsym-lib.c */

#define _GNU_SOURCE  1
#include 
#include 

void myLibraryFunc(char const *msg)
{
    fprintf(stdout, "My library is doing %s\n", msg);
}

void hook(void)
{
    // Load the current executable as a shared object
    void* handle = dlopen(NULL, RTLD_LAZY);
    if (!handle) {
        fprintf(stderr, "Error: %s\n", dlerror());
        return;
    }

   typedef void (*fnT)(char const *);

    // Dynamically resolve the global non-static variable
    fnT* fnPtr = (fnT*) dlsym(handle, "fnptr");
    if (!fnPtr)
    {
        fprintf(stderr, "Error locating fnptr: %s\n", dlerror());
        dlclose(handle);
        return;
    }
    *fnPtr = myLibraryFunc;

    // Close the handle
    dlclose(handle);
}

__attribute__((constructor))
void setup() { hook(); }

## Makefile

linky: dlsym-main.c
	gcc -o linky dlsym-main.c
libi.so: dlsym-lib.c
	gcc -shared -fPIC -o libi.so dlsym-lib.c -ldl

run: linky libi.so
	LD_PRELOAD=$$PWD/libi.so ./linky

Output of make run:

Error locating fnptr: Symbol not found: fnptr
Main program is doing some printing

Symbol (fnptr) is a global data object:

> objdump -t linky | grep fnptr
0000000000020008 g     O .data	0000000000000008 fnptr

Using LD_DEBUG=symbols (Debian) shows that it's looking in the executable:

318:	symbol=fnptr;  lookup in file=./linky 
       318:	symbol=fnptr;  lookup in file=/CDS/libi.so 
       318:	symbol=fnptr;  lookup in file=/usr/lib/aarch64-linux-gnu/libstdc++.so.6 
       318:	symbol=fnptr;  lookup in file=/lib/aarch64-linux-gnu/libc.so.6 
       318:	symbol=fnptr;  lookup in file=/lib/aarch64-linux-gnu/libdl.so.2 
       318:	symbol=fnptr;  lookup in file=/lib/aarch64-linux-gnu/libm.so.6 
       318:	symbol=fnptr;  lookup in file=/lib/aarch64-linux-gnu/libgcc_s.so.1 
       318:	symbol=fnptr;  lookup in file=/lib/ld-linux-aarch64.so.1 
       318:	/CDS/libi.so: error: symbol lookup error: undefined symbol: fnptr (fatal)

I've tried this on Debian, Alpine (musl libc), and other variants (all GCC) and the same results occur. I've asked AI bots how to do this and they spit out exactly this code. The same code on macOS works fine

▶ make run_macOS
DYLD_INSERT_LIBRARIES=$PWD/libi.so ./linky
My library is doing some printing

What am I doing wrong that this doesn't work on GCC?

I am investigating the memory impact of containerising two processes that depend on the same shared object. My main question is whether the shared object will be loaded in memory twice or not. This question has been asked before, but the answers were not complete and contradicting with my experiments. I will cite what I already encountered: https://unix.stackexchange.com/questions/116327/loading-of-shared-libraries-and-ram-usage --> Use -fPIC for your .so https://unix.stackexchange.com/questions/671259/do-docker-containers-share-ram-for-files-memory-mapped-from-the-same-layer-but-a --> Yes, but depends on your setup. You can prove it but checking the device and inode id of the loaded shared object. No indication of what setup to use. https://stackoverflow.com/questions/35863608/shared-library-in-containers --> Yes, depends on your storage driver. aufs, overlay or overlay2 storage drivers support this. https://stackoverflow.com/questions/63145223/about-loading-dynamic-library-in-container --> Each container is its own execution unit. No sharing occurs. Contradicting with the previous. I used the following setup: - base layer --> Contains the OS and two shared objects (G and S - Precompiled using -fPIC) - dependsOnG layer --> Starts from base, contains the executable which depends only on G (Precompiled) - dependsOnGandS layer --> Starts from base, contains the executable that depends both on G and S (Precompiled) Storage driver: Overlay Below you can see the information from grep glib /proc/PID/maps. The PIDs are the processes of the executables inside the container.

| /proc/17/maps:7efd3b630000-7efd41980000 | r-xp | 00000000 | 00:a2             | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41980000-7efd41b7f000 | ---p | 06350000 | 00:a2             | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b7f000-7efd41b80000 | r--p | 0634f000 | 00:a2             | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b80000-7efd41b81000 | rw-p | 06350000 | 00:a2             | 16802420 | /app/libglib.so |

| /proc/39/maps:7fca97208000-7fca9d558000 | r-xp | 00000000 | 00:bb             | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d558000-7fca9d757000 | ---p | 06350000 | 00:bb             | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d757000-7fca9d758000 | r--p | 0634f000 | 00:bb             | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d758000-7fca9d759000 | rw-p | 06350000 | 00:bb             | 16802420 | /app/libglib.so |

If I interpret the result correctly, the two processes view completely different files (the device id is different), thus, the shared object will be loaded twice in memory (seems consistent with what I see with the free command). According to the information I found online this shouldn't happen. I have the following questions: 1. Should the shared object be loaded only once? 2. Does the overlay storage driver support this functionality? 3. Should I be constructing my images/containers in a different way? (I did the same experiments using volumes instead of common layers and indeed the files were identical, however, that's not quite what I want) Thanks in advance!

I have an executable which is linked with several dynamic libraries (.so). These libraries are found in 2 different local folders. When linking the executable, the RUNPATH of the executable is correctly set to these two folders. When running the executable I'm getting loader errors telling me some libraries are not found. Inspecting with LD_DEBUG=libs ldd my_executable, shows that after having found one or more system libraries the loader is no more using the RUNPATH of the executable to search local libraries. At least this is my conclusion when inspected the output. What might be wrong? On my build, on my OS? I'm using Debian testing, but I have this problem also on Ubuntu 22.04. Here's a sketchup of my build:

/usr/bin/c++ \
-Wall \
-Wno-strict-aliasing \
-fdiagnostics-color=always \
main.cpp.o \
-o main \
-Wl,-rpath,/path/to/A:/path/to/B \
/path/to/A/lib1.so \
/path/to/A/lib2.so \
/path/to/B/lib3.so

When running LD_DEBUG=libs ldd main I'm getting something like this:

417465:     find library=lib1.so ; searching
417465:      search path=/path/to/A:/path/to/B     (RUNPATH from file ./main)
417465:       trying file=/path/to/A/lib1.so
417465:
417465:     find library=lib3.so ; searching
417465:      search path=/path/to/A:/path/to/B     (RUNPATH from file ./main)
417465:       trying file=/path/to/A/lib3.so
417465:       trying file=/path/to/B/lib3.so
417465:
417465:     find library=libmd.so.0 ; searching
417465:      search cache=/etc/ld.so.cache
417465:       trying file=/lib/x86_64-linux-gnu/libmd.so.0
417465:     
417465:     find library=libkrb5.so.3 ; searching
417465:      search cache=/etc/ld.so.cache
417465:       trying file=/lib/x86_64-linux-gnu/libkrb5.so.3
417465:     
417465:     find library=lib2.so ; searching
417465:      search cache=/etc/ld.so.cache
417465:      search path=/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/lib:/usr/lib              (system search path)
417465:       trying file=/lib/x86_64-linux-gnu/lib2.so
417465:       trying file=/usr/lib/x86_64-linux-gnu/lib2.so
417465:       trying file=/lib/lib2.so
417465:       trying file=/usr/lib/lib2.so

As we can see, RUNPATH is no more used after some library search steps.