I’m trying to run a C program, but every time I try to run it I get this message: error while loading shared libraries: libpcap.so.0.8: cannot open shared object file: No such file or directory I've re-installed libpcap; I've installed gcc and g++; I’ve updated it and I’m lost. I’m not sure what else I can do. Could anyone help out?

Is it acceptable to specify system paths (/lib, /usr/lib, contents of ld.so.conf.d, etc.) in LD_LIBRARY_PATH? Wouldn't this cause problems? My goal is that an external program, which I can't rebuild at will, would look for libraries first in the system paths, and only if there are none, in my directories. So I want to specify the system paths first, then my directories in the LD_LIBRARY_PATH variable. I know it's better to use containers for these situations, but I'm limited in what I can do.

I encountered an error when trying to generate a cookbook using the command chef generate cookbook test-cookbook. The error message I received is as follows:

ERROR : exit status 127
/opt/chef-workstation/embedded/bin/ruby:  error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

The error appears to be caused by a missing shared library called libcrypt.so.1. How can I fix this issue and generate the cookbook successfully?

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?

Im getting the error below while trying to run vtysh for some network simulations

vtysh: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory

Currently I have libreadline-dev and libreadline-7 installed, and made a symlink that points to libreadline.so.7 at /lib/x86_64-linux-gnu/libreadline.so.6 but to no avail. I'm assuming it might be looking for a different path, but I'm not sure how to approach troubleshooting problems like these. ------------------------- No such luck with the suggestions below. After compiling readline6.3 from the source code as suggested below, my output from ldconfig -v | grep readline is:

