Skip to content

Fixing the ELF interpreter - No such file or directory#

Correcting your own binaries

This is offered as an howto for correcting your own binaries. If you find this issue with a software provided by SCITAS write us a ticket so we can analyze the situation and install a newer version of the program, if possible.

FlexLM issues#

After the upgrade from RHEL8 to RHEL9 we noticed an issue with lmutil, a program used to verify license use for codes using FlexLM. The program would seemingly complain the file was not there, but the file could be found by other methods:

$ lmutil
-bash: /path/to/lmutil: No such file or directory
$ ls -l $(which lmutil)
-rwxr-xr-x 1 <user>   <group>   1280760 Aug 17  2023 /path/to/lmutil

This was the first example of a more general trend. The key information about the issue came from the command file: 

$ file $(which lmutil)
/path/to/lmutil: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
  interpreter /lib64/ld-lsb-x86-64.so.3, for GNU/Linux 2.6.18, stripped

The output tells us lmutil is a 64-bit executable, compiled for the right architecture, but the interpreter is /lib64/ld-lsb-x86-64.so.3. This library is currently not available on RHEL9 and the original No such file or directory error relates to it. As of today, only /lib64/ld-linux-x86-64.so.2 exists on RHEL9.

Fixing the problem#

Since this concerns precompiled files, likely from a commercial product, you may not be able to completely correct the issue. You can however work around it by either:

  1. Patching the binary
  2. Making a script that uses the existing library to read the binary

At SCITAS we opted for solution 1 but you can opt for either.

Patching the binary#

The easiest option to avoid the issue is by using the patchelf utility which will change the hardcoded path to the interpreter. In RHEL 9, as mentioned earlier, the standard interpreter can be found at /lib64/ld-linux-x86-64.so.2.

Keep a backup of important files

We strongly suggest backing up important files before doing any changes that might affect their behavior. That is why we start with making a copy of the file.

The process to patch the file is very simple: 

$ cp /path/to/lmutil /path/to/lmutil.bak
$ patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 /path/to/lmutil

If everything went well, your binary should now use the new interpreter. This can be verified by running the command file as described above or alternatively the readelf command. This will give us the needed output: 

$ readelf -l /path/to/lmutil | grep interprer
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

At this point your binary should have its normal functionality restored.

Making a script to run the binary#

The process described above works fine if you have only one or two files that need to be changed. If, on the other hand, you have many files within one code or several, this alternative may suit you best.

The first step to understand what the script will do is to realize that the simplest way to run the problematic binary from above is actually /lib64/ld-linux-x86-64.so.2 /path/to/lmutil i.e. telling the RHEL9 intepreter to execute the binary (instead of letting the binary choose the interpreter on its own).

As such, if you have an executable script in your $PATH called for instance set_interpreter.sh with a form like: 

#!/bin/bash

INTERPRETER=/lib64/ld-linux-x86-64.so.2
$INTERPRETER $@

you can then run set_interpreter.sh /path/to/my/binary <my options> and easily change between problematic binaries without having to patch them all or remember what is the path to the interpreter.