コンテキストは次のとおりです。私のOSでは（すでに）liba.so.v2関数のシンボルバージョンとして文字列 "symbol_version-2" を含む "liba"。functionX@version-2（私の場合、例えば@NCURSES6_5.0.19991023 更新 存在するobjdump -T /readelf出力）。これは鳥です。バイナリ_aダウンロードして実行してみたかったです。ただし、これは以前のバージョンのライブラリに依存しているためliba.so.v1、 "symbol_version-1"などのさまざまなシンボルバージョン文字列が含まれています（私の場合wrefresh@NCURSES_5.0.19991023（抜けた「6」に注意してください）。
メモ:
- これらの関数（すべて）はsoライブラリに存在し、新しいライブラリは次のとおりです。確立されたld.so経由（使用法の確認
LD_DEBUG=libs ldd ./binary_a） - 残念ながら、バイナリには「新しい」シンボルへの参照はありません。そうでなければ、バイナリを16進数で編集して調整するのは簡単です。vna_flags（下のNewAppsOnOldGlibcリンクを参照）
私の質問は次のとおりです
- 新しいライブラリで新しいシンボルを参照するなど、バイナリをパッチする方法- 特別なツール（objcopy / elfedit、その他...？）または16進編集を使用してください。後者の場合は、ハッシュを再計算する方法に関する段階的なアドバイスが必要です（必要に応じて次のものに基づいています）。協会必要なようです）。詳細は十分に見えます。ダイナミックテーブルハッシュしかし、提供された情報が複雑すぎるため、私のユースケースでは実際には使用できません。
- なぜ？ld.so （まだ）以前のlib.soと以前のシンボルへのすべての参照を16進数で編集した後でも、「バージョンが見つかりません」と文句を言いますか？ld.soのキャッシュにどのような干渉がありますか？
すべての試みでファイルをパッチした後、ldd（実際にはld.so）が新しいシンボルバージョンを見つけることができないと文句を言いました。
理想的な解決策は、（再）コンパイルを避けることです（例：バイナリ_a）、前のリンクのように「ダミー」関数がコンパイルされていない限り、LD_PRELOADs変数を使用しないでください。
私が試したこと：
- 私のテストではパヘルフ、フラグ付きの破損したバイナリを生成しました。--必要なliba.so.v2を削除します。;使用patchelf --必要な liba.so.v2 liba.so.v1 を交換します。ファイルの「物理的」レイアウトを並べ替えますが（hexeditと見なされると）、シンボルはまだv2 so libを参照しているため、このオプションが期待どおりに機能しているかどうか疑われます。より多くの情報を追加するには：これパッチで。バイナリの「再配列」と呼ばれるようですpatchelf - デバッグ 他の行の中には次のようなものがあります。
shifting new PT_LOAD segment by %d bytes to work around a Linux kernel bug - 試験用子供の妖精バイナリの読み込み中に別のエラーが発生しました。私の前にエラーがあったわけではありませんが、「elfヘッダーAMD64-x64が認識されません」
- 別のバイナリを「16進編集」するときのシンボルバージョンは、同じ文字列の長さ（この場合とは異なり、バージョン文字列の長さには1文字の違いがあります） - したがって、より単純な場合 - doLDD結果のバイナリはまだ「symbol_version-2」が見つからないと文句を言います。新しいエントリ（「symbol_version-2」）を追加したいです。.dynstrテーブルは実行可能ではありません（つまり、バイナリをデコンパイルせずに）。そうですか？これが可能なら、私は単にvna_flags現場で Elfxx_Vino「古い」記号に対応するエントリは、「symbol_version-2」であるこの新しい文字列のオフセット（.dynstrテーブル）です。既存のGlibcの上に新しいアプリが追加されました。
次のヘルプ - (a) 変更ソナムlib.so.v2ファイル（使用patchelf --set-sonameまたは類似）内で（b）の名前を変更します。library.so.v2ファイルを送信するlibrary.so.v1 （c）バージョン名の変更（文字列）ただ？もう一度尋ねます。どうすれば不正行為をしますか？ld.soバイナリの手動修正を受け入れますか？
助けてくれてありがとう！