ld-linux.soハックで代替libcを使用します。クリーナーメソッド？

私は非常に古いglibcを備えたレガシーシステムを持っています。これは、膨大なテスト/検証作業を行わなければアップグレードできません。

そのシステム上で新しいプログラム（Java 1.7など）を数回実行する必要がありました。私は、必要なすべてのライブラリをパッケージ化し、chrootでサービスを実行するchrootソリューションを選択しました。

ただし、chrootは非常に制限されているため、LD_LIBRARY_PATHの問題を解決したいと考えています。残念なことに、私はそれlibc.so.6: cannot handle TLS dataを試みるときにエラーを受け取ります。

/lib/ld-linux.so.2chrootからも必要であることがわかりました。これは動作します：

LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program

ただし、ライブラリのロード元を決定するためにjava検査/proc/self/cmdlineすることにより、私のトリックを阻止します。バイナリの名前が「bin / java」でない場合は失敗します。また、起動時にjava自体が実行されるため、問題がさらに複雑になります。

この作業を行う最後の試みとして、Javaバイナリを16進エディタで開き、文字列/lib/ld-linux.so.2を/home/chroot/ld.so（にシンボリックリンクしましたld-linux.so.2）に置き換えました。

しかし、すべての新しいバイナリのパスをネストされたシステムの絶対パスに書き換えるのは非常に面倒だと誰もが同意すると思います。

カスタムld-linux.so を含むカスタムライブラリパスを使用するよりクリーンな方法を知っている人はいますか？

dynamic-linking glibc patchelf

— データレス
ソース

ローダーへのパスは、16進エディターで検出したバイナリにコンパイルされます。あなたが実際に編集したバイナリが直接両方のために働いていたことを幸運/lib/ld-linux.so.2と/home/chroot/ld.so同じ長さです。これらの文字列の長さもバイナリであり、文字列を直接変更すると微妙な問題が発生する可能性があります。

最終的にルートに行く場合は、patchelfのようなものを見てインタープリターを更新する必要があります。これにより、インタープリターを迅速かつ安全に永続的に変更できます。

— gmjosack
ソース

運が悪かったので、バイトをシフトしないようにする必要があることはわかっていました;-)しかし、patchelfは私が望むもののように見えます。相対パスを使用できないことに加えて、使用しているLD_LIBRARY_PATHも処理できるため、ラッパーは必要ありません。私はそれをテストする機会を得たらすぐに答えを信用します。

— データレス14

できます！これにより、このサーバーでnew-libcプログラムとold-libcプログラムを混合するための適切な道が開けます。将来の読者のために、コマンドはでした

patchelf --set-interpreter $JAVA/lib/ld-linux.so.2 --set-rpath $JAVA/lib:$JAVA/lib/i386:$JAVA/lib/i386/jli $JAVA/bin/java

。$ JAVAはJREのディレクトリであり、すべての依存ライブラリを切り上げてlib/JREのディレクトリに配置しました。

— データレス14

@datalessよく私はまだ、このlibjvm.soを回避するためにLD_LIBRARY_PATHを必要にlibstdc ++ so.6理由：共有オブジェクトファイルを開くことはできません：そのようなファイルやディレクトリを[ルート@ 97245bbe7cc1 tensorflow-javaの]＃。

— アモス

@Amosしばらく経ちましたが、私の場合は、デフォルトがjavaバイナリに由来するため、LD_LIBRARY_PATHはもう必要ありませんでした。しかし、Javaで使用されているすべてのライブラリを見つけて、それらをjava lib dirにコピーしたと言った部分に注意してください。私ldd $JAVA/bin/javaはistを取得していました。libnss.soのような動的なlibcが必要な場合もあります

— データレス