/sbin/ldconfig.real: Can't stat /usr/local/lib/x86_64-linux-gnu: No such file or directory
/sbin/ldconfig.real: Path `/lib/x86_64-linux-gnu' given more than once
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once
	libreadline.so.6 -> libreadline.so.6.3
	libreadline.so.7 -> libreadline.so.7.0
/sbin/ldconfig.real: /lib/x86_64-linux-gnu/ld-2.27.so is the dynamic linker, ignoring

	libguilereadline-v-18.so.18 -> libguilereadline-v-18.so.18.0.0
/home/gdc/Desktop/readline-6.3:
/sbin/ldconfig.real: /lib32/ld-2.27.so is the dynamic linker, ignoring

I have an AI program which uses Vulkan API. I want to run it on a Debian server without GPU. I know running Vulkan on CPU is possible but it's slow. What should I install/configure to have Vulkan on CPU on Debian 9? Right now I just get this error: > error while loading shared libraries: libvulkan.so.1: cannot open > shared object file: No such file or directory I think I found a solution: https://github.com/google/swiftshader But I can't test it because my cmake is too old.

I downloaded a game. It has a issue of just not working every time I launch it I'm welcomed by a white screen. Did some cli magic, found out that the game is missing few libraries, installed them. The game still doesn't work, as far as I was able to find out it has trouble loading libsteam_api.so which I can't find a fix for too. The game has few launch scripts, and when launched with one it generates a .dmp file, running file shows the file type as: Mini DuMP crash report \* found old discussion on steam which suggested that my gpu just isn't fast enough, but I'm still going to try and fix it

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?

Is it possible to specify a path with the library that the program should use instead of searching system variables?

Based on https://unix.stackexchange.com/questions/784690/limit-file-io-speed I have built https://git.data.coop/tange/tangetools/src/branch/master/iothrottle It works for some programs: iothrottle -i 10M cat foo > bar # Yes, here you could just use pv iothrottle -o 1M ffmpeg -i foo.mp3 foo.wav iothrottle -o 1M cp -a foodir /other/fs/foodir This does not: iothrottle -o 1M cp -a foodir /same/fs/foodir because on the same file system cp uses a single call to copy_file_range per file. I am OK with that limitation. It also does not work for seq. When I run strace seq 100000 I get: ~~~ write(1, "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14"..., 8192) = 8192 write(1, "\n1861\n1862\n1863\n1864\n1865\n1866\n1"..., 4096) = 4096 write(1, "2680\n2681\n2682\n2683\n2684\n2685\n26"..., 4096) = 4096 write(1, "499\n3500\n3501\n3502\n3503\n3504\n350"..., 4096) = 4096 write(1, "18\n4319\n4320\n4321\n4322\n4323\n4324"..., 4096) = 4096 write(1, "7\n5138\n5139\n5140\n5141\n5142\n5143\n"..., 4096) = 4096 write(1, "\n5957\n5958\n5959\n5960\n5961\n5962\n5"..., 4096) = 4096 write(1, "6776\n6777\n6778\n6779\n6780\n6781\n67"..., 4096) = 4096 write(1, "595\n7596\n7597\n7598\n7599\n7600\n760"..., 4096) = 4096 write(1, "14\n8415\n8416\n8417\n8418\n8419\n8420"..., 4096) = 4096 write(1, "3\n9234\n9235\n9236\n9237\n9238\n9239\n"..., 3838) = 3838 ~~~ So it seems to call write (and not some mmap or other magic), and thus ought to work. But when I run: IOTHROTTLE_DEBUG=1 iothrottle -o 1M seq 10000 >/dev/null I get: ~~~ init called: default read_limit=0, write_limit=0 IOTHROTTLE_READ=0 IOTHROTTLE_WRITE=1048576 Final read_limit=0, write_limit=1048576 allowed: 608 written: 0 allowed: 617 written: 0 ~~~ This tells me that iothrottle only intercepts 2 calls to write. What am I missing?

New noob here. Using MX Linux, set up Mutt with gmail. Was initially successful. Emails and all. Then at some point when trying to use again, it stuck at 4% giving a segmentation fault. Using gdb it says: Fetching message headers... 6202/132349 (4%) Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7c2ea5f in ?? () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9 (gdb) bt #0 0x00007ffff7c2ea5f in ?? () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9 #1 0x00007ffff7c2fca8 in tcbdbput () from /lib/x86_64-linux-gnu/libtokyocabinet.so.9 #2 0x000055555561e5da in ?? () #3 0x000055555561eded in ?? () #4 0x000055555562dfe3 in ?? () #5 0x000055555562bb1c in ?? () #6 0x000055555562893d in ?? () #7 0x00005555555b774e in ?? () #8 0x000055555556c3ea in ?? () #9 0x00007ffff795cd7a in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x000055555556d44a in ?? () What do I do?

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 was re-doing what described here about multiprocessing debugging in GDB. The weird thing is that GDB doesn't hit the exec catchpoint on the child process running cat command (the latter is forked off from bash). ubuntu@ubuntu:~$ echo $$ 670639 ubuntu@ubuntu:~$ cat /etc/issue root@ubuntu:~# gdb -q -p 670639 Attaching to process 670639 Reading symbols from /usr/bin/bash... (No debugging symbols found in /usr/bin/bash) Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so.6... (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so.6) Reading symbols from /lib/x86_64-linux-gnu/libc.so.6... Reading symbols from /usr/lib/debug/.build-id/49/0fef8403240c91833978d494d39e537409b92e.debug... Reading symbols from /lib64/ld-linux-x86-64.so.2... Reading symbols from /usr/lib/debug/.build-id/41/86944c50f8a32b47d74931e3f512b811813b64.debug... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". pselect64_syscall (sigmask=0x564025a0c820 , timeout=, exceptfds=0x0, writefds=0x0, readfds=0x7ffe468736e0, nfds=1) at ../sysdeps/unix/sysv/linux/pselect.c:34 34 ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory. (gdb) catch fork Catchpoint 1 (fork) (gdb) catch exec Catchpoint 2 (exec) (gdb) c Continuing. Catchpoint 1 (forked process 719946), arch_fork (ctid=0x7fbccdc6fa10) at ../sysdeps/unix/sysv/linux/arch-fork.h:52 52 ../sysdeps/unix/sysv/linux/arch-fork.h: No such file or directory. (gdb) info inferiors Num Description Connection Executable * 1 process 670639 1 (native) /usr/bin/bash (gdb) set detach-on-fork off (gdb) nexti [New inferior 2 (process 719946)] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 52 in ../sysdeps/unix/sysv/linux/arch-fork.h (gdb) c Continuing. What is the reason behind it? Thanks.

I accidentally renamed ld-linux-aarch64.so.1. Now I cannot connect my target machine with SSH. How can I rename it back? I will not consider to reflash my target machine.

I made a simple memory manager, and I'm trying to compile it using a shared library in the driver. The shared library files itself compiles fine, however when I compiled the driver by calling the functions in the shared library with my memory manager, it shows me the screenshot below: Here is my code for the shared.c: /* conveniences for casting and declarations */ typedef block_info* (*MM_CREATE)(size_t, MMPolicy); typedef void* (*MM_ALLOCATE)(block_info *, size_t, char *); typedef int (*MM_DEALLOCATE)(block_info *, void *); typedef void (*MM_DESTROY)(block_info *); /* Function pointers retrieved from the shared library */ typedef struct LibraryFunctions { MM_CREATE create; MM_DESTROY destroy; MM_ALLOCATE allocate; MM_DEALLOCATE deallocate; }LibraryFunctions; /* Loads a shared library and returns a pointer to it in libhandle */ /* Returns SUCCESS, if it successful, otherwise, FAILURE */ int load_library(const char *libname, void **libhandle) { *libhandle = dlopen(*libhandle, RTLD_LAZY); if(!(*libhandle)) { return FAILURE; } else { return SUCCESS; } return *libname; } int get_functions(void *libhandle, LibraryFunctions *functions, const char **fn_names) { functions->create = (MM_CREATE)(intptr_t)dlsym(libhandle, *fn_names); if(!functions->create) { return FAILURE; } functions->destroy = (MM_DESTROY)(intptr_t)dlsym(libhandle, *fn_names); if(!functions->destroy) { return FAILURE; } functions->allocate = (MM_ALLOCATE)(intptr_t)dlsym(libhandle, *fn_names); if(!functions->allocate) { return FAILURE; } functions->deallocate = (MM_DEALLOCATE)(intptr_t)dlsym(libhandle, *fn_names); if(!functions->deallocate) { return FAILURE; } return SUCCESS; } Here is part of the driver code to call the shared library: void setup(void) { const char *fn_names[] = {"mm_create", "mm_destroy", "mm_allocate", "mm_deallocate"}; LibraryFunctions funs; int error; error = load_library("./libmemmgr.so", &gLib); if (error == FAILURE) { printf("load_library failed! %s\n", dlerror()); exit(-1); } error = get_functions(gLib, &funs, fn_names); if (error == FAILURE) { printf("get_functions failed! %s\n", dlerror()); exit(-1); } mmlib_create = funs.create; mmlib_destroy = funs.destroy; mmlib_allocate = funs.allocate; mmlib_deallocate = funs.deallocate; } void teardown(void) { dlclose(gLib); } I'm not sure what is causing the errors. edit: So I managed to run the exe file but I failed on "get_functions". Are there any problems with my get_functions?

In a remote system to which I don't have console access, which I'm connecting through ssh, I broke the sudo installation and now I'm not able to use it at all, and I'm not able to restart as a root. The command I ran was:

-sh
sudo mv /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/libm.so.6_org

Everytime I do sudo it says segmentation fault, for example:

-shellsession
~$ sudo -s
Segmentation fault (core dumped)

As specific cases, - id works: uid=1479554(s1474782) gid=100(users) groups=100(users),27(sudo),999(docker) - sh works as well - sudo id doesn't work: sudo id Segmentation fault (core dumped) - su s1474782 -c id doesn't work: sudo id Segmentation fault (core dumped) I was updating some libraries and I think I broke the libm.so.6 library, however I don't see sudo depending on it:

-shellsession
ldd $(which sudo)
    linux-vdso.so.1 =>  (0x00007ffd7ef9e000)
    libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f139de21000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f139dbff000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f139d9fc000)
    libsudo_util.so.0 => /usr/lib/sudo/libsudo_util.so.0 (0x00007f139d7e8000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f139d41e000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f139d1ae000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f139cfaa000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f139e26b000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f139cd8d000)

Any advice how to solve this? I can just re-install sudo?

In my docker container I run the following command to install the lib pcap: apt-get install -y libpcap-dev When I run apt list --installed I see this weird output:

libpcap-dev/oldstable,now 1.8.1-6 amd64 [installed]
libpcap0.8-dev/oldstable,now 1.8.1-6 amd64 [installed,automatic]
libpcap0.8/oldstable,now 1.8.1-6 amd64 [installed,automatic]

Does anyone know why it shows "oldstable" and then "now"? Also, how do I force the installation of the latest version of libpcap and libpcap-dev? I've been searching all over but can't figure it out. Thanks! P.S. I'm doing the installation inside a Docker container.

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 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.

On our linux dev server for an application at work, we have an in-house C program called sendFile to, well, send files to the Mqueue. The program has seemingly not been changed since its creation in 2011 and works well enough as is, but I recently tried to add something to it (a 3rd queue definition), and ran into issues when trying to compile it. The compiling command, which I assembled from the makefile, is as follows : gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer sendFile.c -o sendFile -I/opt/mqm/inc -L/opt/mqm/lib/ -lmqic The last part, -lmqic, is what's causing issues. Specifically, I get this : /bin/ld: skipping incompatible /opt/mqm/lib//libmqic.so when searching for -lmqic /bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/8/../../../libmqic.so when searching for -lmqic /bin/ld: skipping incompatible //lib/libmqic.so when searching for -lmqic /bin/ld: skipping incompatible //usr/lib/libmqic.so when searching for -lmqic /bin/ld: cannot find -lmqic collect2: error: ld returned 1 exit status And when I remove that argument, I get errors due to undefined reference to MQOPEN, MQCONN, MQCLOSE, etc. (functions of the mqic library, I presume). Per the ldd command, I was able to see which libraries are used by the program : linux-vdso.so.1 (0x00007ffcd63e9000) libmqic.so => /opt/mqm/lib64/libmqic.so (0x00007faf14597000) libc.so.6 => /usr/lib64/libc.so.6 (0x00007faf141d2000) libmqe.so => /opt/mqm/lib64/libmqe.so (0x00007faf135f6000) libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007faf133f2000) libm.so.6 => /usr/lib64/libm.so.6 (0x00007faf13070000) /lib64/ld-linux-x86-64.so.2 (0x00007faf1479b000) librt.so.1 => /usr/lib64/librt.so.1 (0x00007faf12e68000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007faf12ad3000) libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007faf128b3000) libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007faf1269b000) The /opt/mqm/lib64/libmqic.so library seems to be exactly what -lmqic refers to, and does exist on the server, so I'm rather puzzled as to why the compiler somehow can't find it. I did try to yum install mqic (in case the version on the server is incompatible as the error messages seem to suggest), but it didn't seem to exist under that name (though maybe I need to name it differently). Thanks in advance for any help! It's likely a very easy solution, and I'll be glad to be the fool if so.