glibcのソースコードをダウンロードし、標準ライブラリの一部をLD_PRELOAD変更してから、その変更された標準ライブラリ（.soファイルの形式）をプログラムで使用していました。しかし、その.soファイルを別のコンピューターにコピーし、そこで同じプログラムを実行しようとするとLD_PRELOAD、セグメンテーション違反が発生しました。
両方のコンピューターにx86-64プロセッサーが搭載されていることに注意してください。さらに、両方のコンピューターにgcc4.4がインストールされています。実行されていないコンピュータには、gcc4.4の他にgcc4.1.2もインストールされていますが。ただし、一方はUbuntu 10.04（コンパイルした場所）を実行しており、もう一方はCentOS 5を実行しています。これがセグメンテーション違反の原因ですか？どうすればこの問題を解決できますか？CentOS5を搭載したコンピューターの管理者権限がないことに注意してください。
C ライブラリを LD_PRELOAD すると、デフォルトの C ライブラリに加えてロードしていると思います。それらがまったく同じバージョンである場合、すべてのシンボルが一致し、あなたのシンボルが優先されます。それでうまくいきます。それらが異なるバージョンである場合、シンボルごとに混在している可能性があります。
また、NSS (ネーム サービス スイッチ、たとえば /etc/nsswitch.conf からのすべてのもの) APIは安定していません。これらのモジュールは、メインの libc.so とは別のものですが、たとえばプログラムがユーザー ID からユーザー名へのマッピングを行うときに動的にロードされます。(libc.so をコピーしたために) 間違ったバージョンをロードすると、あらゆる種類の悪いことが起こります。
さらに、Ubuntu は eglibc と CentOS glibc を使用している可能性があります。したがって、glibc の別のフォークを見ている可能性があります。
LD_PRELOAD ライブラリに、実際にオーバーライドする必要があるシンボルのみが含まれていて、それらを可能な限り最小限にオーバーライドした場合 (たとえば、可能であれば、オーバーライドされた関数を呼び出す)、ライブラリは移植可能になる可能性がはるかに高くなります。
これを行う方法の例については、(たとえば) fakerootを参照してください。
libc の大部分を変更して、すべてをオーバーライドするしか選択肢がない場合は、(a) 非常に奇妙なことをしています。LD_LIBRARY_PATH(b) おそらく、 ではなくを使用したいでしょうLD_PRELOAD。詳細については、ld.so(8) マンページを参照してください。
libc がカーネル バージョン間で移植可能でない可能性があります。