A systems administrator has deployed a custom C++ binary called /opt/acme/bin/reportgen on a RHEL 9 development server and created a systemd service for it. When the service is started, journalctl records the following error:
/opt/acme/bin/reportgen: error while loading shared libraries: libxlnt.so.0: cannot open shared object file: No such file or directory
Before installing new packages or modifying LD_LIBRARY_PATH, the administrator wants to confirm exactly which dynamic libraries the program expects and identify any that are unresolved. Which command or technique should the administrator use first?
Use systemctl daemon-reload to force systemd to re-read unit files.
Recompile the application with the -static flag so it no longer relies on shared libraries.
Run ldd /opt/acme/bin/reportgen to list the binary's shared-library dependencies.
Execute dnf reinstall \* to refresh all installed packages.
The ldd utility prints every shared library that an ELF executable or shared object requires and shows not found for any libraries that cannot be resolved on the current system. Running ldd /opt/acme/bin/reportgen will therefore reveal whether libxlnt.so.0 (or any other dependency) is missing and where the loader expects to find it. This directly verifies the dependency issue without changing the system.
Refreshing all packages with dnf reinstall, recompiling with the -static linker flag, or reloading systemd unit files do not inspect the binary's runtime dependencies and may introduce unnecessary changes before the root cause is confirmed.
Ask Bash
Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.
What is the purpose of the ldd command?
Open an interactive chat with Bash
What is LD_LIBRARY_PATH and how does it relate to the error?