これを実行しようとすると、すべてのプログラムがすぐにセグメント違反を起こし、システムが壊れてしまいました。 に の新しいバージョンをインストールしたld-linux-x86-64.so.2
が、プログラムがロードされたときに の新しいバージョンではなくの/lib64
古いバージョンが見つかったためだと思います。 (どうやら ld と libc は一致する必要があるようです?)libc.so.6
/lib/x86_64-linux-gnu
/lib64
/lib64
を の先頭に置い/etc/ld.so.conf.d/x86_64-linux-gnu.conf
て を実行してみましたldconfig
。しかし、何らかの理由でこれでは何も解決しませんでした。
答え1
関係のない何かを検索していたときに、偶然にも、私のインストールが古いlibcを採用していた理由を発見しました。新しいlibcのABIバージョンが古いためです(https://stackoverflow.com/questions/20577638/library-path-order-for-alternate-glibc-dynamic-linker-ld-so)。
そこで私はこうしました:
/lib
、、/lib32
およびの内容をバックアップしました/lib64
。検索パスの先頭に
/etc/ld.so.conf.d/x86_64-linux-gnu.conf
配置するように編集しました。/lib64
--prefix=/usr --enable-kernel=2.6.26
古い glibc バージョン (2.13) と一致するように、オプションを使用して新しいバージョンの glibc (2.19) を設定しました。新しい glibc をビルドしました。特に何も起こりませんでした。
私は
su
ルート権限を取得し、 を実行しましたmake install
。インストールが開始されましたが、新しい がld-linux-x86-64.so.2
インストールされた後にセグメント違反が発生し、古い が引き続き取得されていましたlibc.so.6
。これを修正するために、私は実行しました
ldconfig
(もちろん、まだ root として)。インストールを再開しました (
make install
)。 を呼び出したコマンドで再びエラーが発生しましたgcc
。これは、ヘッダーの不一致が原因であることが分かりました。つまり、 では、新しいバージョンではなく/usr/include/stdio.h
古いバージョンが取得されていました。/usr/include/x86_64-linux-gnu/sys/cdefs.h
/usr/include/sys/cdefs.h
そこで、これを修正するために、ディレクトリ を削除し
/usr/include/x86_64-linux-gnu/sys
、 へのシンボリックリンクに置き換えました/usr/include/sys
。また、 のヘッダーa.out.h
、、fpu_control.h
をの新しいバージョンへのシンボリックリンクにieee754.h
置き換えました。/usr/include/x86_64-linux-gnu
/usr/include
再度インストールを再開しました(
make install
)。 最終的に成功しました。
システムを再起動すると、すべてが正常に動作するようになりました。
システムに 64 ビット バージョンと一緒にインストールされている libc の 32 ビット バージョンも更新しようとするとどうなるかはまだわかりません。またすべてがひどく壊れるのではないかと思います。成功したらこの回答を更新します。