私はここのアドバイスに従いました。
Android関連のプログラムでglibc-2.29について文句を言っています。
すべてがコンパイルされているように見え、新しくインストールされた/optライブラリ内のフォルダをフォルダ内に表示できるようになりました。
$ ls /opt/glibc-2.29/
bin etc include lib libexec sbin share var
ただし、再起動後も元のプログラムは依然としてエラーメッセージを生成します。
.....because /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found
私が考える解決策の最後の行は次のとおりです。
export LD_LIBRARY_PATH="/opt/glibc-2.14/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
Centos 6では動作しますが、Debianでは動作しない可能性があります。再起動後に入力するとenv | grep LD何も見つかりません。履歴を確認して実行する前に、2.14を2.29に変更しました。
私はDebian 10.4 Busterを実行しています。これを行う方法や欠陥を見つける方法についてのアイデアはありますか？
修正する:
必要なプログラムがエラーを取り除く前に、同じ端末ウィンドウからLD_LIBRARY_PATHをエクスポートする最後の行を実行すると、その端末のすべてが終了します。私が入力した内容に関係なく、lsメモリアクセスエラーを返すこともあります。端末を閉じる以外にできることはありません。 Debian は LD パスがこのように変更されるのが本当に好きではないようです。
ベストアンサー1
盲目的にglibcを変更し、すべてがスムーズに動作することを期待することはできません。 2.14を期待するプログラムは2.14を引き続き使用する必要がありますが、2.29を期待するプログラムはそれを有効にすることができます。
これを設定すると、LD_LIBRARY_PATHリンカにライブラリを探す場所を知らせます。 2.29 が 2.14 と同じ場合、リンカは古いプログラムを新しいライブラリに関連付けようとしますが、結果は満足できません。
幸いLD_LIBRARY_PATHなことに、必要な実行可能ファイルのみを設定でき、その後は他の項目には影響しません。
LD_LIBRARY_PATH=/opt/glibc-2.29/lib /path/to/my/program