|
|
後藤正徳
___________________________________________________________________________________________________________________________
先 ほ ど リ リ ー ス さ れた Debian sarge では 11 ものアーキテクチャをサポートしている。 これら異なるアーキ テ ク チ ャが 同 時 に 使 い 物 に な る た め に は 、 当 然 各 ア ー キ テ ク チ ャ用 バ イ ナ リ を 生 成 す る ツ ー ル チ ェイ ン も十分整備されていなければならない。
本 文 書 で は 、 ツ ー ル チ ェイ ン と は 何 か を簡単に紹介した後、 筆者がメンテナンスしている glibc, linux-kernel-headers パッケージに関して説明を行う。
ツ ー ル チ ェイ ン (toolchain) という用語に正確な定義があるわけではないが、 一般にマシンネイティブなバ イ ナ リ を 生 成 ・加 工 す る た め の 一 連 の ツ ー ル 群 を 指 す こ と が 多 い 。 本 節 で は 、 ま ず Debian での代表的な ツ ー ル チ ェイ ン パ ッケ ー ジ を 紹 介 す る 。
GNU Compiler Collection の略称。 ツールチェインのコアパッケージであり、 ソースコードからアーキテク チ ャ毎 の バ イ ナ リ へ 変 換 す る 役 割 を 持 つ 。 な お 、 gcc 自体はソースコードからアセンブラコードを出力す る ま で の 機 能 し か 持 って お ら ず 、 そ こ か ら 先 の バ イ ナ リ 生 成 部 分 は 後 述 す る binutils のツールを内部で呼 び 出 し て い る 。 現 在 サ ポ ー ト す る プ ロ グ ラ ム 言 語 と し て は C (gcc), C++ (g++), Java (gcj), Fortran (g77, g90) などがある。
Debian パッケージメンテナは Debian-gcc チーム (Matthias Klose, Gerhard Tonn) であるが、 事実上 Matthias (doko) 一人がメンテナンスを担っている。
binutils には、 バイナリを生成・操作するツール群が入っている。 例えば、 gcc によって出力されたアセン ブ ラ コ ー ド を ア セ ン ブ ル し て オ ブ ジ ェク ト コ ー ド 化 す る ア セ ン ブ ラ as、 複数のオブジェクトコードをリン クしてバイナリを生成するリンカ ld、 オブジェクトコードを逆アセンブルしたり解析したりするツール objdump などがある。
Debian パッケージメンテナは James Troup である。 最近では C++ transition for etch に絡んで Matthias Klose が主な実作業にあたっている。 また、 binutils の上流開発者の中で Debian 開発者も兼任 している人物に Daniel Jacobowitz がいる。
glibc は GNU C Library の略称。 gcc, binutils がバイナリを生成するものであるのに対し、 glibc は生成したバイナリ実行時に使用される C 言語ライブラリである。 C 言語の関数やバ イナリ実行時に最初に必要となる初期実行コードなどを含んでいる。 なお、 C ライブラリ は実行環境に依存するため、 システムによっては glibc 以外の libc が使用されることもあ る*11 。
linux-kernel-headers は glibc のうち /usr/include/linux など Linux カーネルソース起源のヘッダを扱 うパッケージである。 元々libc6-dev パッケージにマージされていたが、 ソースが別々であることから 2 つに分離された。
gdb はバイナリ実行時に、 ユーザからデバッグを可能とするための機能を提供する。
Debian パッケージメンテナは上流開発者でもある Daniel Jacobowitz である。
その他のものとして C++ 向けライブラリである libstdc++ などがある。 また、 bfd といったバックエ ンドライブラリや dejagnu といったツール群が存在しているが、 本文書では割愛させて 頂く。
過去をひもとくと、 元々Linux の C ライブラリとしては H. J. Lu を中心に開発されていた libc4, libc5 が使用されていた。 これは GNU C Library バージョン 1 をベースに Linux 向け改良が追加されたものであった。 しかし、 GNU C Library 自体も Roland McGrath, Ulrich Drepper, Andreas Jaeger を中心に別途開発が続けられており、 古い libc5 に代わっ てより新しい現在の glibc バージョン 2 が libc6 として置き換わる移行が行われた (libc6 transition)。
Debian における glibc パッケージは、 当初 Joel Klecker がメンテナンスしていた (1999〜2000)。 しか し Joel が病気で逝去したため、 代って Ben Collins がメンテナンスを開始した (2000〜2002)。 だが、 や がて Ben 自身の興味が薄れて放置されるようになってきたため、 現在のメンバから構成されるメンテナン スチームが組まれた (2002〜)。 その後 Jeff Bailey, Branden Robinson, Daniel Jacobowitz を中心に古い Debian パッケージから debhelper ベースへ完全に書き直され、 同時に linux-kernel-headers パッケージ が libc6-dev パッケージから分離した (2003)。 現在は筆者を中心にメンテナンスが続けられて いる。
パッケージメンテナは Debian-glibc チーム。 構成メンバは以下の通り。
この他にも以下のメンバが活躍している。 移植周り: Bastian Blank、 debian-installer 関連: Colin Watson、 locale: Petter Reinholdtsen, Denis Barbier、 MIPS: Thiemo Seufer, Guido Guenther、 hppa: Carlos O’Donell, amd64: Andreas Jochens, Goswin von Brederlow, ia64: David Mosberger, Randolph Chung, s390: Gerhard Tonn。
開発は主に debian-glibc@lists.debian.org メーリングリストを中心に行われている。 また、 時々IRC にて議論を行って今後の方針などを決定している。 パッケージ管理は元々cvs で行っていたが、 現在は alioth の svn ベースに切り替わっている。 レポジトリは以下の 通り。
本節では、 glibc の各種バイナリパッケージとそれに含まれるファイルを紹介していく。 各ファ イルの解説によって、 glibc がどのような機能を提供しているかの一端が明らかになるだ ろう。
ところで、 パッケージの中には同じ機能を提供しているにも関わらずアーキテクチャによってついてい る 名 前 が 異 な る こ と が あ る 。 具 体 的 に i386 での名前を挙げると libc6, libc6-dev, libc6-dbg, libc6-pic, libc6-prof, libc6-udeb がそうである。 libc6 を例にアーキテクチャとパッケージ名の対応を 表 5に挙げる。 以後では、 一番親しんでいるであろう i386 での名前を使用して説明を進 める。
|
|
C ライブラリとダイナミックローダ等を提供。 Priority: required, Section: base。
sid/i386 では約 9100 バイナリパッケージが依存している Debian のコアパッケージ。 本パッケージは以 下のファイルを含む。
libc のコアとなる動的ライブラリ*12 。 動的ローダ (i386 では /lib/ld-linux.so.2) と libc (i386 では libc.so.6)、 そして周辺ライブラリ (libm, libnss_*, ...) を含む。 スレッドシステム にはカーネル 2.4 でも動作する linuxthreads を採用。
/lib/*.so と同様だが、 TLS (Thread Local Storage) が有効になり、 デフォルトのスレッドシステムが規格により正しく準拠した NPTL (Native Posix Thread Library) になっている。 カーネル 2.6 使用時に は、 デフォルトの /lib/*.so 動的ライブラリに代わってロードされる。
各ライブラリのバージョン番号を指し示すためのシンボリックリンク ファイル。
gconv (各文字コード・エンコーディング毎に用意されているコード変換 iconv モジュール) 動的ライブラリと gconv-modules (エイリアスファ イル)。
pt_chown をインストール。
コンパイル済タイムゾーンデータ。 環境変数 TZ に指定されたタイム ゾーンに応じた時刻を返すために使用される。
各種設定・変換・表示ツール (iconv, locale, localedef, getent, getconf, catchsegv, tzselect, ldd, lddlibc4, zdump, rpcinfo) をインストール。
設定ツール (zic, iconvconfig, tzconfig) をインストール。
動的ライブラリキャッシュファイル作成ツール ldconfig をインストール。
sysfs のためのマウントポイント。 歴史的事情により存在。
64 ビット biarch*13 向 けに作成されている libc6 パッケージ。 Priority: standard, Section: base。
Debian sarge では sparc64, s390x にのみ提供されている。 基本的にパッケージの中身は libc6 パッケー ジと同等であるが、 64 ビット化した動的ライブラリを /lib の代わりに /lib64, /usr/lib64 配下へインス トールする。
アーキテクチャ依存で提供される最適化パッケージ。 Priority: extra, Section: base。
opt パッケージ、 hwcap パッケージとも呼ばれる。 基本的にパッケージの中身は libc6 パッケージと同 等であるが、 例えば libc6-i686 では /lib のかわりに /lib/tls/i686/cmov というディレクト リの下に最適化された動的ライブラリがインストールされる。 この最適化動的ライブラリ は、 アーキテクチャが i686 以上かつカーネルが 2.6 以上でプロセッサに cmov 拡張があ る*14 場 合、 バイナリ実行時に自動的に使用される。 なお libc6-i686 は 686 用に最適化しているだけにとどまら ず、 スレッドサポートが大きく改善されているという重要な特徴がある。
開発向けパッケージ。 Priority: standard, Section: libdevel, Build-Essential。
C, C++ での開発を行うためには必ず必要になる各種ファイルがインストールされる。 本パッケージは 以下のファイルを含む。
ヘッダファイル一式を格納。
gencat, mtrace, rpcgen といった開発用ツールを提供。
libc6 で提供される動的ライブラリのうちのいくつかが静的ライブラリ としてインストールされる。 また、 コンパイル時に必ず静的にリンクさ れるオブジェクトコードが含まれる。
libc6 に含まれる /lib/*.so 動的ライブラリへのシンボリックリンクファ イル。 コンパイル用。
64 ビット biarch 向けに作成されている libc6-dev パッケージ。 Priority: standard, Section: libdevel。
Debian sarge では sparc64, s390x にのみ提供されている。 基本的にパッケージの中身は libc6-dev パッ ケージと同等であるが、 64 ビット化した動的ライブラリを通常とは別パスへインストール する。
デバッグライブラリパッケージ。 Priority: extra, Section: libdevel。
libc6 や libc6-i686 パッケージで提供される動的ライブラリは strip されてシンボル情報が落とされてい るが、 本パッケージで提供される動的ライブラリはシンボル情報も含んだものが/usr/lib/debug 配下にイ ンストールされる。
本パッケージは、 開発時など glibc も含めた gdb デバッグを行う際に使用する。 LD_LIBRARY_PATH 環 境変数に /usr/lib/debug パスを含めてアプリを起動すると利用できる。
プロファイルライブラリパッケージ。 Priority: extra, Section: libdevel。
libc6-dev で提供される静的ライブラリとほぼ同じだが、 プロファイルオプション (-pg) つきでコン パイルされている。 gprof を使ってアプリの性能プロファイリングを行いたいときに利用 する。
国際化機能 “ロケール” 用データを提供するパッケージ。 Priority: standard, Section: base。
Debian で日本語を使いたい場合には必ずインストールされている必要がある。 本パッケージは以下の ファイルを含む。
国際化 (gettext 化) した glibc の出力メッセージデータ (.po)。
ロケールデータのうち文字コードに関するデータ。
ロケールデータのうちロケール情報に関するデータ。
ロケールデータ生成スクリプト。 /etc/locale.gen に基づいてロケール データを生成し/usr/lib/locale へインストールする。
元々locales パッケージには、 コンパイル済のロケールバイナリデータ全てが含まれていたが、 使いもし ないロケール情報にサイズを食われることに強い反対意見があった。 そこで現在は、 各ユーザが charmaps (ja_JP.eucJP の eucJP) と locales (ja_JP.eucJP のうち ja_JP) データを使用してユーザが必 要とする分だけ手元で生成出来るようになっている。 “dpkg-reconfigure locales” によって生成するロケー ルデータを随時設定変更可能。
NSCD (Name Server Cache Daemon) パッケージ。 Priority: optional, Section: admin。
デフォルトで提供される glibc ネームサービススイッチライブラリ (libnss_*) は、 毎回関数を呼び出す 度にネットワークへ問い合わせに行く仕様になっている。 例えば libnss_dns は、 DNS を引くための機能 を提供するが、 DNS を引く関数を呼ぶ度にネームサーバへ通信が発生してしまう。 nscd を 使うと、 ローカルへ問い合わせをキャッシュするので、 その分速度を速めることが可能に なる。
ドキュメントパッケージ。 Priority: optional, Section: doc。
glibc に関するドキュメント (/usr/share/doc/glibc-doc/*) と、 公式マニュアルである info (/usr/share/info/libc.info*)、 そしていくつかのマニュアルページ (/usr/share/man/man3/*) が提供さ れる。
なお、 manpages-dev で提供されるマニュアルページと glibc-doc の info ドキュメントは、 互いに提供 元も内容も異なる全くの別物である。
PIC アーカイブパッケージ。 Priority: extra, Section: libdevel。
元々boot-floppies のために用意されていたパッケージ。 フロッピに入れるには大きすぎる glibc ライブ ラリから必要な関数だけ抽出し、 小さくカスタマイズするために使用する。 現在も debian-installer の mklibs で使用されている。
debian-installer 用 udeb パッケージ。 Priority: extra, Section: debian-installer。
libc6-udeb は debian-installer が動作するために必要な最低限の動的ライブラリのみ含む。 libnss-*-udeb は ssh を動作させるために s390 用に導入されたもので、 フロッピ容量の関係で libc6-udeb から外された動的ライブラリが入る。
linux-kernel-headers は、 libc6-dev とともに C, C++ 開発時に必要となるパッケージである。 ソースは glibc とは異なり Linux カーネルを元にしている。 Priority: standard, Section: devel, 事実上の Build-Essential。
中身のほとんどは Linux カーネルヘッダファイルで構成される。 本パッケージは以下のファイルを 含む。
Linux カーネルソースでいう include/linux ディレクトリにあるヘッダ ファイルをコピーしたもの。 アーキテクチャ非依存。
include/asm-* ディレクトリにあるヘッダファイルをコピーしたもの。 アーキテクチャ依存。
include/asm-generic ディレクトリにあるヘッダファイルをコピーした もの。 アーキテクチャ非依存。
ちなみに、 アーキテクチャによっては 32 ビットと 64 ビットのカーネルヘッダが別々になっているもの がある (sparc, ppc など)。 その場合、 asm に 32 ビットアーキテクチャ用ヘッダだけが入っていると、 64 ビットバイナリをコンパイル出来ないことになってしまう。 そこで、 asm 以下には振り分けのためのダ ミーファイルを入れておき、 コンパイルオプションの #ifdef によって適宜読むファイルを切り替える仕組 みになっている (例を図 2に示す)。
本節では、 ハックの一助になるよう glibc, linux-kernel-headers ソースパッケージの中身を簡単に紹介 する。
glibc ソースパッケージは以下のような構成になっている。 ここでは、 特に重要な役割を持つファイルを取 り上げる。
ソースパッケージ。
.dsc ファイルがなくても .orig.tar.gz からソースを解凍可能にするスク リプト。
control ファイルとその元ファイル control.in/*。 debian/rules control として control.in/* から control ファイルを生成する。
各バイナリパッケージ用 debhelper ファイルの雛形を格納。
locales パッケージで使用する debconf フロントエンド用国際化メッ セージファイル。
Debian ローカルでインストールするファイル (例えばマニュアルや設 定ファイル等) を格納。
Debian ローカルパッチ。 dpatch をベースにした独自のパッチシステム で管理。 最新版では 66 個、 総計 452KB (!) ある。
ルールファイル rules と、 ビルドの各段階に分けてより細かく記述した ルールファイル rules.d/* から成る。
shlib バージョン定義ファイル。
-dbg 生成時用ラッパスクリプト。
ビルド時に各アーキテクチャ依存の情報を切り替えるための Makefile 集。
linux-kernel-headers ソースパッケージは以下のような中身となっている。
アーキテクチャ毎に用意されているデフォルトカーネルコンフィグファ
イル
/usr/include/linux/autoconf.h を格納*15 。
debian ディレクトリ。
Debian ローカルパッチが入っている。 dpatch にて管理。
ia64, parisc 用の特別ファイル。
テストプログラム。 gcc-2.95, gcc-3.3, g++-3.3 に対して -ansi などのフ ラグをチェックしてコンパイルエラーが出ないか調べる。
出自のバージョン番号。 /usr/include/linux/version.h としてインストー ルされる。
なお、 debian/patches 以下には現在 36 個、 総計 61KB 分のローカルパッチが入っている。 これをパッ チ種別毎に分類したものが表 6である。
|
|
libc6 パッケージは、 通常のパッケージと比較して以下の点が大きな違いである。
そこで、 ここでは実際に起きた問題の一つを取り上げ、 メンテナンスにあたって発生する様々な苦労の 一端を紹介したい。
発生した問題
これは glibc 2.3.4-1 を experimental に dupload した時に発生した問題である。
i386 アーキテクチャでは、 libc6 の他に最適化ライブラリ libc6-i686 が用意されている。 カーネル 2.6 + i686 アーキテクチャを使っている場合、 libc6-i686 に入っているとバイナリ実行時 に/lib/tls/i686/cmov 以下の最適化動的ライブラリが優先して使用されることは既に述べた。 この「どの 動的ライブラリをロードするのか」 をバイナリ起動時に実際に判断するのは、 libc6 パッケージに入ってい る動的ローダ ld.so である。
ところが glibc 2.3.4 になってから、 ld.so と libc.so 共通で使用している内部構造体に変更が発生 し、 新旧の libc.so と ld.so を混ぜて使用できなくなってしまった。 これが原因で、 以下の ようなケースに陥ると、 全バイナリがクラッシュして動作しなくなってしまうようになっ た*16 。
状態遷移図の登場
上記のように、 パッケージをインストールしたり削除したりといった状況に応じて、 問題が起きたり起 きなかったりする。 そこで、 結局最後は libc6 や libc6-i686 パッケージのインストール状況毎に応じて状 態遷移図を書いて問題を整理した。 それが、 図 3である。
例えば、 Lo (libc6 2.3.2.ds1) + Po (libc6-i686 2.3.2.ds1) がインストールされている状態 Lo,Po から Ln (libc6 2.3.4) をインストールしようとすると、 色付きの不整合状態 Ln,Po に陥ることが図から読み取 ることができる。
解決策
この図 3に基づき、 インストールや削除、 アップグレードやダウングレードでも問題が発生しないよう に工夫した glibc を作成した。 具体的には、 Debian ローカルパッチで使用可能になっている /etc/ld.so.nohwcap というファイルを場合に応じて制御するというものである。 このファイル が存在すると、 ld.so は最適化ライブラリを使用せず、 libc6 に入っているデフォルトライ ブラリを使うようになる。 つまり、 ld.so と libc.so のバージョンはいつでも一致するよう になってクラッシュしなくなるわけだ。 そこで .preinst/.prerm に手を加え、 インストー ルまたは削除される状態に応じてこのファイルを生成したり削除したりするような変更を 行った。
i386 では、 上記手法によって問題解決することを確認した。 ただし、 sparc 版では同様のテストを行え る環境がないため、 新しい glibc を sid にアップロードすると sparc ユーザによってはシステムクラッ シュが経験できるかもしれない。
glibc, linux-kernel-headers には、 まだまだ様々な作業が積み残されている。 本節では今後 etch にて行わ れる予定の作業のうち、 Debian 全体に与える影響が比較的大きいものをピックアップして紹介し たい。
sarge がリリースするまでには非常に長い年月がかかったため、 主要なツールチェインは全て昔のバー ジョンに塩漬けされた状態になってしまった。 これを取り戻すべく、 etch では最新版を 7 月に次々と投入 予定である。 最近の doko + jbailey + gotom の議論によって、 次の順番でツールチェインを移行してい こうという話になっている。
この移行の中で最も影響が大きいのが gcc 4.0 である。 gcc 4.0 では C++ ABI (Application Binary Interface) や、 いくつかのアーキテクチャ(sparc, mips など) で関数の呼び出し規約に 変更が加わっている。 特に、 C++ ABI 移行では、 C++ を利用する全てのパッケージが 一時的に名前を変えるなどの対処が必要になってくる。 より詳細は以下の URL を参照の こと。
現在の Debian は、 いわゆる 64 ビットの biarch を部分的にサポートしている。 とは言え、 64 ビットをサ ポートするパッケージは libc6 や libncurses など一部のライブラリパッケージのみで、 それも debian/rules でインストール先を /lib から /lib64 に振り分けるといった仕掛けを作り込んで実現して いる。
しかし近年、 amd64 や ppc64 など、 32 ビットと 64 ビットを両方使えるアーキテクチャが 急速に普及してきており、 より簡単に両者のバイナリを扱えるパッケージフレームワーク の整備が求められている。 また、 3 種類以上のアーキテクチャを同時に使える multiarch *17 も可 能にしたいという意見がある。
現時点でどう実装していくのかについて議論はまとまっていないが、 動的ローダに変更を加える可能性 は高い。 より詳細は以下の URL を参照のこと。
Debian sarge は 11 + 1 アーキテクチャにポーティングされているが、 さらにもっと多くのアーキテク チャへポーティングしたいという声がある。
ppc64
現在最もサポートが望まれているのは ppc64 である。 Debian で最初にネイティブ ppc64 の開発作 業を開始したのは amd64 サポートでも中心的な役割を果たした Andreas Jochens であっ た*18 。 その後 debian-powerpc メーリングリストにおける議論で、 ppc64 は amd64 と比較してネイティブサポートのメリットがそれ ほど大きくない*19 た め、 現在は biarch サポートでいく方針に固まりつつある。
sh3, m32r, mips64, parisc64
既にいくつかポーティングされているものもあるが、 積極的にサポートする方向にはなっていない。 sh3 に関しては、 マシンの整備が進めば状況はもう少し良くなると考えている。
locales パッケージの解説で述べたように、 現在コンパイル済ロケールデータはパッケージ として提供されておらず、 ユーザがインストール時に必要なものだけコンパイルするよう になっている。 しかし、 このロケールデータのコンパイルにはかなりのメモリと時間を食 うため、 特に組込み向けシステムでは生成が大変厳しいというバグレポートが報告されて いる。
そこで、 locales パッケージの他に locales-all パッケージを用意し、 コンパイル済ロケールデータをあ ら か じ め 用 意 し て お く こ と で 、 ロ ケ ー ル 生 成 に か か る 時 間 を 節 約 で き る よ う に な る 予 定 で ある。
timezone データは libc6 パッケージに統合されているが、 必ずしも必要なデータではないため、 組込み機 器向けでは libc6 から切離してスリムにしたいという要望がある。 また、 timezone データそのものは glibc 開発者がメンテナンスしているわけではなく、 glibc とは無関係に頻繁に更新されて いる。
そのため、 etch では timezone データを libc6 パッケージから切り離して独立させていく予定である。 これまで安定版では timezone データを更新したくても一緒に glibc 一式を再コンパイルしなければな らないリスクがあったが、 別パッケージにすることでそれを回避できるというメリットも ある。
現在の Debian glibc は、 Linux カーネル 2.2 から 2.6 までをサポートしている。 しかし、 既にカーネル 2.2 シリーズはメンテナンスされなくなりつつあり、 Debian から消えつつ ある。
glibc はカーネルによってコンパイルするソースを切り替えているが、 最適化パッケージをインストー ルしていない限り、 いつまでもカーネル 2.2 の頃にあった古いシステムコールを利用してしまう。 そこで、 etch ではカーネル 2.2 サポートを廃止し、 カーネル 2.4 以上でなければ動作できなくする予定で ある。
woody → sarge の移行では、 mips, sun4m, hppa, hppa64, real-i386 などがカーネルを最新版へアップグ レードしない限り glibc も入れ替えられない状態が発生した。 これは、 カーネルと glibc の仕様が一緒に 変更されたためである。
しかし、 一旦カーネルと glibc をアップグレードした後、 カーネルを昔のバージョンに戻して再起動さ れるとシステムがうまく動作しなくなる可能性もある。
そこで、 カーネル 2.2 サポート廃止にあわせて、 古いカーネルを検出した場合は/etc/init.d/glibc-kernel-check といったスクリプトによってユーザに警告を発せられるような仕組みを整えていく予定で ある。
RedHat の RHEL4 や Ubuntu ia64, ppc 版では linuxthreads に代わって NPTL が標準 PThread ライブラリとして採用されている。 既に上流開発者も linuxthreads は今後メン テナンスをほとんど行わない予定と宣言している。 近い将来 Debian でも 2.6 カーネルが 主流になってくれば、 linuxthreads と 2.4 カーネルはサポートを止めていく方向になるだ ろう。
Debian では sarge の大幅なリリース遅れにより、 glibc や linux-kernel-headers がかなり古いバージョン になってしまった。 これは、 リリースマネージャによるベースパッケージフリーズの影響が大き い*20 。 etch では、 SCC の導入によってマイナーアーキテクチャの FTBFS に足をひっぱられなくなることもあ るので、 出来るだけ最新版を unstable に積極投入していきたい。
また、 upstream とのより緊密な開発体制を敷くためにも、 experimental を積極活用し、 cvs 最新版を 出来るだけ experimental へ投入していきたいと考えている。
本文書では主に glibc, linux-kernel-headers を中心に Debian ツールチェインの解説を行なった。 良く使 われてはいるものの、 普段あまり中身を知る機会のないと思われるパッケージであるが、 これを機会に関 心を持っていただければ幸いである。
東 京 エ リ ア Debian 勉強会 2005 夏_________________________________________________________
