[Momonga-devel.ja:01214] Re: openssl version up
- From: KOMATSU Shinichiro <koma2@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 10 Jan 2003 01:52:52 +0900
小松です。
長いです。しかも、読みにくいかもしれない(苦笑)。
From: HOSONO Hidetomo <h12o@xxxxxxxx>
Subject: [Momonga-devel.ja:01203] Re: openssl version up
Date: Thu, Jan 09, 2003 at 12:31:26AM JST
> > > 1つ確認ですが、lib{ssl,crypto}.so* の SONAME はどうなりますか？
> > > 現状だと
> > >
> > > RedHat の lib{ssl,crypto}.so* と SONAME が違うため、
> > > openssl に依存してる binary only なソフトが動かない
> > > (Epson kowa の pips の cups 版とか)。
> > >
> > > という問題があるので、何とかしたい/して欲しい と思うのですが。
> >
> > あぁぁぁ、そうだ、それがあった…。SONAMEは0.9.7になっちゃうのです。
> > …RHL8.0のopensslからパッチをひっぺがさなければなりません。
>
> <URL:ftp://ftp.kddlabs.co.jp/10/Linux/RedHat/redhat/linux/8.0/en/os/i386/SRPMS/openssl-0.9.6b-29.src.rpm>
> を取得してSONAMEをチェック(openssl-0.9.6a-soversion.patchを読む)
> したのですが、SONAMEはlibssl.so.2となるようです。
えっと、確認ですけど、
openssl-0.9.7 と 0.9.6b は binary 互換性がなさそうなので
("change API" なんて文字列もいくつか見えたし)、
SONAME が lib{crypto,ssl}.so.2 と＊なってはいけない＊、
というのはいいでしょうか？
合わせるべきは、RedHat がやがて出すであろう(ホント？)
openssl-0.9.7-*.rpm に含まれる lib{crypto,ssl}.so の SONAME です。
それは多分 lib{crypto,ssl}.so.3 となると思われるのですが、
出てみるまでわかりません。
個人的には「0.9.7 が出たからといってすぐに上げる必要があるのか？」
という気がするのですが(RedHat が出すのを待ってもいい気がする)、
上げるというのであれば以下のような方法が考えられます。
1) とりあえず lib{crypto,ssl}.so.0.9.7 という
ファイル名、SONAME にしておく。
2) RedHat が openssl-0.9.7 の rpm を出したら
SONAME を RedHat のものに合わせて変更する。
ファイル名はそのまま。
ちょっと実験してみた(*)結果、
binary を exec() する時には
link している library の SONAME は見ていない(ファイル名しか見てない)
みたいですね。
例えば、libssl.so.0.9.7 という名前のファイルの SONAME が libssl.so.3 で、
libssl.so.0.9.7 という SONAME を持つ library がシステムに存在しなくても、
libssl.so.0.9.7 を link している binary を実行すれば
ちゃんと libssl.so.0.9.7 という名前の library を load してくれるようです。
ファイル名と SONAME が違う時には、ldconfig(8) が
必要な symbolic link を張ってくれます
(上の例だと、libssl.so.3 -> libssl.so.0.9.7 という link を張る)。
(*) 実験の詳細
### libm-2.2.5.so という SONAME を持つ shlib は存在しませんが、
### ムリヤリ作って link されると、実行時には
### /lib/libm-2.2.5.so (SONAME は libm.so.6) が呼ばれる、
### ということを確認する実験です。
% cat > nisemath.c
double cos(double a)
{
return -100. ; /* 正しくない挙動をする cos() を用意 */
}
### libm-2.2.5.so という SONAME を持つ shared library をムリヤリ作る。
% gcc -o libnisemath.so.1 -shared -Wl,-soname=libm-2.2.5.so nisemath.c
% objdump -p libnisemath.so.1 | grep SONAME
SONAME libm-2.2.5.so
### cos() を呼ぶプログラム
% cat > hoge.c
#include <math.h>
#include <stdio.h>
int main()
{
printf("%f\n", cos(1));
return 0;
}
### ムリヤリ作った shlib を link
% gcc hoge.c libnisemath.so.1
% ldd a.out
libm-2.2.5.so => /lib/libm-2.2.5.so (0x40046000)
libc.so.6 => /lib/libc.so.6 (0x00000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
# ちゃんと /lib/libm-2.2.5.so を呼びそう
% ./a.out
0.540302
# 正しい結果を返しているので、
# /lib/libm-2.2.5.so の cos() を呼んでるようだ。
> ## Rawhideは3だったんだけどなぁ(←ほぼ1年前の記憶)。
%changelog を見ると、一旦 openssl-0.9.6c に上がって
その時点で shlib version の方も上がってますね。
なぜかすぐに 0.9.6b に戻されてますが。
＃ binary の互換性確認(本当に SONAME 変える必要があるのかの確認)が
＃ 面倒になったのだろうか。。。？
＃ ちなみに私は changelog を途中まで読んで挫折しました。
> 「openssl に依存してる binary only なソフト」がrequireしている
> lib{ssl,crypto}のバージョン、分かりますか? > koma2
ちゃんと確認せずに書いてたのがバレバレなんですが、
pips は何と lib{crypto,ssl}.so.0.9.6 を link してました。(苦笑)
Kondara で build したんですかねぇ(momonga ということはなさそうだし)。
これだと Vine や turbo で動かないような。。。
＃ こういった、逆パターン(mo で build したものが他の distro で動かない)
＃ も避けたいですね。
--
---------------------------------------
東京大学大学院総合文化研究科
広域科学専攻相関基礎科学系
佐々研究室 博士３年
小松 晋一朗
koma2@xxxxxxxxxxxxxxxxxxxx
koma2@xxxxxxxxxxxxxxxxx
http://kamuy.c.u-tokyo.ac.jp/~koma2/
---------------------------------------