I'm trying to compile VTK from source and I received the following error. I'm running Fedora 27, kernel version 4.14.11-300.fc27.x86_64 /usr/lib64/libSM.so: undefined reference to `uuid_generate@UUID_1.0' /usr/lib64/libSM.so: undefined reference to `uuid_unparse_lower@UUID_1.0' ldd /usr/lib64/libSM.so shows $ldd /usr/lib64/libSM.so linux-vdso.so.1 (0x00007ffd4998b000) libICE.so.6 => /lib64/libICE.so.6 (0x00007f3aa36ff000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f3aa34fa000) libc.so.6 => /lib64/libc.so.6 (0x00007f3aa3115000) /lib64/ld-linux-x86-64.so.2 (0x00007f3aa3b23000) Further looking at the symbols in libuuid.so.1 shows $objdump -T /lib64/libuuid.so.1 | grep 'uuid_generate$' 0000000000002370 g DF .text 0000000000000087 UUID_1.0 uuid_generate $objdump -T /lib64/libuuid.so.1 | grep 'uuid_unparse_lower' 0000000000002710 g DF .text 0000000000000002 UUID_1.0 uuid_unparse_lower The output of ldconfig is $sudo ldconfig -p | grep libuuid libuuid.so.1 (libc6,x86-64) => /lib64/libuuid.so.1 libuuid.so.1 (libc6) => /lib/libuuid.so.1 $ sudo ldconfig -p | grep libSM libSM.so.6 (libc6,x86-64) => /lib64/libSM.so.6 libSM.so.6 (libc6) => /lib/libSM.so.6 libSM.so (libc6,x86-64) => /lib64/libSM.so I'm not sure, what is going on here. Can someone please help? Thank you Senthil

I've read **a lot** of guidance that says the LD_LIBRARY_PATH is searched before anything else, but one of my .so libraries is linking with libtdc++.so.6 in /usr/lib64. ldd mylib.so: ... libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f82abd18000) ... I want mylib.so to link with libstdc++.so.6 in another location, like /apps/gcc_4.8.0/lib/libstdc++.so.6 So I add /apps/gcc_4.8.0/lib to LD_LIBRARY_PATH, which ***does not*** have /usr/lib64 in it, but it still doesn't find it there. If I add: setenv LD_PRELOAD /apps/gcc_4.8.0/lib/libstdc++.so.6 to my environment, there are no more linker errors. Yay, but that doesn't solve the problem. Users downstream aren't going to want to depend on this library being in the proper place. WHY ISN"T LD_LIBRARY_PATH BEING SEARCHED FIRST!?!

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.

Reference: Weak symbol In the link the following linker option is mentioned: cc main.o -Lpwd -Wl,-Rpwd -lpowerslow -o main2 The purpose of all of the above flags have been documented in the GCC Manual, except -R. What does this flag instruct the linker? TIA Vinod

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?

$ file /lib/ld-linux.so.2 /lib/ld-linux.so.2: symbolic link to i386-linux-gnu/ld-2.27.so $ readlink -f /lib/ld-linux.so.2 /lib/i386-linux-gnu/ld-2.27.so $ file /lib/i386-linux-gnu/ld-2.27.so /lib/i386-linux-gnu/ld-2.27.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=7a59ed1836f27b66ffd391d656da6435055f02f8, stripped So is ld-2.27.so a shared library? It is said to be a dynamic linker/loader and mentioned in section 8 of man . So is it an executable? If yes, why is it named like a shared library as *.so? If no, how shall I understand it is like an executable, for being a dynamic linker/loader and mentioned in section 8 of man? Thanks.

Compiling code with GCC or Clang can result in some colorful error outputs. Linking code, however, doesn't enjoy the same luxury. It seems like the GNU Linker doesn't support colorized error output right out of the box. Is there a way around this? Is it possible to colorize/stylize linker errors from ld?

I am learning about the relocation from the ELF reference and this blog , but I can't get my head around calculating the relocation address. 1. Suppose we have two files A and B of type ET_REL, we want to merge their sections named S during linkage; these sections include symbols SA (in A file) and SB (in B) file. If we have relocation entries and relocation offsets in A.elf and B.elf, I don't understand how linker avoids conflict of relocation addresses: I assume that these offsets might be the same in A.elf and B.elf, since these files don't know about each other during compilation. 2. What is the purpose of relocation table in ET_EXEC? I can't see why is it needed. 3. What is the purpose of the addend in relocation of Rela type? I think that most of all I don't have a clear intuition on how the relocation looks like, step by step. There is an example in the blog , but I don't understand what happens exactly with that symbol, what is the result and how do we combine multiple sections. Any suggestions on resource to learn would be appreciated.

