Getting "cannot open shared object file" even though ldd shows it can find it

Question

I looked for similar post on this topic but none the solutions work for me. I am trying to build a small program using openssl.

/mnt/sda1/openssl$ gcc tstsvr.c -I/mnt/sda1/openssl/include -L/mnt/sda1/openssl -lcrypto -lssl

When I try to run it:

$ sudo ./a.out
./a.out: error while loading shared libraries: libcrypto.so.81.1.1: cannot open shared object file: No such file or directory

But:

$ ldd a.out
        linux-vdso.so.1 (0x00007fff23fe6000)
        libcrypto.so.81.1.1 => /mnt/sda1/openssl/libcrypto.so.81.1.1 (0x00007f82f1db9000)
        libssl.so.81.1.1 => /mnt/sda1/openssl/libssl.so.81.1.1 (0x00007f82f1d1e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f82f1b1a000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f82f1b14000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f82f1af1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f82f20ad000)

Format looks fine (inside /mnt/sda1/openssl):

$ file a.out
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=760dc5f7be4f51f598bab38a0b1eab1a42ef8a68, for GNU/Linux 3.2.0, not stripped
$ file libcrypto.so.81.1.1
libcrypto.so.81.1.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=404d1e7ed143383801efbb10ed7914f2cd0858d4, not stripped
$ ldd libcrypto.so.81.1.1
        linux-vdso.so.1 (0x00007ffc44b5a000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1083a8c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1083a69000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1083877000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1083d93000)

Just to make sure, I added path to LD_LIBRARY_PATH as well. Even ran sudo ldconfig. Neither made any difference.

What else can I try?

Is `/mnt/sda1` mounted `noexec`, by any chance? (I wouldn't expect `No such file or directory` in that case, though.) — Steve Summit, Feb 08 '23 at 04:20
What does `wc /mnt/sda1/openssl/libcrypto.so.81.1.1` give you? — Steve Summit, Feb 08 '23 at 04:21
`9690 67246 3394632 /mnt/sda1/openssl/libcrypto.so.81.1.1` . `/mnt/sda1` isn't mounted `noexec`. Other programs executes just fine. — some user, Feb 08 '23 at 04:42
Do you have the same issue if you run the program without using `sudo`? I realize that the program might then not have sufficient privilege to do everything it wants to do, but you might not expect some of the things that `sudo` can do with your environment. — John Bollinger, Feb 08 '23 at 05:08
In particular, `/mnt/sda1/openssl` is a very unusual path in which to find a shared library. It's entirely possible that it is in your dynamic library search path in your normal shell environment, but not in the environment in which your program runs when you launch it via `sudo`. — John Bollinger, Feb 08 '23 at 05:14
Are you using `LD_LIBRARY_PATH` to locate your shared objects? This seems relevant: [**How to keep environment variables when using sudo**](https://stackoverflow.com/questions/8633461/how-to-keep-environment-variables-when-using-sudo) — Andrew Henle, Feb 08 '23 at 05:22
@AndrewHenle - Yes! Looks like that's the issue. sudo did not inherit the LD_LIBRARY_PATH. I confirmed using `sudo ldd a.out`. `sudo LD_LIBRARY_PATH=/mnt/sda1/openssl ./a.out` worked for me. Please make an answer and I will accept it as resolved. — some user, Feb 08 '23 at 06:00

Allan Wind · Accepted Answer · 2023-02-08T17:46:16.897

Per sudoers(5):

By default, the env_reset flag is enabled. This causes commands to be executed with a new, minimal environment.
...
Note that the dynamic linker on most operating systems will remove variables that can control dynamic linking from the environment of set-user-ID executables, including sudo. Depending on the operating system this may include RLD*, DYLD, LD_, LDR_*, LIBPATH, SHLIB_PATH, and others. These type of variables are removed from the environment before sudo even begins execution and, as such, it is not possible for sudo to preserve them.

Your easiest option is probably to do:

sudo LD_LIBRARY_PATH=/mnt/sda1/openssl ./a.out

Getting "cannot open shared object file" even though ldd shows it can find it

1 Answers1