Knowledgebase

Overview

If you’re seeing messages like:

/sbin/ldconfig: File /lib64/libodbc.so.2 is empty, not checked.
/sbin/ldconfig: File /lib64/libltdl.so.7 is empty, not checked.

— it usually means one or more shared library files in /lib64 are completely empty (0 bytes). That’s not normal. These libraries are essential for running various software, and if they’re missing or empty, it can cause system errors, crashes, or software that simply won’t start.

This guide will help you track down the problem and fix it properly.

What This Affects

• AlmaLinux 8 systems (confirmed on 8.10)

• Any setup where shared libraries in /lib64 are unexpectedly empty

• Applications like PHP, ODBC drivers, and others relying on those libraries

Symptoms to Watch For

• Errors from ldconfig saying certain .so files are “empty, not checked”

• PHP segfaults, applications crashing, or services failing to start

• Reinstalling just one package doesn’t fix everything

Step 1 – Find the Broken Files

Run this to find any empty shared libraries:

find /lib64 -type f -size 0 -name 'lib*.so*'

These are the files that are causing trouble. They’re supposed to be compiled binary files — not zero bytes.

Step 2 – See Which RPM Package Owns Each One

To check one specific file:

rpm -qf /lib64/libodbc.so.2

If you’ve got several broken ones, here’s a way to check them all:

find /lib64 -type f -size 0 -name 'lib*.so*' | while read file; do
    rpm -qf "$file"
done | sort -u

This will list the packages that need to be reinstalled.

Step 3 – Reinstall the Affected Packages

Here’s a simple script to reinstall all the packages that own broken .so files:

find /lib64 -type f -size 0 -name 'lib*.so*' | while read file; do
    rpm -qf "$file"
done | sort -u | grep -v "not owned" | while read pkg; do
    echo "Reinstalling $pkg..."
    dnf reinstall -y "$pkg"
done

If some files aren’t owned by any package, they were probably placed there manually. In that case, you’ll need to replace them yourself or figure out what software originally provided them.

Step 4 – If Reinstall Doesn’t Work

Sometimes DNF gets stuck with a bad cache. If your reinstall didn’t fix the files, try this:

dnf clean all
dnf reinstall -y <affected-package-name>

Replace <affected-package-name> with the ones from earlier.

Step 5 – Check That It’s Fixed

After reinstalling, check a few of the problem files:

ls -lh /lib64/libodbc.so.2

You should see a non-zero file size now. Then run:

ldconfig

There should be no more “empty” errors in the output.

Extra: Check Your Disk and Memory

If multiple libraries were corrupted or you're seeing PHP segfaults in dmesg, it's smart to rule out hardware issues.

Check for kernel-level errors:

dmesg | grep -i error

Check your drive health:

smartctl -a /dev/nvme0n1
smartctl -a /dev/nvme1n1

Check the filesystem (safe, read-only):

fsck -n /dev/md3

Or to do a full check at next boot:

touch /forcefsck
reboot

Final Thoughts

If you’re seeing errors about empty .so files, something likely went wrong during a package install, upgrade, or a disk write. Reinstalling the right packages usually resolves it, but if problems keep coming back, it’s worth taking a closer look at your storage or memory.

If you're unsure what installed the broken files in the first place, or you're still seeing application crashes after reinstalling libraries, dig deeper into logs or try reinstalling the app itself (e.g. PHP, httpd, etc.).

Let us know if you need help identifying packages or restoring files that weren’t managed by RPM.