[plamo:19416] Re: S.O.Slibpng.so2を削除してしまった

[KOJIMA]

こじま＠こういう風にいろいろ調べることができるのが PC-UNIX の面白いと
ころ，です(笑)

# Windows な OS だと，最終的な仕組みはブラックボックスだから，さまざま
# な Tips を体系的な知識に組み立てることができないように思っています．

ちと，自分の知識を整理するために書いてみますが :-)

From: "hayasi" <hys@mrh.biglobe.ne.jp>
Subject: [plamo:19413] Re: S.O.S libpng.so2を削除してしまった
Date: Tue, 24 Jun 2003 22:17:47 +0900

> > ところ、すべて修復されていました。なぜか狐につまれたみたいで。
> > でも、ほっと一息ついてます。
> >
> 間違って消しても　自分で古いバージョンのライブラリーを読むようにしてても
> 再起動したら　新しいバージョンを読むように自動で設定されるみたい。(実験しま
> した)
> (これで藤野さんの修復　私の上の疑問も解消です)
> 
> ならば　故意に古いバージョンを読む設定を　再起動しても有効にするには？
> 単純、強引には　新しいバージョンを削除する。
> しかし　それでは便利悪い。
> 名前を変える、、、新しいバージョンだとパソコンに気付かれない名前に、、、
> 全然関係なさそうな場所に移動してみる、、、、など　今後　実験してみます。

調べてみる手掛りは ldconfig ですね．

多少，バックグラウンド的な説明をしておくと，，，

・昔々，それぞれのコマンド(プログラム)は必要な機能を全て自分の中で用意
  していた

・しかし，画面に文字を出力する機能とか，ファイルからデータを読み出す機
  能のように，ほとんどのコマンド(プログラム)に共通する機能が多数あるた
  め，そういう共通する機能をまとめて「ライブラリ」として別途提供するよ
  うになった．

・それぞれのコマンドはライブラリの機能を呼び出すことで定型的な機能は簡
  単に使えるようになった．それらのライブラリの機能はコンパイル時にリン
  カが調べて，コマンドの実行ファイルに組み込んでいた(静的リンク(static
  link))．

・上記の場合，コマンドの実行ファイルごとにライブラリの中の必要な機能
  (例えば画面に一文字出力する機能)が組み込まれてしまい，それぞれのコマ
  ンドの実行ファイルはずいぶん大きくなってしまう．そこでライブラリの部
  分はコマンドの実行ファイルに組み込むことを止め，実行ファイルを実際に
  実行した際に必要に応じて組み込むようにした(動的リンク(dynamic link))．
  この結果，それぞれのコマンドの実行ファイルは，本当にそれぞれのコマン
  ド(プログラム)に個別の処理をする部分だけになって，サイズがずいぶん小
  さくなった．

という経緯があります．

# linux 的に言うと，最後の段階でもう一つ a.out から ELF へ，という話も
# あるんだけど，そのヘンは省略

この動的リンクの機能を提供しているライブラリが /usr/lib/libXXX.so とい
う共有ライブラリ(shared library)です．

# 多分，so は shared object の略

/usr/lib/libXXX.so は，上述のようにライブラリとして一連の機能を提供し
ていますが，ライブラリとして開発が進むにつれて異なるバージョンのものが
生れてくることがあります．しかしながら，それぞれのコマンド(プログラム) 
の側から見ると，ライブラリの細かいバージョンの違いはそれほど問題ではな
く，そのライブラリの提供してくれる機能(例えば PNG ファイルを展開する機
能)が使えればいい，という要求があります．それらを調整するため，ライブ
ラリの実体は /usr/lib/libpng.so.2.1.0.6 という風に細かいバージョン番号
を付けるけれど，実際にコマンド(プログラム)が参照するライブラリはその実
体へのシンボリックリンクにしておいて，細かなバージョンの違いはコマンド
(プログラム)へ見せないようにする，という方法が取られるようになりました．

例えば，ちょっと古い Plamo な環境の libpng を見てみると，

kojima@athlon[~]% ls -l /usr/lib/libpng*
-rw-r--r--    1 root     root       224418  7月  1日 2000年 /usr/lib/libpng.a
lrwxrwxrwx    1 root     root           11  9月  1日 2002年 /usr/lib/libpng.so -> libpng.so.2*
lrwxrwxrwx    1 root     root           17  9月  1日 2002年 /usr/lib/libpng.so.2 -> libpng.so.2.1.0.6*
-rwxr-xr-x    1 root     root       217137  7月  1日 2000年 /usr/lib/libpng.so.2.1.0.6*
ko

という風になっていて，libpng の実体は libpng.so.2.1.0.6 であり，それに
対して libpng.so.2 と libpng.so というリンクを張って，libpng のバージョ
ン 2 の機能を明示的に必要とするコマンド(プログラム)は libpng.so.2 を，
libpng ならバージョンを気にしなくてもいいコマンド(プログラム)は 
libpng.so を，それぞれ参照すればいいようになっています．

この libpng.so.2.1.0.6 <- libpng.so.2 <- libpng.so というリンクは手動
で張ることもできますが，イチイチ手作業でやるのも面倒なので ldconfig と
いうコマンドが用意されており，このコマンドを実行すると自動的に必要なシ
ンボリックリンクをそれぞれの共有ライブラリに対して作成してくれます．

一般の Linux では，起動時のスクリプトの中で ldconfig コマンドを実行す
るようになっているので，libpng.so.2 -> libpng.so.2.1.0.6 というリンク
が存在しない場合でも再起動して ldconfig コマンドを実行すれば，このリン
クは再現されて必要なライブラリを参照できるようになる，というわけです．

# ですから，手動で ldconfig コマンドを叩いてもリンクは回復したと思われ
# ます．

この ldconfig は，自身の中で共有ライブラリのありそうな場所(/lib とか 
/usr/lib)は知っていますが，そういう標準的な場所以外に共有ライブラリを
置いた場合は，その位置を教えてやらなければなりません．そのための設定ファ
イルが /etc/ld.so.conf になっています．

ちなみに，共有ライブラリという考え方を使えば，それぞれのコマンド(プロ
グラム)のサイズはずいぶん小さくなって HDD 的には助かりますが，そのコマ
ンドを実行する際に，コマンド本体だけではなく，共有ライブラリと共有ライ
ブラリへ結びつける動的ローダー(ld-linux.so)が必要となるため，HDD がク
ラッシュするなどしてそれらが使えなくなった場合のために static link な
コマンドを用意していることもあります．Plamo の場合， /bin/bash-static 
とか，/bin/tar.static， /sbin/sln といったものが static link なコマン
ドになっており，このヘンの限られたコマンドだけでいかにクラッシュしたシ
ステムを修復するかが，昔は root の腕の見せどころだったりしました :-)

# ls 代りの echo * とか．まぁ，最近はインストーラでも vi が使えたりす
# るので，無理してシングルモードで立ちあげたりしなくても CD boot で作
# 業ができるから，ほとんどこの手のテクニックは必要無くなっていますが，，

ふと思うと，「共有ライブラリ」という考え方が生れたころは HDD のスペー
スが重要だったり，HDD からそれぞれのコマンドを読み込むための時間が結構
長くかかったり，という外的要因があったんだけど，最近みたいに高速な HDD 
が無尽蔵に使えるようになってきたら，「共有ライブラリ」という考え方はむ
しろデメリットの方が大きいのかも知れないなぁ，，

-------
こじま