The error 'libssl.so.3: not an open shared object file' typically indicates a corrupted library file or an incompatible architecture rather than a simple missing file. To resolve this, verify the integrity of your OpenSSL installation, ensure you are linking against the correct version (1.1.1 vs 3.0+), and clean your build environment before recompiling with explicit paths to the valid shared objects.
Understanding the Error Message
When the linker or dynamic loader encounters libssl.so.3, it expects a valid ELF shared object. The specific message "not an open shared object file" (often appearing as "not an open shared object" or similar variations depending on the OS) suggests that the file exists at the specified path but is unreadable, corrupted, or has incorrect permissions. It does not always mean the file is absent; sometimes it means the file is zero bytes, contains garbage data, or is from a completely different CPU architecture.
This issue frequently arises during compilation when the build system finds a stale or partially downloaded library in the cache or system directory. If you recently upgraded your operating system or switched compiler versions, the ABI compatibility might have changed, causing the loader to reject the existing binary. Additionally, if you are cross-compiling, you might be accidentally pointing to the host system's libraries instead of the target sysroot.
Checking File Integrity
First, determine if the file is actually present and readable. Use the file command to inspect the header of the library. Run the following command in your terminal:
file /path/to/libssl.so.3If the output says "data" or "empty," the file is corrupted. If it shows a different architecture (e.g., x86_64 when you are building for ARM), it is incompatible. If the file does not exist, the error message might be misleading due to symlinks, so check the symlink chain using ls -l.
Clean Build Environment
A common cause for this error is leftover artifacts from a previous failed build. The Makefile or CMake configuration may reference old object files or libraries that no longer match the current source code. Before attempting to recompile, you must perform a thorough cleanup.
- Navigate to your OpenSSL source directory.
- Run
make distcleanto remove all generated files, including libraries and object files. This is more aggressive thanmake clean. - Remove any temporary build directories created by CMake or other tools.
- Verify that no stray
libssl.so*files remain in your local build output directory.
This step ensures that the build system starts fresh and does not attempt to link against potentially broken cached binaries. If you are using a package manager like yum or apt to install development headers, ensure they are fully installed and not partially configured.
Verifying Library Paths and Symlinks
Modern Linux distributions often use multi-lib configurations where both 32-bit and 64-bit libraries coexist. Ensure that your linker is picking up the correct version. Check your LD_LIBRARY_PATH environment variable. If it points to a directory containing a corrupted or mismatched libssl.so.3, the linker will fail.
echo $LD_LIBRARY_PATHIf you see paths that do not correspond to your intended OpenSSL installation, unset them temporarily for the build process. You can also explicitly tell the linker where to find the libraries by passing flags such as -L/usr/local/openssl/lib during the configuration stage. Always verify that the symlinks libssl.so point to libssl.so.3 and not to a broken alternate link.
Recompiling with Explicit Configuration
Once the environment is clean and verified, reconfigure OpenSSL. Specify the prefix and ensure that the shared library flag is enabled. For example:
./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl shared zlibAfter configuration, run make followed by make test. If the tests pass, proceed with make install. This process generates new, valid shared objects in the target directory. Update your system's dynamic linker cache by running ldconfig if you installed to a standard system path.
If you are compiling dependent software like Nginx, ensure it is linked against this newly built version. Refer to our guide on troubleshooting Nginx compilation errors if you encounter subsequent makefile issues after fixing OpenSSL. Similarly, if you are dealing with OpenSSH, check for version mismatches as described in our article on fixing OpenSSL version mismatches in OpenSSH.
Alternative: Using System Packages
If compiling from source continues to fail, consider using the distribution's package manager. On Debian/Ubuntu, install libssl-dev. On RHEL/CentOS, install openssl-devel. These packages provide pre-compiled, tested libraries that are guaranteed to work with the system's kernel and other dependencies. This approach bypasses the complexity of manual compilation and avoids local corruption issues entirely.
Frequently Asked Questions
Why does the file exist but still throw an error?
The file may be corrupted, zero-sized, or have incorrect permissions that prevent the linker from reading its header. It could also be a symlink pointing to a non-existent target or a file from an incompatible CPU architecture.
How do I fix permission denied errors on libssl.so.3?
Ensure the library file has read permissions for the user running the build. You can fix this by running chmod 644 /path/to/libssl.so.3 and ensuring the parent directory is executable (chmod 755) for traversal.
Should I use static or shared libraries for OpenSSL?
Shared libraries are generally preferred for flexibility and smaller binary sizes, but static libraries can avoid runtime dependency issues. If you choose static, link with -static and ensure you include libcrypto.a as well, since libssl depends on it.
What causes architecture mismatch errors with libssl?
This happens when you mix 32-bit and 64-bit toolchains or libraries. Ensure your compiler, linker, and the OpenSSL library you are linking against are all built for the same target architecture, such as x86_64 or aarch64.
Can I ignore this error and continue compilation?
No, ignoring this error will result in a binary that cannot load at runtime. The application will crash immediately upon starting because the dynamic linker cannot map the invalid shared object into memory.