ポータビリティを高くする
アプリケーションをポータブルにする方法は、特定のディストリビューション上で完成した既存アプリケーションのポータビリティをチェックすることから開始することもできれば、そのアプリケーションをLSBビルトツールにて完成させることを目指した開発を行うこともできます。
「新しいアプリケーションの作成」のセクションでは、LSBビルトツールを使い、LSB準拠アプリケーションの開発を進めるためのツールと情報を提供します。
「既存アプリケーションの修正」のセクションは、既に完成しているアプリケーションをお持ちのベンダーのために用意されています。
「LSBツール－実際に使ってみよう－」のセクションは、一連のLSBツールを使ったアップリケーションのチェック、テストの一例を示します。
新しいアプリケーションの作成
適切なツールを使って作成・テストすれば、新しいアプリケーションをLSB認証可能にすることは、それほど難しいことではありません。
LSB Software Development Kit (SDK)は、バイナリとRPMパッケージのLSB準拠性を開発者自身で検証する手段を提供します。ビルド進行中は、アプリケーションによるAPIの使用状況をモニターして、検証の確実性を保証します。
「LSB準拠のアプリケーション作成」の項では、LSB準拠のアプリケーション作成に必要なツールの入手方法およびインストールおよび実行方法の概略を述べ、実際に開発に着手できるようガイドします。
「LSBサンプル実装(LSB SI)」は、LSBに準拠した最小限の実行環境で、アプリケーションのテストに使用します。ディストリビューション固有の動作の影響を受けないように、LSB準拠を目指すアプリケーションは必ずLSB SIでテストする必要があります。LSB認証プログラムでも、このLSB SIの使用が義務づけられています。
LSB準拠のアプリケーション作成
LSB準拠の新しいアプリケーションを作ることを決定したら、次にどうするか？LSBに向けての開発は、多少のセットアップ作業を伴います。具体的には以下の通りです。
- LSB Software Development Kit (SDK)のダウンロード
- LSB SDKのインストール
- Linux Application Checkerのダウンロードとインストール
- LSB SIのダウンロードとインストール
開発がスタートしてからは、アプリケーションをLSBに準拠させるための良い戦略があります。それにはLinux Application Checkerツールを利用しますが、詳しくは後程このページで説明します。
LSB SDKのダウンロード
LSB SDKは、LSB認証にふさわしいアプリケーションを作成するための開発環境を提供します。このキットはtarball形式で、インストールスクリプトも入っています。LDNのWebサイトのダウンロードページからダウンロードできますので、該当するアーキテクチャーに見合ったものをダウンロードして保存してください。
LSB SDKのインストール
自分のアーキテクチャーに見合ったLSB SDKパッケージ（tar.gz）のダウンロードが完了したら、下記の手順でインストールしてください。
1. パッケージを解凍します。
tar xzf lsb-sdk-
Linux Application Checkerのダウンロードとインストール
LSBサンプル実装(LSB SI)のダウンロードとインストール
LSB準拠に向けての戦略
LSB準拠阻害要因の排除方法
LSBサンプル実装 (LSB SI)
LSB SIは、汎用ディストリビューションではありません。これは、LSB仕様に準拠したアプリケーション構築の可能性を実証するテスト環境なのです。
殆どのLinuxディストリビューションは多数のパッケージで構成され、そのどれをインストールするか、または後で追加・削除・アップグレードするかはユーザーに任されています。これは至極普通のことですが、ポータブルアプリケーションを作成する場合には少々問題が起こります。アプリケーションをインストールする予定のシステム上に存在することを許されていない何かをアプリケーションがリンクしてしまっていないことの確証が得にくいからです。
アプリケーション開発にLSBを利用すれば、この問題の発生を効果的に抑えることができます。LSB認証されたディストリビューションは全て、一定のライブラリとインターフェースで構成され、LSBに文書化されている通りに動作するからです。
LSB SIは、LSBディストリビューションの中核となるこれらのライブラリとインターフェースの必要最小部分だけを実装したもので、プログラムの出荷前テストに使用されます。
例えば、自動検出ビルドスクリプトを有するソフトウェア（GNU configure等）では、システムにインストールされているもの全てが、それがLSBの一部であるかどうかとは無関係に、ビルドで利用する可能性があります。そこで、得られたバイナリをLSB SIで実行すれば、LSB不適合のフィーチャーが紛れ込んでいるケースを検出できることになります。
AppCheckerはスタティックツールなので、他のプログラムを呼ぶ場合のような、実行時の問題を見つけることはできません。一方、LSB SIでは、LSBに適合した環境でアプリケーションを動作させることが可能になります。
LSB SIは、LSBに準拠したシステム構築が可能であることの「概念証明(proof-of-concept)」と考えることもできます。その基本方針は、パッケージメンテナーによって公開されているパッケージと最小限のパッチだけを使用することにあります。これら一部のパッチは、LSB SI環境でビルドを行う時に（大抵の場合は、ビルドに必要なの機能を補うために）必要となります。バグを修正したり、LSB適合性を満たすために用意されているパッチもありますが、これらは本来、上流メンテナーが次のリリースに盛り込むべき性質のものです。
LSB SIは、LSB仕様の進化に合わせて変化し続けます。新しいフィーチャーは、それらが仕様として確定された時点で、LSB SIのテストバージョンに組み込まれます。新しい仕様が承認されるのとほぼ同時に、その仕様に沿ったLSB SIのバージョンが発表になるということは、いずれかのディストリビューションのフルサポートを決める前に、新しいフィーチャーをプレビューする機会を開発者に与えるということでもあります。
LSB SIは、スタンドアロンのLinuxディストリビューションとして設計されてはいません。あくまでサンプルであり、単なるテスト環境です。通常のディストリビューターから得られる付加価値 － 性能やセキュリティに関する問題の追跡と解決等 － は、LSBプロジェクトでは提供していません。
インストール
LSBサンプル実装（LSB SI）ツールは、ふたつのパッケージで構成されています。
lsbsi-chroot：SI chroot用コアファイルシステムを提供
lsbsi-tools：SI chroot設定・実行用のツールを提供
これらのパッケージは、rpm、deb、tarballのいずれかのフォーマットで入手可能で、互いに独立してインストールできます。実際のところ、それぞれを異なったマシンにインストールし、一緒に動作させることもできます。
rpm/deb形式でのインストール
ダウンロードしたパッケージファイルのタイプにより、rpm、dpkgその他のパッケージマネージャーを使用する必要があります。例えば：
rpm -i lsbsi-chroot-3.2.0-3.i586.rpm lsbsi-tools-3.2.0-3.i586.rpm
デフォルトでは、lsbsi-chrootは/opt/lsb/si/chrootに、lsbsi-toolsは/opt/lsb/si/toolsにインストールされます。lsbsi-chrootインストール後に、lsbsiグループがシステムに追加されます。
lsbsiグループに自分のユーザー名を追加するのを忘れないでください。LSB SIツールは、lsbsiグループのユーザーまたはrootユーザーしか使用できません。また、lsbsiグループの全てのユーザーが、chrootやmountを実行できるようにするために/etc/sudoersが修正されます。
xdg-utilsがシステムにインストールされている場合は、lsbsi-toolsパッケージをインストール後に、LSB SIを実行するためのメニューがデスクトップに表示されます。 その他の場合は、/opt/lsb/si/tools/si を使用して実行してください。
tarball形式でのインストール
1. lsbsi-chroot-3.2.0-3.i586.tar.gzファイルの展開：
sudo tar xzfv lsbsi-chroot-3.2.0-3.i586.tar.gz
2. lsbsi-chroot-3.2.0フォルダに移動してコマンドを実行：
sudo ./install.sh
このスクリプトで、lsbsiグループが追加され、/etc/sudoersファイルが修正されます。
3. lsbsi-tools-3.2.0-3.i586.tar.gzを展開：
tar xzfv lsbsi-tools-3.2.0-3.i586.tar.gz
4. lsbsi-tools-3.2.0フォルダに移動してコマンドを実行：
sudo ./install.sh
インストール中に、chrootへのパス（lsbsi-chrootが展開されているフォルダへのパス）を指定してください。
LSB SIツールの実行
LSB SIツールは、デスクトップメニューから選択、または[lsbsi-tools-path]/si-GUIを実行して動作させます。[lsbsi-tools-path]は、rpmまたはdebを利用した場合は/opt/lsb/si/toolsで、tarball形式でインストールした場合はlsbsi-toolsが展開されているフォルダへのパスとなります。これにより、設定調整・chroot環境起動用のGUIインターフェースが立ち上がります。chroot環境を起動するには、[lsbsi-tools-path]/siスクリプトを使用する方法もあり、これは、Qt4ライブラリが搭載されていないシステムの場合に便利に利用できます。
設定オプション
chroot環境起動時のオプション設定にはグラフィカルインターフェースを利用します。これらオプションの殆どは、chroot環境へリモートアクセスするためのssh接続のためだけに使用されます。
設定可能なオプションは以下の通りです。
- Path：ローカルまたはリモートシステム上のchroot環境へのパス
- Host：lsbsi-chrootのあるサーバのホスト名
- Port：サーバ上のsshデーモンへのポート番号
- User：ssh接続されるユーザー名
- PreferredAuthentications：認証モード（publickey、keyboard-interactive、password、またはhostable）
- X11forwading：X11転送オプション（normalまたはtrusted）
chroot環境を立ち上げるためのオプション調整を行う一番簡単な方法はグラフィカルインターフェースを利用することですが、si_run.confファイルに全てのオプションを指定するという方法もあります。siスクリプトをご使用の場合は、siスクリプトの中に引数を指定することもできます。（詳しくは、./si--helpを参照のこと。）
オプションの設定が全て終了したら、Run SIボタンをクリックしてください。SI chroot環境でシェルが動作しているターミナルウインドウ（gnome端末またはkonsole）が開きます。
LSB SIトラブルシューティング
現行バージョンのLSB SIはSE Linuxをサポートしていません。LSB SIを立ち上げる前にSE Linuxを無効にすることを推奨しています。
LSB SIをデスクトップメニューから起動できない場合は、ターミナル（[lsbsi-tools-path]/si）から起動して、何が問題なのか、エラーメッセージで確認してください。
LSB SIをデスクトップメニューから起動することが、不正なchroot環境の原因になることがあります。この問題はFedora Core 9の場合に特に起こりやすく、理由は、/etc/sudoersがDefaults requirettyの文字列を含んでおり、それが、ターミナル以外からのsudoコマンド実行の邪魔をしているからです。この状況は、下記に述べるような対策を取ることで回避できます。
- /etc/sudoers内のDefaults requirettyの行をコメントアウトする。
- 該当するメニュー項目に関し、Launcher Properties内のアプリケーションのタイプを変更する。タイプをApplication in Terminalに変更する。（Gnomeの場合）
- ターミナル経由でLSB SIを起動する。rpmやdeb形式でインストールした場合は /opt/lsb/si/tools/siを使用。またはlsbsi-tools.tar.gzファイルを展開したフォルダの./siを実行。
LSB SIのアンインストール
rpmまたはdebの場合は、rpm –eまたはdpkg –rコマンドを使用します。tarball版をアンインストールする場合は、該当するフォルダに移動し、sudo ./uninstall.sh を実行します。
既存アプリケーションの修正
既に開発されたLinuxアプリケーションを持っている開発者やISVは、先ず何をすれば良いのか？他のLinuxディストリビューションに移植するか、それとも、いろいろなディストリビューション間共通で使用できるようにするか？LSB認証を取得するか、それとも見合わせるか？
ここでは、このような選択のいかんに拘わらず、アプリケーションの移植効率を大幅に向上させるための方法とツールをご紹介します。 「複数ディストリビューションへの移植」の項では、複数のディストリビューションへの移植作業を正しく行うためのガイドラインを提供します。
複数ディストリビューションへの移植
複数ディストリビューションへのアプリケーションの移植は、多大なエンジニアリングコストとサポートコストというイメージにつながりやすく、このためにLinuxプラットフォームの真の価値が損なわれるのは残念なことです。LDNは、ディストリビューション間共通のポータビリティ向上の技術やLSB認証を確実にするための技術に重点を置きながら、開発コストと工数の大幅削減を可能にするスキルとツールを提供して行くことを第一目標としています。
ポータビリティを向上させる最も良い方法は、LSB Application Checkerを利用してテストしてみることです。このツールを用いれば、LSB準拠まで、あとどれくらいで到達できるかを知ることができます。テストレポートのLSB認証ページを開けると、アプリケーションが使用しているライブラリとインターフェースの中で、どれがLSB準拠を阻んでいるかまで特定することができます。そして、それらが確認できたら、LSB準拠を実現するために推奨できる方法は4つあります。例えLSB準拠が目的ではない場合でも、LSBに向かって歩むことは、アプリケーションのポータビリティを格段に高める結果につながります。
LSB準拠阻害要因の排除方法
● 代替インターフェースを使用する。
（例：memalign()の代わりにposix_memalign()を使用）
● 代替ライブラリを使用する。
（例：openssl の代わりにlibnssを使用）
注：これは、ディストリビューション間共通のポータビリティ実現を、はっきりと目標に定めている場合に最適な方法です。opensslは、いろいろなディストリビューションが異なったバージョンに対応したABI群を提供しているからです。
● ライブラリをスタティックにリンクする。
警告：一部のライセンスソフトウェア、例えばGPL等は、スタティックにリンクされたライブラリをメインアプリケーション本体の一部とみなし、メインアプリケーションにまでライセンス条件を拡大適用する場合があるので注意が必要です。
● ISVが提供する共有ライブラリにダイナミックにリンクする。
これらの他にも、アプリケーション移植時に考慮すべき戦略もあります。
● エンディアンネスの検討（bigendianまたはlittleendian） アーキテクチャーレベルで考慮すべき問題です。
● 32ビット/64ビット対応性
どちらか一方にだけ依存しないでください。
● ハードコードされたアドレスの排除
● オブジェクトサイズを取得する場合のsizeofの使用 32ビットから64ビットに変換する場合は特に重要です。
● charが符号付き（または符号無し）と仮定しない。
● 浮動小数がdoubleと同じサイズと仮定しない。
● #ifdefを使用する場合は注意する。
● 関数プロトタイプを必ず作成し、コンパイル時には-Wstrict-prototypesオプションを用いて、その使用をコンパイラに厳密にチェックさせる。
● POSIXインターフェースとデータ型を使用する。
● CおよびC++ライブラリに含まれる標準関数のみを使用する。
● ディストリビューション固有のライブラリの使用や、ライブラリの拡張はしない。
● アプリケーションのビルドにはLSB SDKが提供するLSBツールを使用する。
LSBツール－実際に使ってみよう－
Linuxはオープンなオペレーティングシステムなので、目的に合わせた設定と構築が可能です。しかしながら、種類が豊富で選択の余地が広いということがユーザーにとって有利である反面、このような異種混交状態にソフト開発者がてこずっているというのも事実です。基本は似ていても、それぞれ微妙に違うプラットフォームに向けてパッケージを設計しなくてはならない面倒があるからです。ただし、アプリケーションがLinux Standard Base (LSB)に準拠しており、各Linuxディストリビューションも同様であれば、アプリケーションは各準拠ディストリビューション上で実行可能になります。この項では、LSBの良さを理解した上で、この標準に適合する形で実際にコードを移植する方法を学習して行きましょう。
本チュートリアルは、Linuxソフト開発者を読者に想定して書かれています。LSBとは、Linuxソフトウェアディストリビューション間の互換性を向上させるための仕様、および、その目的のために開発されたツールとテスト用パッケージソフトで構成されています。LSB仕様に準拠し、ユーザーに互換性を保証していると認められたアプリケーションやディストリビューションはLSB認証を取得することができます。以下にLSBの概略と、アプリケーションコードのLSB準拠性を検証する方法を解説します。
前提条件
本チュートリアルを利用するには、CまたはC++プログラミング言語、標準的なLinuxソフトウェア開発環境、およびそこで使用されるコンパイラ、リンカ、システムライブラリ、各種設定、ビルドユーティリティ、パッケージ化ソフト等の一連のツールに関して、知識と経験を持っていることが必要です。
さらに、コマンドラインを使用してのソフトウェアのインストール、また、ファイルシステムの構築、ネットワークサービスの停止、システムサービスの追加等を始めとするLinuxシステムの保守・管理に関しても、ある程度の経験が必要です。
Debian Linuxを利用している場合は、APTパッケージマネージャーに関する経験も必要となります。
本チュートリアルを開始するに当たっては、ソフトウェアパッケージをいくつかLinuxにインストールしなくてはなりません。インストールが必要なものは以下の通りです。
Linuxディストリビューション用KVMパッケージ
注：KVMパッケージの代わりに、VMWare WorkstationをMicrosoft® Windows® XPにインストールして、バーチャル化したLinuxのインスタンスをXPプラットフォームで動作させることもできます。VMWare Workstationのお試し版は無料でダウンロードできますので、それを使ってバーチャルマシン（VM）を作成し、セーブすれば、VMWare Player（無料）に切り替えて再実行が可能です。
対象ハードウェアプラットフォームのLSB仕様（バージョン3.2.0）も同時にダウンロードして、目を通しておくことをお薦めします。代表的な7個のプロセッサ（IA32、IA64、 PPC32、PPC64、S390、S390XおよびAMD64）に対応したハードウェア別LSB仕様書が用意されています。
アプリケーションの認証を受ける場合は、Linux FoundationのLSB認証プログラムのページを訪れてください。
本チュートリアルに記載されているサンプルプログラムを実行するには、オペレーティングシステムにLinuxまたはWindows XPを採用しているコンピュータが必要です。VMare Workstationは、これらいずれのプラットフォーム上でも動作し、以降の作業に必要なLinux環境を提供します。
アプリケーションが、自分のプロセッサに対応したLSB仕様書で承認されていないソフトウェアライブラリに依存している場合、それらのライブラリもバーチャルシステムにインストールする必要があります。混乱を防ぐため、アプリケーション固有のライブラリは標準ライブラリと分離してインストールするのが理想的です。
標準化の必要性
DistroWatchのWebサイトの記載によると、現在少なくとも25のLinuxディストリビューションが存在しています。これだけでも驚異的な数字ですが、サイズを最適化したもの（例：Damn Small Linux）、使い勝手を改良したもの（例：Knoppix）、コミュニティユーザー主体で開発したもの（例：Fedora Core）、特定の国用にカスタマイズされたもの（例：Red Flag Linux）等を加えると、この数字は一足飛びに2倍にも3倍にも増加します。これだけ多くのバリエーションがある近代的なオペレーティングシステムは、Linux以外には見当たりません。
Linuxの「ご自分でどうぞ」的文化は、多様化と専門化を助長します。他方、このような拡散の仕方は、Linuxアプリケーションを開発・販売・サポートしているISVにとって、対抗しがたい状況を創出しています。1980年代の「UNIX® 戦争」がISVの成功のチャンスを打ち砕いたとするなら、これだけ多くのLinuxバージョンの存在も、Linuxアプリケーションの量産市場を閉塞させるだけとしか言いようがありません。複雑なアプリケーションを、多数のLinuxバリエーションのために開発・サポートするために費やさなければならないコストを想像してみてください。
相互運用性向上のために
Linux Standard Base (LSB)は、多様化の促進と一貫性の維持を目指して、Free Standards Group（Linux Foundationの前身）によって策定されました。LSBのWebサイトでは、「Linuxディストリビューション間の互換性を高め、全てのLSB準拠システム上でソフトウェアアプリケーションの実行を可能にするための標準制定と推進を目的とするオープンソースプロジェクト」と定義されています。
LSBでは一貫性のあるLinux プラットフォームを規定しており、このプラットフォームを（少なくとも）実装しているLinuxディストリビューションは、LSB準拠と認められます。（このことは、付加的な特徴を組み込むことを否定するものではありません。）LSBプラットフォームが提供するサービスだけを使用するLinuxアプリケーションも、同様にLSBに準拠しているとみなされます。アプリケーションが追加で必要とするライブラリは、インストールまたはスタティックリンクのいずれかの方法で利用可能にします。（これらのライブラリも、自給自足的でLSBに準拠している必要があります。）
LSBが標準を定めている（または、いずれ定めようとしている）分野を図3.に示します。具体的には、全てのLinuxアプリケーションの基礎となるライブラリ、重要ファイルの格納先指定や現地語化への対応方法を含む実行環境、システムの初期化、LSB準拠システムで使用する共通コマンドやユーティリティ、および、ユーザー/グループ管理が含まれます。
図３：LSBのコンポーネント
アプリケーション開発者にとって最大の関心事は、ブルーとオレンジでマークした部分かと思われます。
青色で示した部分には、LSB準拠のアプリケーションが使用できるコアライブラリと追加モジュールを規定しています。コアライブラリには、libc、libm、libpthread、libpam、libcrypt、libz、libncurses、librt、libgcc_sが含まれます。モジュールには、X Window System Version 11用グラフィックス（libX11、libXt、libXext、libSM、libICE、libGL）およびC++標準ライブラリ（libstdc++）があります。
オレンジの部分はLSB仕様の一部ではありませんが、アプリケーションやパッケージが、LSBに準拠しているかどうかを検証するための重要なツールを示しています。
バイナリ互換性
LSB標準はバイナリ互換です。LSB準拠のアプリケーションバイナリ（コンパイル後の実行コード）は、LSB準拠の任意のLinuxディストリビューション上で実行可能です。（ただし、アプリケーション、ディストリビューションともに、同一のプロセッサ用に開発されたものである必要があります。）
バイナリ互換性はソース互換性とは大きく異なります。ソース互換のアプリケーションの場合、ローカルシステムのコンパイラとライブラリを使用してのリコンパイルが必要で、問題は、これらふたつが予測不能な動作やばらつきの源であるという点です。ソース互換の場合、実行ファイルが動作すること（ましてや期待通りに動作すること）が保証されている訳ではありません。
整合性確保のメリット
LSBは、ディストリビューションとアプリケーション間に締結された「拘束力のある協定」と解釈することができます。ディストリビューションは、仕様に従ったライブラリとインターフェースを提供することを約束し、アプリケーションは、これらのライブラリとインターフェースだけを使用し、足りないものは自分で用意することに合意します。両者がこの協定を遵守することを保証する手段として、各種ツール類、ガイドライン、ディストリビューションおよびアプリケーションに対する検証・認証サービスがLSBから提供されています。
LSBに従うことは、ディストリビューションベンダー、ISV、ユーザーの三者全ての利益につながります。
ディストリビューションベンダー
LSBに準拠することにより、ユーザーの保有する製品上で、多くのアプリケーションが終始一貫、確実に動作することを保証できます。いったん認証を取得してしまえば、その後は差別化や新しいフィーチャーの開発に全力を傾注できます。
ISV
認証されたバイナリは、LSB準拠のディストリビューションに次々展開して行くことが可能です。認証取得後に必要なことは、そのバイナリを自分でテストしサポートして行くことだけです。もし、そのバイナリが国際的に認められれば、たったひとつのアプリケーションの単一バージョンだけで、世界中のユーザーを満足させることも可能になります。
ユーザー
競合するいくつもLSB準拠のディストリビューションの中から、自分に最も適したLinuxを選ぶこともできますし、ひとつのベンダーだけに偏ることも避けられます。 Linuxアプリケーションの選択の幅も広がります。
このようなダイナミックスは、ディストリビューションベンダー、ISV、ユーザーの全てが、それぞれのLinuxに対する投資から大きな恩恵を受けられることを意味します。もちろん、Linux自身も報われます。
LSB構築環境とサンプル実装
LSBは、ディストリビューションとアプリケーションが互いにLSB仕様に従うことを約束した「協定」です。しかし、LinuxディストリビューションをLSBに準拠させることがいかに複雑かを知らずして、アプリケーションを準拠させるのは至難の技かも知れません。
アプリケーションの開発者は、自分が使っているコードのことは当然熟知していますし、それをLSBに準拠させるために積極的に働いてもくれるでしょう。しかし、そのコードがLSBに準拠していないコンポーネントに依存しているかどうかまでは明確に解らない場合も多いのではないでしょうか？特に、Linuxディストリビューションの場合、その中には何千個というコンポーネントがゴロゴロしているのですから。
例えば、そのコードが、特定のディストリビューションだけが採用しているLSB未準拠のストリングライブラリに依存しているかも知れません。また、そのストリングライブラリが、つい最近、システムアドミニストレーターによってローカルに追加されたばかりという場合もあり得ます。別の例では、ライブラリのバージョンの問題があります。あるライブラリのバージョンＷがLSB仕様に準拠しているからといって、バージョンYまでそうであるという保証はありません。
マイグレーション用ツール
このような依存性を検出・排除するために、つまり、コードをLSBに準拠させるための重要な手段として、LSBはふたつのツール － ビルド環境とサンプル実装（LSB SI） － を提供しています。
ビルド環境は、ソースコードがLSB未準拠のライブラリとアプリケーションバイナリインターフェースに依存していないかどうか検査するためのツールで、ヘッダファイル、スタブライブラリ、それとLSB準拠のLinuxシステム上でのソフトウェアビルド環境をシミュレーションするためのコンパイララッパで構成されています。このツールは、あらゆるLinuxシステム（LSBに準拠していないシステムも含む）にインストール可能です。
ビルド環境には2種類あります。ひとつは、開発者が現在使用中のローカルオペレーティングシステムで動作するユーティリティのセットで、LSB環境におけるビルドのシミュレーションに使用します。もうひとつは完全なファイル階層となっており、chroot環境の代わりに使用します。前者は、LSB準拠性を手軽に評価する際に便利です。後者では、現在のビルド環境を新しいrootに取り込む必要がありますが、迷子ファイルの問題は起こりません。
サンプル実装(LSB SI)は、LSB準拠の実行環境でアプリケーションが正しく動作することを検証する手段です。LSB準拠のディストリビューションを代用する、一種のミニLinuxと考えて頂くと良いでしょう。実際にサンプル実装からブートすることもできます。
もちろん、Linuxに準拠しているディストリビューションそのものを使って検証することも可能ですが、サンプル実装の使用を推奨する理由がいくつかあります。まず、LSBで定義されているものだけで構成されています。またLSB仕様のバージョンに合わせて、異なるバージョンのサンプル実装が入手可能です。例えば、アプリケーションがLSB3.0とLSB3.2に準拠していることを検証したい場合には、該当するバージョンのサンプル実装を同じテストシステムにインストールするだけで済みます。これは、Linuxシステムをふたつ用意するよりは余程簡単です。さらに、新たに承認されたLSB仕様に対する検証も、その仕様に準拠したシステムが導入されるまで待つ必要もなく、即座に実行に移せるというメリットもあります。
LSB標準の各バージョンに対応して、ビルド環境とサンプル実装はセットで提供されています。本チュートリアルは、LSB3.2.0に準拠したプラットフォームの使用を前提として書かれています。（このチュートリアルを作成した時点での最新バージョンです。現在普及しているLinuxのディストリビューションの多くは、旧バージョン（LSB3.1.0、LSB3.0.0）のLSBのインスタンスを用いて認証されている可能性が高いと思われます。）
バーチャルマシン（ＶＭ）を用いての移植のメリット
LSB3.2.0サンプル実装を利用するには、これをchroot環境で実行できるオペレーティングシステムが必要です。本チュートリアルでは、コミュニティ開発のLinuxディストリビューションのひとつ、Fedora 9 ( FC9)を、この目的に使用します。
FC9を持っていない場合、また、旧LSBの多数のインスタンス、もしくは複数のLinuxディストリビューション上でこのサンプル実装を実行したい場合はというと、最も簡単でコストのかからない方法は、それぞれのLinuxディストリビューションをVM上で走らせることです。（方法としては多少煩雑になりますが、マシンをマルチブートに変更したり、ハードウェアを増設したりすることでも対応できます。）
KVMは、Ubuntu Hardyを始めとする殆どのディストリビューションがサポートしているバーチャル化技術です。Intel-VTやAMD-V (AMD SVM エクステンションとも呼ばれる)をサポートしている比較的新しいx86系 CPU が搭載されたシステムで利用できます。KVMをサポートしている（または、していない）CPUのリストはXensourceのWebサイトに掲載されています。システムによっては、バーチャル化のエクステンションを有効にするために、BIOSコンフィギュレーションの変更が必要となります。BIOSコンフィギュレーションを変更した場合は、変更をフラッシュメモリに保存後、電源を入れ直す必要がもあります。
KVMをサポートしていないLinuxシステム、または、Windows XPなどのシステムをお使いの場合は、代わりにVMWareをインストールします。この場合、Thought PoliceのWebサイトにあるFedora Core 9イメージが必要となります。
VMWare Workstationのダウンロードとインストール
VMWare WorkstationをDebian Linux にインストールし、FC9をVMで実行します。これで、LSB3.2.0のビルド環境とサンプル実装が実行可能になります。
VMイメージのダウンロード
FC9 VMイメージはLinux FoundationのWebサイトからダウンロードできます。このイメージはオペレーティングシステム全体を含み、従って1400MBと、かなり大容量です。
KVMのインストール
Ubuntu Hardyをご使用の場合、KVMパッケージは簡単にインストールできます。ターミナルウインドウで下記コマンドを使用します。
sudo apt-get install kvm
グラフィカルインターフェースを利用する場合は、Synapticsパッケージマネージャーを使用します。
DebianまたはUbuntuディストリビューションでは、rootユーザー以外がKVMを利用する場合には、自分のユーザーIDを"kvm"グループに登録しなくてはなりません。テキストエディタで/etc/groupを編集してスーパーユーザーになるのがひとつの方法です。Ubuntuの場合は、メニュー選択という方法もあります。システムのメニューバーから、System->Administration->Users->Groupsと選び、Unlockボタンをクリック。次にパスワードを入力してManage GroupsをクリックするとGroup Settingsウインドウが開きますので、"kvm"を探し、Propertiesをクリックします。Group Membersリストが表示されたら、自分のユーザーIDにチェックマークをつけてOKボタンをクリックします。"kvm"グループに変更を加えた後は、必ず一度ログアウトして、再度ログインしてください。
KVM Workstationの実行
KVMバーチャルマシンを起動するには、ターミナルウインドウで下記コマンドを実行します。
kvm fedora-9-i386.qcow2
Ctrl+Alt を押さない限り、KVMアプリケーションはマウス/キーボードからの入力を全てトラップします。バーチャル環境に戻るには、KVMウインドウ上をクリックしてください。
おめでとうございます！以上でめでたくFC9がVM上で動作することになります。
セットアップ完了したら、LSBへのコード移植プロセスに進みます。
一般的な移植方法
LSBへのアプリケーション移植は次の手順で行います。
コードを新しいビルドシステムにコピーします。 新しいビルドシステムとは、別個のハードウェア（本チュートリアルではVM）上で動作している、LSB準拠のLinuxディストリビューションのことです。
コードをビルド後、Linux Application Checker (AppChecker)ツールを用いてバイナリをスキャンし、LSB仕様にないシンボルが含まれていないことを確認します。スタティックアーカイブもスキャンして、それらがLSB準拠のアプリケーションでの使用にふさわしいかどうかも確認します。
無効なシンボルが発見された場合は、コードまたはコードアセンブリをLSB仕様に適合するよう変更します。
例えば、LSB仕様に合致しないライブラリはスタティックリンクで接続して、コードがライブラリ内で自己完結するようにします。（ライブラリ内のコード自体はLSBに準拠していると仮定した場合。）全ての問題を解決したら、次のステップに進みます。
LSBビルド環境を使用して、クリーンかつ標準に準拠した環境でコードをビルドします。コードがLSB未対応のライブラリを使用している場合は、それらをインストールまたはスタティックリンクでつなぐ等の変更が必要になります。（全てのライブラリはLSBに準拠している必要があります。）
LSBビルド環境によるコードのビルドに成功したら、LSBサンプル実装（LSB SI)でコードを実行します。
対象のLinuxシステムがLSBに準拠している場合は、そのシステム上で実行することも可能です。
アプリケーションをパッケージ化します。 LSB準拠のRPM は、LSB準拠のシステムに必ずインストールできます。ただし、この方法だけに拘る必要はなく、LSBに準拠したシステム上で動作可能という条件の下で、他のパッケージ化技術も利用できます。例えば、tarballを付属したシェルスクリプト、（LSB準拠という条件で）お手持ちのインストーラなども利用可能です。
では、簡単なアプリケーションを実際に作ってみましょう。
LSBビルド環境ユーティリティのインストールと実行
chrootバージョンのLSBビルド環境を利用する前に、ビルド環境ユーティリティを試してみます。これらのユーティリティAppChecker（lsbappchk、lsbpkgchk）は、殆どのLinuxシステムに簡単かつ迅速にインストールでき、アプリケーションやRPMパッケージ（標準LSBフォーマット）がLSB準拠にならない原因の確認に役立ちます。
LSBビルド環境ユーティリティのダウンロードとインストール
ビルド環境ユーティリティはふたつのRPM（lsbappchk用とlsbpkgchk用）で構成されています。このテストシステムの例はDebian Linuxを使用しているので、まずdebフォーマットに変換し、Debianのdpkgパッケージマネージャーが使えるようにします。
1 $ sudo apt-get install wget
2 $ wget http://ftp.linuxfoundation.org/pub/lsb/test_suites/released-3.2.0/binary...
3 $ wget http://ftp.linuxfoundation.org/pub/lsb/test_suites/released-3.2.0/binary...
4 $ wget http://ftp.linuxfoundation.org/pub/lsb/lsbdev/released-3.2.0/binary/ia32...
5 $ wget http://ftp.linuxfoundation.org/pub/lsb/lsbdev/released-3.2.0/binary/ia32...
6 $ wget http://ftp.linux-foundation.org/pub/lsb/lsbdev/released-3.2.0/binary/ia3...
7 $ sudo apt-get install alien
8 $ alien *.rpm
9 $ ls -t -1
lsb-pkgchk_3.2.2-2_i386.deb
lsb-build-cc_3.2.1-1_i386.deb
lsb-build-c++_3.2.1-1_i386.deb
lsb-build-base_3.2.2-1_i386.deb
lsb-appchk_3.2.4-1_i386.deb
lsb-pkgchk-3.2.2-2.i486.rpm
lsb-appchk-3.2.4-1.i486.rpm
lsb-build-c++-3.2.1-1.i486.rpm
lsb-build-cc-3.2.1-1.i486.rpm
lsb-build-base-3.2.2-1.i486.rpm
10 $ sudo dpkg --install *.deb
11 $ ls /opt/lsb
bin doc man
12 $ ls /opt/lsb/bin
lsbappchk lsbc++ lsbcc lsbpkgchk
コマンド１はwgetのインストール（システムにまだ搭載されていない場合）、コマンド2-6はLSBユーティリティの最新版のダウンロードを行います。
lsb-appchkは、与えられたバイナリがLSBで定義され、かつダイナミックにリンクされたシンボルだけを使用しているかどうか検証します。 lsb-pkgchk は、LSB準拠のシステム上にソフトウェアをインストールするためのアプリケーションパッケージが有効かどうか検証します。lsb-pkgchkはRPMだけを対象としたツールです。ただし、LSBでは、ソフトウェアのインストールにRPMだけを使用するよう限定している訳ではありません。
lsb-build-base は、スタブライブラリとヘッダファイルを提供します。スタブライブラリは、LSBに定義された機能を実装してはいませんが、LSBシステム上に存在するダイナミックライブラリと同様に機能し、LSB準拠のアプリケーションのビルドを可能にします。 lsb-build-c++ は、ビルド環境にC++を追加します。
lsb-build-ccはlsbccを内蔵しています。lsbccは、LSB準拠のアプリケーションを作成するためのコンパイラ＝GNU Compiler Collection (GCC)用のラッパです。アプリケーションがGNUタイプのconfigureスクリプトを使用している場合は、デフォルトのCCコンパイラ（GCC）の代わりにlsbccを利用するよう簡単にスクリプトを変更することができます。場合によっては、makefile等でGCCを直接lsbccに置き換えることも可能です。
コマンド7の機能は、alien（RPMをDebian debパッケージに変換するユーティリティ）をインストールすることです。コマンド8はalienを実行し、コマンド9はその結果を表示します。コマンド10 は、コマンド11と12が示すように、全てのソフトウェアを/opt/lsb/ディレクトリにインストールします。 RPMのビルド・検証に関する解説は、本チュートリアルでは省略します。代わりにlsbccを使って小さなCアプリケーションを作成し、その結果として得られたバイナリに無効なシンボルが存在しないか、lsb-appchkを使ってスキャンしてみることにします。
サンプルプログラム
リスト1に、コマンドライン引数を出力する小規模なプログラムを示します。 （エラー処理は意図的に除外してあります。）
リスト1：単純なCプログラム
#include
LSBビルド環境とサンプル実装（LSB SI)のインストール
chrootビルド環境のダウンロードとインストール
Chroot LSBサンプル実装のダウンロードとインストール
ビルド環境・サンプル実装におけるコードのビルドと実行
まとめ
出典
最近のBlogエントリー
