web-dev-qa-db-ja.com

glibc-2.23をローカルにインストールすると、すべてのプログラムでsegfaultが発生する

Rootアクセス権がないシステムでglibcをアップグレードしようとしています。したがって、ローカルプレフィックスにインストールしています。これを設定するためのベストプラクティスを理解したり、特定の問題を解決したりするのに役立ちます。 （私の問題の簡単な要約：新しくインストールしたglibc libパスをLD_LIBRARY_PATHに含めると、ls、vim、pwdなどのsegfaultなど、実行しようとしたすべてのプログラム。）

背景情報：

$ uname -a
Linux 3.13.0-68-generic #111-Ubuntu SMP Fri Nov 6 18:17:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

コンパイラ/ツールチェーン：gcc 5.3.0のソースバージョンからローカルでコンパイルおよびインストールされています。正常に動作するようです。これは~/toolchains/gcc_5.3.0にインストールされています

$ ls ~/toolchains/gcc_5.3.0
bin  include  lib  lib32  lib64  libexec  share

インストールしようとしています：glibc-2.23のソースから--prefix=~/local/

このマシンにはSudoがありません（これは共有クラスターです。ポリシーでは、カスタマイズが必要な場合は独自のツールチェーンをインストールします）。

$ echo $LD_LIBRARY_PATH
~/toolchains/gcc_5.3.0/lib:~/toolchains/gcc_5.3.0/lib64

システムにインストールされたglibcのバージョンは2.19です。

$ ldd --version
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.7) 2.19

（上と下では、わかりやすくするために、上の絶対パスを〜に置き換えています）

問題：

システムにインストールされたgcc 4.8.4だけでなく、gcc 5.3.0を使用してglibc-2.23をコンパイルおよびインストールできます。 LD_LIBRARY_PATHが上記のように設定されている場合、〜/ local /へのコンパイルとインストールは正常に機能します。ただし、新しいglibcライブラリ（〜/ local/libにインストールされている）を活用するために、現在のLD_LIBRARY_PATHの最後に〜/ local/libを追加しました。

$ echo $LD_LIBRARY_PATH
~/toolchains/gcc_5.3.0/lib:~/toolchains/gcc_5.3.0/lib64:~/local/lib

これを実行するとすぐに、segfaultを実行しようとするすべてのことを行います。 lsもvimも実行できません。 bash印刷の「セグメンテーション違反」だけが表示されます。私はLD_LIBRARY_PATHを変更する必要があります。その後、すべてが再び正常に動作します。

何が起こっているのかを理解するためにgdbやstraceなどを実行することはできません（これらのsegfaultも）。

質問：

  1. ここで何が起こっているかについてのアイデアはありますか？

  2. LD_LIBRARY_PATHのインストールや設定に対する私のアプローチが正しくないと感じています。ローカルにインストールされたgccとローカルにインストールされたglibcのベストプラクティスは何ですか？バージョンをより慎重に一致させる必要がありますか？それぞれの最新の安定したソースを取得しました。

  3. 将来の私の知識として、gdbが機能しない場合、segfaultが発生している場所を正確に特定できるように、この種のことをデバッグする他の方法はありますか？

ご意見、ありがとうございました。

編集：私は通常、システム上で更新されたツールセットを取得し、必要な開発ヘッダーやライブラリなどを取得しようとしています。たとえば、perf_eventsのいくつかの高度な機能を使用するには、いくつか必要ですlibauditなど、他のものの。もちろん、これにはldapやberkeley dbなどが必要です。最終的には、より新しいバージョンのglibcでのみ提供されるように見えるいくつかのヘッダーが必要になります。たとえば、berkeley dbをコンパイルしようとしたときに表示されるエラーは次のとおりです。このタイプは、glibcのヘッダーであるdirent.hで定義されているようですが、システムにインストールされているパッケージでこのタイプが見つかりません。

 -fPIC -DPIC -o .libs/os_dir.o

../src/os/os_dir.c: In function '__os_dirlist':

../src/os/os_dir.c:45:2: error: unknown type name 'DIR'

  DIR *dirp;

  ^

私のシステムがそれ自体では見つけられない、開発ヘッダーとライブラリへのアクセスを取得するための代替アプローチがあるかどうか知りたいです。上記のDIRに関するエラーは、おそらく良い例です。

linuxglibc
6
Kulluk007

Ld-linux-x86-64.so.2（man ld.so）とlibc.soの不一致のため。

LD_LIBRARY_PATH設定でgdbを実行する場合は、次のように実行します。

export LD_LIBRARY_PATH=~/local/lib
/lib64/ld-linux-x86-64.so.2 --library-path /lib64 /usr/bin/gdb /bin/ls

これにより、古いライブラリ環境では/ usr/bin/gdbが実行され、新しいライブラリ環境では/ bin/lsが実行されます。同様に、次のように新しいライブラリ環境で実行できるコマンドは1つだけです。

export LD_LIBRARY_PATH=~/local/lib
~/local/lib/ld-linux-x86-64.so.2 /bin/echo
6
masm