readelf: Usage, Options & Common CI Errors

readelf prints the structure of ELF files: headers, segments, sections, and dynamic info.

readelf is the authoritative ELF inspector. In CI it answers "which shared libraries does this need?" (DT_NEEDED) and "what RPATH is baked in?", the two questions behind most "cannot open shared object file" runtime failures.

What it does

readelf displays information about ELF format object files: the ELF header (-h), program/segment headers (-l), section headers (-S), the dynamic section (-d), and symbols (-s). Unlike objdump it is ELF-specific and does not rely on libbfd, so it works even on unusual targets.

Common usage

Terminal

readelf -h app                     # ELF header (arch, type)
readelf -d app | grep NEEDED       # required shared libraries
readelf -d app | grep -E 'RPATH|RUNPATH'   # baked-in lib paths
readelf -a libfoo.so | less        # everything
readelf -s app | grep -i func      # symbol table

Options

Flag	What it does
-h	ELF header (class, machine, type)
-d	Dynamic section (NEEDED, RPATH, SONAME)
-l	Program headers / segments
-S	Section headers
-s	Symbol table
-a	Everything

Common errors in CI

When a binary fails at runtime with "cannot open shared object file", readelf -d <bin> | grep NEEDED lists exactly which .so it wants; check RPATH/RUNPATH in the same output and compare against the install path. A "wrong ELF class: ELFCLASS32" or arch mismatch shows in readelf -h (Machine/Class lines) - the object was built for a different target. readelf has no "file format not recognized" libbfd dependency, so it works where objdump fails on exotic targets.