`ldd <dynamic_lib>`が "??? => ???"を出力するのはなぜですか（ライブラリと場所の両方に疑問符があります）？
ldd <dynamic_lib>を実行していると、??? => ???を読み取るエントリがいくつかあることに気付きました。 「Linux」、「ldd」、「??? => ???」のさまざまな組み合わせを検索エンジンとこのサイトの両方で検索しても、何も見つかりませんでした。
関連する可能性があります：問題のダイナミックライブラリは、組み込みのGCCスイートを使用してMSYS2のWindows10でコンパイルされました。
lddコマンドは、実行可能ファイルまたはライブラリを、実行/使用したときと同じように、システム内の共有ライブラリにリンクしようとします。指定されたファイルからライブラリ参照を読み取り、ファイルシステムとパス（LD_LIBRARY_PATH）でそれらを見つけようとします。 「???」と表示されている場合は、システム内の一部のライブラリが見つからないことを意味します（また、調べたプログラム/ライブラリが実行されない/使用できない可能性があります）。
あるシステムから別のシステムにファイル（実行可能または共有オブジェクトライブラリ）をコピーすると、ライブラリで問題が発生することがよくあります。その理由は、システムライブラリが異なることです。たとえバージョンによってのみ異なり、それ以外の場合は存在する場合でもです。
場合によっては、不足しているライブラリもコピーして、LD_LIBRARY_PATHに含まれているフォルダに配置することが解決策になります。この目的でその変数を設定するか、コピーしたライブラリファイルをシステムにインストールしたくないために新しいフォルダーを追加することもできます（！）。
元のシステムでlddを実行すると、コピーするライブラリを見つけることができます。
これが独自のプログラムであるか、自分でコンパイルした場合は、実際にはどのライブラリが欠落しているかを知っている可能性があります。
ライブラリを特定したら、それらを個人用フォルダにコピーできます。 ~/libsに。次に、このフォルダをライブラリパスに追加します。
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}":~/libs
変数がすでに存在する場合（echo $LD_LIBRARY_PATHによるテスト）、または
export LD_LIBRARY_PATH=~/libs
そうでない場合（両方ともbashスタイルのシェル構文）。
次に、lddを再試行します。
後で、変数を設定するシェルスクリプトを常に使用して実際のプログラムを開始し、次にプログラムを開始することができます。
MSYS2のWindowsで同じ問題が発生した場合（GCC Suiteを使用して共有ライブラリをコンパイルし、実行可能ファイルをそのライブラリにリンクし、実行時に依存関係が欠落していることを確認）、次のことができます。
- 共有ライブラリを実行可能ファイルと同じディレクトリにコピーします。
- 実行可能ファイルと同じディレクトリから共有ライブラリへのリンク。
- パス環境変数を変更して、共有ライブラリを含むディレクトリを含めます。
MSYS2はWindows上でUnixライクな環境を提供する可能性がありますが、実行時にWindowsが実行可能ファイル（共有ライブラリを含む）を検索する方法を順守する必要があります（つまり、LD_LIBRARY_PATHは無意味であり、リンカーはで提供されるパスを気にしませんrpath; PATHを使用する必要があります）。