テストされていない可能な解決策
「共有ライブラリのロード中のエラー：glibc 2.5以降のダイナミックリンカが必要」とは何ですか？
このエラーの原因は、実行するダイナミックバイナリ（またはその依存共有ライブラリの1つ）に.gnu.hashセクションしかないが、ターゲットマシンのld.soが古すぎて.gnu.hashを認識できないことです。古い学校の.hashセクションのみを認識します。
これは通常、問題の動的バイナリが新しいバージョンのGCCを使用してビルドされた場合に発生します。解決策は、-staticコンパイラコマンドラインオプション（静的バイナリを作成するため）または次のオプションのいずれかを使用してコードを再コンパイルすることです。
-Wl,--hash-style=bothこれは、リンクエディタldに.gnu.hashセクションと.hashセクションの両方を作成するように指示します。
ここにあるldのドキュメントによると、古い学校の.hashセクションがデフォルトですが、コンパイラーはそれをオーバーライドできます。たとえば、RHEL（Red Hat Enterprise Linux）Serverリリース5.5のGCC（バージョン4.1.2）には、次の行があります。
$ gcc -dumpspecs .... *link: %{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu %{shared:-shared} .... ^^^^^^^^^^^^^^^^ ...詳細については、こちらを参照してください。
私はすでに同じ問題を抱えていました。コンパイラを使用していない古いマシン用に小さなツール（私が書いたもの）をコンパイルしようとしました。最新のマシンでコンパイルしましたが、バイナリを実行するには少なくともGLIBC2.14が必要でした。
（xxdを使用して）バイナリのダンプを作成することにより、私はこれを見つけました：
....
5f64 736f 5f68 616e 646c 6500 6d65 6d63 _dso_handle.memc
7079 4040 474c 4942 435f 322e 3134 005f py@@GLIBC_2.14._
....
そこで、コード内のmemcpy呼び出しを自家製のmemcpyの呼び出しに置き換えたところ、glibc2.14との依存関係が魔法のように消えました。
申し訳ありませんが、なぜ機能したのか、または変更前に機能しなかったのかを説明できません。
お役に立てば幸いです。
それでは、エレガンスとブルートフォースのバランスを見つけようとして、ターゲットカーネルバージョンに一致するVMをダウンロードし、ライブラリの問題を修正しました。
全体（ダウンロード+ yum install gcc）は30分未満で完了しました。
参照：仮想マシン、カーネルバージョンマッピングテーブル