1
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 を含むカスタムライブラリパスを使用するよりクリーンな方法を知っている人はいますか?