[plamo:20251] Re: OS-Versionとプログラムの互換性

[KOJIMA Mitsuhiro]

From: "H.Shiozaki" <sios_hs@yahoo.co.jp>
Subject: [plamo:20244] Re: OS-Versionとプログラムの互換性
Date: Thu, 14 Aug 2003 02:11:32 +0900

>   上記は，シンボルタイプの種類については，全てのサンプルです。
>   LIBC_2.0 は，複数個有り，LIBC_2.1 LIBC_2.13 は，各１箇所だけありました。
>   nm foo-lx22とnm-foo-lx20に付いては，添付ファイルへまとめてあります。
>   > 上記の例だと GLIBC_2.0 以外に GLIBC_2.1.3 を使っている部分があるから，
>   > このバイナリは glibc-2.0.x の環境では動かないことが分ります．
>   そうすると，foo-lx24の場合には，glibc-2.1とGlib-2.1.3が必要で，
>   foo-lx22の場合にはglibc_2.1が必要というご指摘と理解しました。
> 
>   foo-lx20では，GLIBC_x.x　型のシンボルは1つもありませんでした。
> 
>   Linuxのどの（古い）バージョン以降が，Libc-2.1，-2.13　をサポートしているか
> が
>   このソフトの下位互換性のある範囲と言うことになりますか。

うーん，，イマイチ話が通じてないようですが(苦笑)，このあたりは 
libc(glibc2) 側の問題であって，Linux のバージョンに依存する問題ではあ
りません．

# Linux のバージョンに依存しているように見えるのは，当時のバージョンの 
# libc(glibc2) が古いだけ

>   しかし，glibcのバージョンとlibcのバージョンの対応関係を
>   調べる方法を，私目は，分かりません。

libc4, libc5, libc6 というのは Linux が使う共有ライブラリの形式に対す
る呼称であり，glibc2.x というのは，その共有ライブラリを実現するための
実際のコードのバージョンである，と考えればいいのでは．

Linux が使っている共有ライブラリには大きく libc4, libc5, libc6 の 3 種
があります．思いつくままにこれらの特徴をあげてみると．．

・libc4 : glibc1.x や BSD の libc あたりから必要な機能を抜き出してデッ
          チあげたバージョン．バイナリの形式が a.out と呼ばれる古い形
          式になっており，共有ライブラリのメンテが大変だった(事前に使
          うアドレスを登録する必要があった)ので，Linux が広まるにつれ
          早期に形式変更が望まれた

          時代的には カーネル 0.9x 〜 1.0 の頃

・libc5： libc4 同様，glibc1.x と BSD libc あたりの折衷版だが，バイナ
          リの形式を ELF に変更して共有ライブラリを自由に作れるように
          なった．

	  時代的にはカーネル 1.0 〜 1.2 くらいだったと思う

	  実は，glibc 自身は libc4 以前から開発が進んでいたが，当初は 
	  GNU のカーネル(HURD)を前提に開発されていたため，Linux にとっ
	  ての必要な機能が不足していたり，開発速度が遅かったので，
	  Linux の開発者が別途ライブラリをデッチあげたらしい．

・libc6: そろそろ熟成してきた glibc2.x を採用した共有ライブラリ．glibc 
         のバージョンとしては glibc-2.0.x から最近の 2.3.x あたりまで
         複数のバージョンが存在するが，共有ライブラリとしては libc6 と
         呼ばれている．

	 libc5 までは(当時の Linux で動かすことが前提のため)ix86 アー
	 キテクチャに依存したコードになっていた．一方 glibc2 は元々マ
	 ルチアーキテクチャ対応になっていたので，ix86 以外のプラット
	 フォームで動かす場合は glibc2(= libc6)が必須となったため，急
	 速に普及が進んだ．

         時代的にはカーネル 1.2 以降

ですから，libc6 というのは，Linux の共有ライブラリの 6 番目の形式
であり，それを実現しているのが glibc2.x である，と言えるでしょう．

念のために書いときますが，nm とかで表示されるシンボル情報

  0804f7c0 B CPU_Clock_Hz
  0804f7bc b rtc_reg_a
  0804f620 D _DYNAMIC
  0804f61c d __FRAME_END__
  0804c924 R _IO_stdin_used
           U __libc_start_main@@GLIBC_2.0
           U fclose@@GLIBC_2.1
  0804f000 W data_start
           w __dso_handle
  0804f778 A __bss_start
  08048b24 T main
  080489fc t init_dummy

は，C コンパイラが出力したコードを元にアセンブラが機械語に変換し，それ
をリンカがまとめる時に付くもので，

           U __libc_start_main@@GLIBC_2.0
           U fclose@@GLIBC_2.1

こういうシンボルは libc6(=glibc2.x)の内部シンボルのうち，特に glibc2 
のバージョン間で互換性が無い機能を使っているため，利用する際にバージョ
ン番号を参照する必要がある場合に生成されるもので，GCC の FAQ には以下
のような下りがあります．

1.17.   What is symbol versioning good for?  Do I need it?

{AJ} Symbol versioning solves problems that are related to interface
changes.  One version of an interface might have been introduced in a
previous version of the GNU C library but the interface or the semantics of
the function has been changed in the meantime.  For binary compatibility
with the old library, a newer library needs to still have the old interface
for old programs.  On the other hand, new programs should use the new
interface.  Symbol versioning is the solution for this problem.  The GNU
libc version 2.1 uses symbol versioning by default if the installed binutils
supports it.

We don't advise building without symbol versioning, since you lose binary
compatibility - forever!  The binary compatibility you lose is not only
against the previous version of the GNU libc (version 2.0) but also against
all future versions.

ですから，この種のシンボルが作成されるのは glibc-2.1 以降ということですね．

>   もっともLinux-2.0xは，（あまりにも）古いので無視するとして，少なくとも，
>   Linux-2.4.19で開発したfoo-lx24が，Linux-2.4.0からLinux-2.4.18の環境で
>   動作するかは，知りたいのです。
>   もし，Linux2.2.xを使っている方が多いならば。
>   Linux-2.2.17で開発したfoo-lx22が，Linux2.2.0からLinux-2.2.16の環境で
>   動作すかも，知りたいのです。
>   OSバージョンがこの間のGLIBCのバージョンを調べるには，
>   各OSをインストールして確認する方法が本来でしょうが，
>   この方法は大変過ぎまので，なにか良い，調べる方法はないものでしょうか？

glibc はセキュリティホール等も見つかってどんどんアップデートされている
(アップデート用の rpm 等が提供されている)ので，どのディストリビューショ
ンのどのバージョンが glibc2 のどのバージョンを使っている，という対応表
を作成するのは意味がないでしょう．

どうしてもバイナリで配布したい，というのあれば static link してしまう
しか無いように思いますが，ソースコードを公開してそれぞれの環境でコンパ
イルしてもらうようにすれば，この手の問題で悩む必要はなくなるのでは？

# 最近は Linux がメジャーになりすぎててこのヘンの感覚がおかしくなって
# るように思うけど，そもそもバイナリの互換性なんてごくごく限られた条件
# の元でしか成立しないものであり，そういうのがイヤだからソースコードを
# 公開したフリーソフトウェアが普及したのだと思うです．

--------
こじま