I am trying to run adbd from within a chrooted environment. I can run it fine with Android's LD_LIBRARY_PATH=$PWD ./linker64 $PWD/adbd. When I try to run ./adbd I get: bash: ./adbd: cannot execute: required file not found. Running with strace $PWD/adbd returns:

execve("/root/adbd", ["/root/adbd"], 0x7fcfe8dfd0 /* 8 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

What dynamic linker is missing and on which path?

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.

- How to set library search path through environment variables? (since I'm using bazel) - How to print library search path used by ld.gold (so I can check if I set it correctly) **Context:** I'm compiling a project using bazel, and the error message is: /usr/bin/ld.gold: error: cannot find -lresolv_wrapper Here is the output of ldconfig:

➜  /tmp ldconfig -p | grep resolv_wrapper
	libresolv_wrapper.so.0 (libc6,x86-64) => /home/xiaochencui/local/libresolv_wrapper/lib/libresolv_wrapper.so.0
	libresolv_wrapper.so (libc6,x86-64) => /home/xiaochencui/local/libresolv_wrapper/lib/libresolv_wrapper.so

**Note:** - I have read this page but it doesn't help: https://unix.stackexchange.com/questions/637498/ld-cant-find-library-to-link-even-though-ldconfig-v-lists-the-file - I know we can add library search path by --library-path arg, but I'm not using ld.gold directly.

I have an existing executable for which a small amount of source code has been lost. In particular, the executable uses a few functions from a static library, and the source code for that library is missing. I do have an older version of that library's code, but the executable uses three or four methods that aren't in the old version. I have a header file for the new version of the code, which includes prototypes of the missing functions, but the .c file containing the actual function definitions is missing. Since the executable is statically linked, I wonder if there is a way to rebuild the static library by extracting the object code from it. I can find the symbols I need using nm and objdump, but I don't know if there's a way to extract those functions and re-package them into object files or a static library. As an example, it looks something like this:

$ nm ./theApplication

001721dc T _missingFunction1

00171ed8 T _missingFunction2


$ objdump --disassemble-all ./theApplication

00171ed8 :
  171ed8:       1a e5 f8 14     P2 = [P3 + 0x53e0];

001721dc :
  1721dc:       c5 04           [--SP] = (P5:5);

I'd like to pull missingFunction1() and missingFunction2() out into a static library or object files so I can link against them in other executables. Is that possible, and if so, how can it be done?

In the past I have embedded resource files (images) into programs by first converting them to .o files using the GNU linker. For example: ld -r -b binary -o file.o file.svg Starting with FreeBSD 12, the default linker has changed from GNU's to LLVM's. Although the linker appears to understand the command line options, it results in an error. For example: ld -r -b binary -o file.o file.svg ld: error: target emulation unknown: -m or at least one .o file required Also tried using the command line options from the [ld.lld(1)](https://www.freebsd.org/cgi/man.cgi?query=ld) manual page: ld --relocatable --format=binary -o file.o file.svg ld: error: target emulation unknown: -m or at least one .o file required Am I using the correct tool? Do I need to specify a value for the -m option?

If I understand correctly, the variables LIBPATH and LD_LIBRARY_PATH have a higher priority than the argument to the linker -blibpath. I'm looking for how to tell the loader to search for libraries along the paths prescribed during compilation (that is, -blibpath or some other). On linux, for example, there is -rpath, which has priority higher than variables. I'm looking for an analog on AIX. I'm also looking for where the priority of paths for finding libraries on AIX is clearly described.

I was curious if it's possible to build Linux kernel without GNU toolchain (gcc+autotools). I found out that it is possible: after applying patches from llvm.linuxfoundation.org , it was possible to build Linux kernel with clang. GNU linker was used. The alternative to ld is gold which is also part of GNU binutils. Popular musl+clang toolchain ELLCC also uses GNU binutils. There are more alternatives: lld (no stable releases), mclinker (no stable releases). Does alternative to GNU binutils exist? Probably, building on Mac OS X or FreeBSD doesn't involve GNU tools.

I was reading a textbook which describes static libraries anad shared libraries. There are two source files, addvec.c and multvec.c, to create a static library of them, we would use the ar tool as follows:

linux> gcc -c addvec.c multvec.c
linux> ar rcs libvector.a addvec.o multvec.o

so basically it just create relocatable object files (.o) first then use the ar tool with those .o files. But if we want to build a shared library libvector.so then the command in the book is:

linux> gcc -shared -fpic -o libvector.so addvec.c multvec.c

note that we use source file (.c) as arguments directly, not relocatable object files. So why for share libraries, there is no need to produce relocatable object files and use source files directly, which is inconsistent compared to static linking which uses relocatable object files?

I am trying to build 32bit versions of two programs, and both shows the same error message /usr/bin/ld: cannot find /media/34GB/Arquivos-de-Programas-Linux/Glibc-2.17-32bit/lib/libpthread.so.0 I certainly understand why it cannot find it, as I moved Glibc dir from the above path to: /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libpthread.so.0 However, I have no idea as to why ld is looking for libpthread in this wrong path. I have a bunch of symbolic links to Glibc lib files in /usr/lib32, but these are all correct, with the one responsible to libpthread pointing to the second path above. I executed ldconfig but to no avail When I tried to build the first program, I thought some libraries that I was passing to configure had this old path hard linked on it, and so it was the cause. However, when I run configure on the second program, I don't need to pass any library to it for the same error message to show up, so the cause is likely other. So, I am open to any suggestion as to why is ld looking for libpthread in the old directory.

I have built Qt6 in an Alma8 based Docker container, with the Docker host being Fedora 35. Under some circumstances (described below), all Qt libs cannot load libQt6Core.so[.6[.2.4]]. But that file exists and the correct directory is searched for that file. Other Qt libs (e.g., libQt6Dbus.so) are found and loaded. Extensive debugging, re-building, seaching-the-web did not yield any clues what the underlying cause is and how I could fix it. ### Locating the problem I have narrowed down the problem to the following scenario: - I created two minimal VMs, one with centos7 and one with alma8. - I installed Docker from the official repos into both of them. - I ran the same Docker image in both VMs and installed the same qt6 package. - **It breaks when the Docker host is centos7.** - **It works when the Docker host is alma8.** ### Theory and Question - Qt6 was built on Alma8 and links to some system libraries newer than what Centos7 provides, so Qt6 cannot run unter Centos7 (this is totally expected and okay). But it *should* run anywhere in the Alma8 Docker container. - Container images should be able to run anywhere, but in this case "something" from the host OS sneaks into the container and causes the Issue – even though both containers use the exact same image! The question is: What is this "something" and how/why does it break the build? ### What I tried I inspected libQt6Gui.so to see whether or not it can load libQt6Core.so and I inspected libQt6Core.so to see if something looks bogus using: - ldd and LD_DEBUG=libs ldd which indeed showed some differences (see below) - [libtree](https://github.com/haampie/libtree) which showed no differences (but a nice tree :)) - pyldd (from conda-build) - readelf -d What I also tried: - Setting LD_LIBRARY_PATH (did not change anything – no surprise since I know that the correct path is always searched) - Building Qt6 in an alma8 container with a centos7 host (build failed with "libQt6Core.so.6: cannot open file", same error as with the built lib) - Building Qt6 in a centos7 container (build failed due to other problems I could not yet fix) ### Differences from ldd In the screenshots below, you see a the Alma8-Docker-Container on a Centos7 host on the *left* and the Alma8-Docker-Container on an Alma8 host on the *right. The first two images show the results for ldd /opt/emsconda/lib/libQt6Gui.so. libQt6Core can not be found on the left but is found on the right. This second screenshot shows that other Qt libs *are* found and loaded. The ICU libs are also missing on the left - maybe they are only loaded when libQt6Core was also loaded? This screenshot shows the results of LD_DEBUG=libs ldd .... You can see that in both cases, libQt6Core is search in the correct location (/opt/emsconda/lib). But it is only loaded in the right container. The left one additionally looks in `/opt/emsconda/lib/./ (haha)) and then silently walks on to the next lib ... I could not find any error messages. This file is just not opened/loaded. Inspecting the libQt6Core.so itself might give us a clue. It links to a linux-vdso.so.1. According to [this SO question](https://stackoverflow.com/questions/58657036/where-is-linux-vdso-so-1-present-on-the-file-system) , that file is a virtual lib injected into the userspace by the OS kernel. Since Docker containers do not run their own kernel, I suspect that that file comes from the host OS. Maybe, libQt6Core relies on some functionality in the linux-vdso.so.1 that the centos7 kernel cannot provide? I have no idea ... ---- Since nothing I tried so far yields an error message, I have no clue what the acutal problem might be or how to proceeded with debugging. I'd be greatful for any kind of hints, tips or help.

I have two versions of a library, zita-convolver3 and zita-convolver4. The system library is zita-convolver3, but i want to link against zita-convolver4, which is stored in a local user directory. How do i get meson to compiler.find_library zita-convolver4 instead of prioritising the system version zita-convolver3? I can work around this by using a pkg-config file and setting the pkgconfig_path to explicitly set this. But is there a way of doing it using only meson?

I understand that with Linux, RAM gets divided into kernel space and user space. Kernel space is reserved for running the kernel, and user space applications should not have direct access to the memory there. How exactly does this memory get divided into kernel space and user space? Is it defined in the linker script when building the kernel?