H+I_マイグレ4C_PDF 06.2.14 7:25 PM ページ 6
Linux on
HP Integrity Servers
Technical Guide
— Solaris向けLinuxポーティングガイド —
高性能インテル® Itanium® 2 プロセッサ搭載
2006年1月
HP and HP Partner Use Only
H+I_マイグレ_2C_1_4 06.2.14 6:27 PM ページ 1
Linux Integrity Technical Guide
— Solaris向けLinuxポーティングガイド —
はじめに
急速に拡大するエンタープライズ分野でのLinux活用に向けてHPではサーバ製品のLinux対応を積極的に進めています。インテル®
Itanium® 2 プロセッサ搭載HP Integrityサーバは、優れた信頼性、可用性、そしてスケーラビリティによりエンタープライズLinuxの中核を
支えるバックエンドサーバとして最適なパフォーマンスを提供します。
本Linux Integrity Technical Guideは、Linuxエンジニアを対象にしてHP IntegrityサーバとLinuxにおける技術的な情報をまとめた資料集で
す。システムの構成検討やインストールの際にご活用ください。
本書は、Sun SolarisからLinuxにアプリケーションを移行する際に役立つ情報をまとめたものです。
記載内容は、2005年10月現在のものとなります。記載内容については事前の連絡なしに変更されることがあります
目次
インテル® Itanium® 2 プロセッサ搭載 HP Integrity サーバが選ばれる理由 .............................................................................................5
Solaris向けLinuxポーティングガイド .......................................................................................................................................................6
本ガイドについて ...................................................................................................................................................................................7
1 標準規格およびオープンソース・システムの意義...............................................................................................................................9
1.1 はじめに .......................................................................................................................................................................................9
1.2 LinuxとHP.....................................................................................................................................................................................9
1.3 なぜLinuxを使うのか？.................................................................................................................................................................9
1.4 なぜLinux Standard Base（LSB）を使用するのか？ ....................................................................................................................10
2 ポーティング・プロセスの概要...........................................................................................................................................................11
2.1 ポーティングのプロセス .............................................................................................................................................................11
2.2 ポーティングの問題点と推奨事項 ...............................................................................................................................................12
2.3 その他の留意事項.......................................................................................................................................................................12
2.4 オペレーティング・システムのバージョン調査 ............................................................................................................................12
2.5 ポーティングとコーディングの方法 .............................................................................................................................................13
3 開発環境の概要.................................................................................................................................................................................14
3.1 コンパイラの概要 .......................................................................................................................................................................14
3.1.1 Cコンパイラ.........................................................................................................................................................................14
3.1.2 C++コンパイラ ....................................................................................................................................................................14
3.1.3 Java......................................................................................................................................................................................14
3.1.4 Fortran..................................................................................................................................................................................15
3.2 シェルとスクリプト言語の概要...................................................................................................................................................15
3.2.1 シェル ..................................................................................................................................................................................15
3.2.2 Awk ......................................................................................................................................................................................15
3.2.3 Perl.......................................................................................................................................................................................15
3.2.4 Python..................................................................................................................................................................................15
3.2.5 Tcl/Tk ...................................................................................................................................................................................16
3.3 リンカとローダの概要 ................................................................................................................................................................16
3.4 システム・ライブラリとAPI の概要..............................................................................................................................................16
1
H+I_マイグレ_2C_1_4 06.2.14 6:27 PM ページ 2
3.5 その他の開発ツールの概要 ........................................................................................................................................................16
3.5.1 ソースコードのバージョン管理ツール .................................................................................................................................16
3.5.2 ビルドツール........................................................................................................................................................................16
3.5.3 アプリケーション移行ツール ...............................................................................................................................................17
3.5.4 統合開発環境（IDE）..............................................................................................................................................................18
3.5.5 デバッグ･ツール ..................................................................................................................................................................18
3.5.6 欠陥追跡ツール....................................................................................................................................................................18
3.6 Linux環境のセットアップ .............................................................................................................................................................18
3.7 サードパーティへの依存性 ..........................................................................................................................................................18
3.8 アプリケーションの移行 .............................................................................................................................................................19
4 コンパイラ ........................................................................................................................................................................................20
4.1 Cコンパイラ ...............................................................................................................................................................................20
4.1.1 言語のモード・オプション.....................................................................................................................................................20
4.1.2 プリプロセッサ・マクロ........................................................................................................................................................21
4.1.3 最適化 ..................................................................................................................................................................................21
4.1.4 プラグマ...............................................................................................................................................................................21
4.2 C++コンパイラ ...........................................................................................................................................................................22
4.2.1 テンプレートの実装 .............................................................................................................................................................23
4.2.2 テンプレートのインスタンス化............................................................................................................................................23
5 リンカとローダ .................................................................................................................................................................................24
5.1 リンクエディタ ............................................................................................................................................................................24
5.1.1 コマンド行オプション...........................................................................................................................................................24
5.1.2 環境変数 ..............................................................................................................................................................................24
5.1.3 ライブラリの検索順序..........................................................................................................................................................24
5.1.4 リンカ定義シンボル.............................................................................................................................................................24
5.2 実行時リンク ..............................................................................................................................................................................25
5.2.1 ライブラリの解決.................................................................................................................................................................25
5.2.2 シンボル・バインディング.....................................................................................................................................................25
5.2.3 環境変数 ..............................................................................................................................................................................26
5.3 リンカ関連のツール ...................................................................................................................................................................26
5.3.1 ldd ........................................................................................................................................................................................26
5.3.2 elfdump ................................................................................................................................................................................26
5.3.3 ar..........................................................................................................................................................................................27
5.3.4 lorder....................................................................................................................................................................................27
5.3.5 nm........................................................................................................................................................................................27
6 その他の開発ツール..........................................................................................................................................................................28
6.1 ソースコードおよびバージョン管理............................................................................................................................................28
6.1.1 CSSC ...................................................................................................................................................................................28
6.1.2 RCS......................................................................................................................................................................................28
6.1.3 CVS......................................................................................................................................................................................29
6.1.4 Subversion ...........................................................................................................................................................................29
6.1.5 機能の比較...........................................................................................................................................................................30
6.1.6 他のバージョン管理システムへのソースのポーティング......................................................................................................30
6.2 ビルドツール ..............................................................................................................................................................................30
6.2.1 Ant .......................................................................................................................................................................................30
6.2.2 Make ....................................................................................................................................................................................30
6.2.2.1 シェルの問題 .................................................................................................................................................................31
6.2.2.2 文字列置換における % ワイルドカード .........................................................................................................................31
6.2.2.3 The $< マクロ................................................................................................................................................................32
6.2.2.4 サフィックス規則 ...........................................................................................................................................................32
6.2.2.5 ソース管理のサポート...................................................................................................................................................32
6.3 HP Solaris-to-Linux Application Transition Tools..........................................................................................................................32
6.3.1 HP Solaris-to-Linux binaryScan Utilityの概要 ........................................................................................................................33
6.3.2 HP Solaris-to-Linux Software Transition Kit概要....................................................................................................................33
6.3.3 HP Solaris-to-Linux Porting Kit（SLPK）概要 .........................................................................................................................33
6.4 シェル .........................................................................................................................................................................................34
6.4.1 Bourne Againシェル（bash）..................................................................................................................................................34
2
H+I_マイグレ_2C_1_4 06.2.14 6:27 PM ページ 3
6.4.2 Bourneシェル（sh）................................................................................................................................................................34
6.4.3 POSIXシェル（sh）.................................................................................................................................................................34
6.4.4 Kornシェル（ksh）..................................................................................................................................................................34
6.4.5 Cシェル（csh）.......................................................................................................................................................................34
6.4.6 Turbo Cシェル（tcsh）...........................................................................................................................................................34
6.4.7 Zシェル（zsh）.......................................................................................................................................................................35
6.4.8 環境の制限...........................................................................................................................................................................35
6.5 統合開発環境（IDEs）...................................................................................................................................................................35
7 システムライブラリ，APIおよび実行時環境 ......................................................................................................................................36
7.1 システムライブラリおよびAPI ....................................................................................................................................................36
7.2 Linuxで利用できないSolarisライブラリ ......................................................................................................................................37
7.3 Linuxで利用できないSolarisヘッダファイル ................................................................................................................................38
7.4 ファイルおよびファイル・ハンドル ..............................................................................................................................................39
7.5 ネットワーク機能 ........................................................................................................................................................................39
7.6 数学ライブラリ...........................................................................................................................................................................39
7.6.1 組込まれた数学形式の比較..................................................................................................................................................39
7.6.2 IEEEとFast Math ..................................................................................................................................................................39
7.6.3 ISO C数学ライブラリ関数 ....................................................................................................................................................39
7.6.4 POSIX数学ライブラリ関数 ...................................................................................................................................................39
7.6.5 Solaris数学ライブラリの拡張 ...............................................................................................................................................40
7.6.6 独自開発の数学ライブラリ ..................................................................................................................................................40
7.6.7 その他の検討事項 ................................................................................................................................................................40
7.7 ライブラリの開発 .......................................................................................................................................................................40
7.8 セキュリティAPI ..........................................................................................................................................................................41
8 スレッド .............................................................................................................................................................................................42
8.1 Solarisのスレッド・モデル............................................................................................................................................................42
8.1.1 Lightweight Processes（LWP）..............................................................................................................................................42
8.1.2 Solaris Threads.....................................................................................................................................................................42
8.1.3 Solaris POSIX Threads..........................................................................................................................................................42
8.2 Linux POSIX Threadsモデル........................................................................................................................................................42
8.2.1 LinuxThreads ........................................................................................................................................................................42
8.2.2 Native POSIX Thread Library for Linux（NPTL）.....................................................................................................................42
8.3 Linux NPTL APIに対するSolaris Threadsのマッピング ................................................................................................................43
8.4 Linuxスレッドの実装に関する追加情報.......................................................................................................................................44
8.4.1 移植性のないSolaris POSIX Threadインタフェース..............................................................................................................44
8.4.2 POSIXスレッド属性デフォルト値 ..........................................................................................................................................44
8.4.3 POSIX Threadsヘッダファイル .............................................................................................................................................44
8.4.4 POSIX Threads共有ライブラリ.............................................................................................................................................44
8.4.5 POSIX Threadsアプリケーションのコンパイル ....................................................................................................................45
8.4.5.1 LinuxThreadsを使用したコンパイル ..............................................................................................................................45
8.4.5.2 Native POSIX Thread Libraryを使用したコンパイル.......................................................................................................45
9 エンディアンについての検討事項 .....................................................................................................................................................46
9.1 概要 ............................................................................................................................................................................................46
9.2 永続的データ..............................................................................................................................................................................46
9.2.1 プリプロセッサによるバイト・オーダ制御............................................................................................................................47
9.2.2 実行時のバイト・オーダ制御 ................................................................................................................................................48
9.2.3 標準のバイト・オーダAPI の使用 ..........................................................................................................................................48
9.3 バイト・スワッピング ...................................................................................................................................................................49
9.4 浮動小数点データ.......................................................................................................................................................................50
9.5 未使用バイト...............................................................................................................................................................................50
9.6 共用体.........................................................................................................................................................................................51
9.7 マルチワード・エンティティの32 ビット単位での初期化 ..............................................................................................................51
9.8 バイト配列として使用される16進定数 .......................................................................................................................................51
9.9 その他の留意事項.......................................................................................................................................................................52
3
H+I_マイグレ_2C_1_4 06.2.14 6:27 PM ページ 4
10 32ビットから64ビットへのポーティング ...........................................................................................................................................53
10.1 なぜ64ビットなのか？...............................................................................................................................................................53
10.2 Linux 64ビット環境....................................................................................................................................................................53
10.3 ポーティングの問題 ..................................................................................................................................................................54
10.3.1 標準の型定義 .....................................................................................................................................................................54
10.3.2 ポインタと整数 ..................................................................................................................................................................55
10.3.3 式 .......................................................................................................................................................................................55
10.3.4 ビット・シフト......................................................................................................................................................................55
10.3.5 関数パラメタ......................................................................................................................................................................55
10.3.6 数値定数 ............................................................................................................................................................................56
10.4 ポーティングツール ..................................................................................................................................................................57
10.4.1 Intel® C++ Compiler ............................................................................................................................................................57
10.4.2 The GNU Compiler Collection (GCC)...................................................................................................................................57
10.4.2.1 GCC ............................................................................................................................................................................57
10.4.2.2 G++ .............................................................................................................................................................................57
10.4.2.3 GDB.............................................................................................................................................................................57
10.4.2.4 Data Display Debugger (DDD) ......................................................................................................................................57
10.4.2.5 Splint ...........................................................................................................................................................................58
11 ファイル・システムおよびクラスタについての検討事項 .................................................................................................................59
11.1 ファイル・システム・サポート ....................................................................................................................................................59
11.2 ロジカル・ボリューム・マネージャ
（LVM）..................................................................................................................................59
11.3 Sun Clusters - 背景概要............................................................................................................................................................60
11.3.1 クラスタ構成オプション ....................................................................................................................................................60
11.3.2 管理性 ................................................................................................................................................................................61
11.3.3 クラスタ・コミュニケーション............................................................................................................................................61
11.3.4 リソース構成......................................................................................................................................................................61
11.3.5 クラスタ・ファイル・システム .............................................................................................................................................61
11.3.6 アプリケーション・プログラミング・インタフェース
（API）.................................................................................................61
11.4 HP Serviceguard Clusters - 比較 ...............................................................................................................................................62
11.4.1 クラスタ構成オプション ....................................................................................................................................................62
11.4.2 管理性 ................................................................................................................................................................................62
11.4.3 クラスタ・コミュニケーション............................................................................................................................................62
11.4.4 リソース構成......................................................................................................................................................................63
11.4.5 クラスタファイル・システム ...............................................................................................................................................63
11.4.6 アプリケーション・プログラミング・インタフェース ..........................................................................................................63
11.5 VERITAS Clusters - 比較 ...........................................................................................................................................................63
11.5.1 クラスタ構成オプション ....................................................................................................................................................63
11.5.2 管理性 ................................................................................................................................................................................64
11.5.3 クラスタ・コミュニケーション............................................................................................................................................64
11.5.4 リソース構成......................................................................................................................................................................64
11.5.5 クラスタ・ファイル・システム .............................................................................................................................................64
11.5.6 アプリケーション・プログラミング・インタフェース ..........................................................................................................64
11.6 追加情報 ...................................................................................................................................................................................64
12 追加リソース...................................................................................................................................................................................66
A Cコンパイラ・オプションの比較.......................................................................................................................................................67
B C++コンパイラ・オプションの比較 ..................................................................................................................................................71
C リンカオプションの比較 ..................................................................................................................................................................75
D Makeのサフィックス規則..................................................................................................................................................................77
E ポーティング・チェックリスト ............................................................................................................................................................81
4
H+I_マイグレ4C_P5 06.2.14 7:29 PM ページ 5
インテル® Itanium® 2 プロセッサ搭載 HP Integrity サーバが選ばれる理由
■要求の厳しいエンタープライズ・アプリケーションやテクニカル・アプリケーションに最適なインテル® Itanium® 2 プロセッサ
インテル® Itanium® 2 プロセッサは、非標準のRISCソリューションをしのぐ費用対効果、柔軟性、選択の幅を提供します。インテル®
Itanium® 2 プロセッサは、エンタープライズ・レベルのアプリケーションやデータベースで求められる高度な並列処理機能、スケーラ
ビリティ、信頼性を備えています。
現在、インテル® Itanium® アーキテクチャは、世界中のハードウェア・ベンダから多様な構成のシステムがリリースされており、各種の
オペレーティング・システム上で 5,000種類以上のアプリケーションをサポートしています。スーパーコンピュータTOP500
（www.top500.org）
にランキングされている79のシステム、さらにFortune 100社のうち半数を超える企業のエンドユーザ・システム
が、インテル® Itanium® 2 プロセッサをベースにしたソリューションで稼動しています。今こそ、エンタープライズおよび高性能コンピュー
ティング環境にインテル® Itanium® 2 プロセッサを搭載したシステムを導入し、卓越したパフォーマンスと将来に向けた柔軟性を獲得
するチャンスです。
■幅広いラインアップでインテル® Itanium® 2 プロセッサの能力を最大限に引き出すHP Integrityサーバ
HP Integrityサーバは、インテル® Itanium® 2 プロセッサによる圧倒的な処理性能を手に入れつつ、ミッションクリティカル・システムで豊富
な実績を誇るUNIXサーバ「HP 9000サーバ」で培った、高信頼性と高可用性のためのあらゆるテクノロジーを継承しています。
そして現在のようなビジネスの状況がめまぐるしく変化する状況においても、HP Integrityサーバは高い仮想化技術により柔軟に対
応します。仮想化技術とはサーバの処理能力をプール化し、必要なときに動的にしかも自動的に割り当てる技術。この高い仮想化技
術により、変化に対しての柔軟性と俊敏性という競争力を企業は手にすることができます
サポートするオペレーティング・システムは、LinuxをはじめWindows、HP-UXの3つに対応。オペレーティング・システムの制約にとら
われない柔軟なシステム基盤を構築することで、企業は、そのときの状況に応じた最適なシステムを手に入れることができます。ま
た、実際の運用では仮想化された環境をどう管理するのかが問題になります。こういった問題には、HP Systems Insight Managerが
プラットフォーム、オペレーティング・システム環境に依存しないシームレスな管理を実現します。
HP Integrity サーバは、これらの特長によりお客様のビジネス価値を最大化するソリューションを提供します。
rx1620
rx2620
rx4640
rx7620
rx8620
Superdome
日本ヒューレット・パッカード株式会社とインテル株式会社は、IntegrityとItanium® Architectureを推進
しています。
5
H+I_マイグレ4C_P5 06.2.14 7:29 PM ページ 6
Solaris™ 向けLinux® ポーティングガイド
本書は，Sun Solaris™ からLinux® にアプリケーションを移行する際に役立つ情報をまとめたものです。
© 2005 Hewlett-Packard Development Company, L.P.
Confidential computer software. Valid license from HP required for possession, use, or copying. Consistent with FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government
under vendor’s standard commercial license.
本書に含まれる情報は，事前の通知なしに変更されることがあります。HPは，製品およびサービスの保証書で保証する内容以外には，
一切の保証はいたしません。本書の内容が，保証内容の拡張を意味することは一切ありません。HPは，本書に含まれる技術的あるい
は編集上の誤りや欠落に対して一切の責任を負いません。
GNUは，Free Software Foundationの商標です。
インテル、Intel ロゴ、Intel Inside、Intel Inside ロゴ、インテル Xeon、Itanium、およびPentiumはアメリカ合衆国および他の国におけるインテル コーポ
レーションまたはその子会社の商標または登録商標です。
Javaは，Sun Microsystems, Inc.の登録商標です。
Linuxは，米国におけるLinus Torvalds氏の登録商標です。
MicrosoftおよびWindowsは，米国におけるMicrosoft Corporationの登録商標です。
Oracleは，米国におけるOracle Corporationの登録商標です。
POSIXおよびIEEEは，Institute of Electricaland Electronic Engineers, Inc.の登録商標です。
SunおよびSolarisは，米国におけるSun Microsystems, Inc.の商標です。
SPARCは，米国におけるSPARC International, Inc.の登録商標です。
UNIXは，The Open Groupの登録商標です。
6
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 7
本ガイドについて
本ガイドは，Sun Solaris™ からLinux® へのポーティングに関する情報とヒントを提供するものであり，Solaris 8およびSolaris 9から，イ
ンテル® プロセッサを搭載したHP ProLiantとHP Integrityサーバ上のLinux Standard Base（LSB）1.3以降に準拠したLinuxディストリ
ビューションへ32ビットおよび64ビットのアプリケーションを移行することに主眼を置いた内容となっています。なお，本ガイドにお
いて，限定的なリリース識別子を示すことなくLinuxに言及している場合は，あらゆるLSB準拠のLinuxディストリビューションが含ま
れます。
HPはオープン・システムおよびマルチプラットフォーム環境の活用を支援するために本ガイドを制作しました。HPの提供するテクニ
において入手可能です。
カル・アップデートおよび正誤表は，DSPP Linux Developer Webサイト
（www.hp.com/go/linuxdev）
対象読者
本ガイドは，SolarisアプリケーションをLinuxにポーティングすることに関心をお持ちのアプリケーション開発者，技術管理者およびプ
ロダクト・マネージャの方々のための参考文献として、計画策定の支援を目的としています。第2章および第3章は，ポーティング作業の
概要とLinuxアプリケーションの開発環境に関するもので，組織内の全開発者および主要な意思決定者向けの内容となっています。ま
た，残りの章では，ポーティングにおける特定の分野向けの詳細な技術情報を提供します。これらの章は，アプリケーション開発およ
びSolaris上でご使用になっているアプリケーションの技術的側面に関する基本的な理解を備えた方々を対象としています。
SolarisからLinuxへのアプリケーション移行の問題点や落とし穴に関するより専門的なレベルの比較および議論を目的とした文書の入手
も可能です。
HPが提供するこれらの文書および他の移行ツールは，
DSPP Linux Developer Webサイト
（www.hp.com/go/linuxdev）
www.hp.com/go/linuxをご覧ください。
から入手できます。
HPが提供するLinuxソリューションに関する情報については，
構成
本ガイドの構成は以下のとおりです。
第1章
標準規格およびオープン・ソース・システムの意義
第2章
ポーティング過程の概要
第3章
Linuxアプリケーション開発環境の解説
第4章
SunおよびGNUコンパイラの比較
第5章
SolarisおよびLinuxシステムにおけるリンカとローダの比較
第6章
ポーティング作業に役立つその他の開発ツールについて
第7章
システム・ライブラリ，APIおよび実行時環境の違いについて
第8章
マルチスレッド化されたアプリケーションのポーティングに関する情報
第9章
ビッグエンディアンおよびリトルエンディアン・システムにおけるデータ記憶の相違について
第10章
32ビットおよび64ビット・アプリケーション開発の比較
第11章
複数クラスタ環境の機能比較
第12章
その他のポーティングリソースの紹介
付録A
GNU Cコンパイラ・オプションに対するSun ONE Studio Cコンパイラのマッピング
付録B
GNU C++コンパイラ・オプションに対するSun ONE Studio C++コンパイラのマッピング
付録C
GNUリンカ・オプションに対するSolarisリンカのマッピング
付録D
GNU makeサフィックス規則に対するSolaris makeのマッピング
付録E
基本的なポーティング情報のチェックリスト
関連情報
HP Linux Developer Webサイト
（www.hp.com/go/linuxdev）では，2つの開発環境に関する深いレベルでの比較や，移行に際して
の潜在的な落とし穴などを内容とする
「Migrating from Solaris to Linux（SolarisからLinuxへの移行）
」をはじめ，関連文書や移行のための
ツールを提供しています。
また，計画策定，ポーティングおよび開発用のツールを含むSolaris-to-Linuxアプリケーション移行ツール一式も開発済みです。このツー
ル群は，SolarisアプリケーションをLinuxにポーティングすることを考えているすべての方々の必需品です。
7
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 8
HP Solaris-to-Linuxアプリケーション移行ツールに関するより詳細な情報については，第3章を参照ください。また，SolarisからLinux
へのアプリケーションのポーティングに役立つリソースのリストについては，第12章を参照ください。
出版履歴
本書は，
『Solaris to Linux Porting Guide（July 2005, Edition1）
（
』英語）をもとに日本語で提供するものです。
英語の文書はwww.hp.com/go/linuxdevから入手可能です。文書の版はガイドの出版年月日によって表され，新しい版を出版する
際には，出版年月日を変更します。
版番号
出版年月日
コメント
第1版
2005年7月
最初のリリース
（英語）
表記法
本ガイドでは以下の表記法を使用します。
%
パーセント記号は，Cシェルのシステム・プロンプトを表します。ドル記号は，Bourneシェル，Kornシェル，およびPOSIX
$
シェルの場合のシステム・プロンプトを表します。
%cat
対話式の例における太字（ボールド体）は，ユーザが入力する文字を示します。
file
イタリック体（斜体）は，変数値，プレースホルダ，および関数の引数名を示します。
⋮
垂直の反復記号は，実際には存在する例の一部が省略されていることを示します。
…
構文定義において，水平の反復記号は，前の項目を1回以上繰り返して使用できることを示します。
cat（1）
manページへの参照は，該当するセクション番号をカッコ内に示します。たとえば，cat（1）は，catコマンドについての情報
が，manページのセクション1に記載されていることを示します。
[ | ]
構文定義において，大カッコはオプションの項目を示し，中カッコは必須項目を示します。大カッコまたは中カッコの中の項
{ | }
目を縦線で区切っている場合は，そこに記されている項目の中から1つの項目を選択することを示します。
さらに，以下の表記法および用語も使用します。
• 10進定数は，10進数字（0-9）の列で構成され，先頭には0を付けません。
• 16進定数は，先頭が0x（または0X）で始まる16進数字（0-9abcdefABCDEF）の列で構成されます。特に断らない限り，これらの定数は
最初の字句の数字が最上位の数字であるように表現されます（リトル・エンディアンのバイト順）
。
• 8進定数は，先頭が0で始まる8進数字（0-7）の列で構成されます。特に断らない限り，8進定数はリトル・エンディアンのバイト順で表
現されます。
• 2進定数は2進数字（0-1）の列で構成され，後にbを付けます。特に断らない限り，2進定数はリトル・エンディアンのビット順とリトル・
エンディアンのバイト順で表現されます。
• バイトは8ビットと定義します。
8
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 9
1 標準規格およびオープンソース・システムの意義
Linuxは，そのTCOの低さと，他のオペレーティング・システムとの類似性により，既存環境との統合を実現しつつコストを削減できる，
企業向けオペレーティング・システムとして理想的な選択肢の1つにまで成長しています。Linuxは，オープンソースに加えて，今日の市
場セグメントに応じた多彩な商用ソリューションを提供しているという特長を備えています。SolarisからLinuxへ移行することにより，
デプロイメントの選択肢が増えると同時に，TCOを削減することも可能になります。さまざまなプラットホーム上でLinuxは利用できる
ため，オペレーティング・システムがサポートされているプラットフォームを気にすることなく，ユーザはどのようにソリューションを導
入するか決定できます。
HPは，Linuxを利用したオープンソースおよび商用のソリューションを対象にLinux Reference Architecture（LRA）※1を用意しています。LRA
は，HP ProLiantおよびHP Integrity両サーバへのLinux導入のために認定，サポートされたソリューションを提供します。また，LRAと
同様，Linuxにおける開発環境にもオープンソースおよび商用の両選択肢があります。数多くの選択肢がある中でLinuxへの取り組みを
始めようとすることは，気の重いことかもしれません。HPは，豊富な経験をもとに移行に際してユーザが遭遇するあらゆる問題を容
易に解決できるようにするお手伝いをします。
※1 www.hp.com/go/lra
1.1 はじめに
本ガイドでは，SolarisからLinuxにアプリケーションをポーティングする作業の概要を解説します。HPはアプリケーションのポー
ティングに役立つリソースを数多く提供しています。本ガイドでは，そのうちのいくつかをご紹介します。ポーティングの対象プ
ラットホームには，ベンダ独自のLinuxインプリメンテーションではなく，Linux Standard Base（LSB）準拠を認定されたインプリ
メンテーションを利用してください。これにより，さまざまなLinuxベンダおよびバーション間でも，アプリケーションに最大限の
移植性を持たせることができます。
1.2 LinuxとHP
HPはLinuxの誕生当時からこのシステムとの関わり合いを持っており，それは今日も続いています。最初の64ビットLinuxカーネル
のインプリメンテーションを担った開発者の多くはHPの従業員でした。また，HPはLinuxカーネルおよびその他のコア・コンポー
ネントの開発コミュニティにおいても，リーダーシップをとり続けています。HPのLinux R&D専門研究室は20年以上にもわたる
UNIX® ライブラリやデバイス・ドライバの開発経験を有しており，HPのワークステーションやサーバ上でLinuxを実行可能にする作業
やテスト，サポートを担当しています。HPは，導入当初から適切に稼働する，テストされた確かなソリューションを提供しています。
HPは業界をリードするハードウェアおよびソフトウェアを使ったLinuxソリューションを提供すると共に，主要なアプリケーション・
ソフトウェア・サプライヤと緊密な協力関係を結んでいます。HPはLinuxのパートナーとして，顧客やISVを対象とした幅広いサー
ビスとサポートに関する専門知識に加え，Linuxのための最先端の管理技術およびクラスタ技術を提供します。HPをご利用いただ
くことにより，ハードウェアとソフトウェアの両方のサポートを1つの組織から得ることが可能になります。HPとLinuxに関するより
詳細な情報についてはwww.hp.com/go/linuxをご覧ください。
Linuxへの取り組みに加えて，HPはオープンソース・コミュニティにおいても積極的に活動を行っています。HPはオープン・コンピ
ューティングの先駆者としての歴史を有しており，他のどの大手ハードウェア・ベンダーよりも長期間にわたってオープンソース・
コミュニティと関わってきました。HPの研究室は数多くのよく知られたオープンソース・アプリケーションに貢献しており，そのう
ちのいくつかはopensource.hp.comから入手可能です。
HPは，顧客企業の成功，そして，企業でのLinux普及に最大の努力を払っています。2003年10月1日，HPは，SCOからの法的措置
に対して，登録を行った顧客がHPから補償を受けることができるプログラムを導入しました。このプログラムは，顧客がLinuxの
導入計画を進められるよう，顧客を保護し，無用なリスクや混乱をなくすことを目的とするものです。詳細については，
www.hp.com/go/linuxprotectionのLinux補償プログラムを参照ください。
1.3 なぜLinuxを使うのか？
Linuxは，PDA（www.handhelds.orgを参照ください）から企業レベルのサーバ（ www.hp.com/go/proliantlinuxおよび
www.hp.com/go/integritylinuxを参照ください）にいたるまであらゆる場所で利用される人気の高いオペレーティング・シス
テムになりました。Linuxが備えるオープンであるという特性によって，ユーザはそれぞれの目的に合わせてコンポーネントを簡
単に追加・削除することが可能です。Linux人気の理由の大部分は，そのインタフェースの親しみやすさと機能によると考えられて
います。コマンドラインはUNIXユーザに見慣れたインタフェースを提供し，同時にグラフィカル・インタフェースはMicrosoft®
Windows®ユーザにおなじみのインタフェースを提供します。複数のインタフェースやファイル共有などの各種システム・サービス
を提供することにより，LinuxはWindowsやUNIXの代替となる環境を低価格で実現します。
LinuxのTCOの低さは，エッジ・サーバおよびエンタープライズサーバとして魅力的です。たとえば，ロイター・マーケット・データ・
システム
（RMDS）を導入するためにSunからLinuxサーバへ移行することによって，インフラコストに著しい変化をもたらすことが
9
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 10
できます※2。www.hp.com/wwsolutions/linux/resourcecentre.htmlにあるLinux TCO計算機のリンクをたどり，どれほど
節約できるのかをご自分の目でお確かめください。
最も重要なのは，数多くのハードウェア・プラットホーム上でLinuxを利用できるという点です。その結果，オペレーティング・シス
テムが利用できるかどうかに気を使うことなく，柔軟にハードウェア・ベンダーを選択し，パフォーマンスやアプリケーションの有
無をベースにして選択を行うことが可能となりました。最近のベンチマークでは，Linuxクラスタ構成でOracle®が稼働するHP
Integrityサーバが，100万TPC-C以上というTPC-Cの新記録を達成しました。これは，わずか5.52ドル/tpmC という業界内でも最
高のTPC-C数です※3。Linuxが稼働するHP ProLiantサーバは，Solarisよりも53%も低価格で，31%のパフォーマンス向上をもたら
し，Oracle Application Serverとしては業界内で最も低いTCOを達成しています※4。HPおよびLinuxの最新ベンチマークについて
は，www.hp.com/go/linuxbenchmarksを参照ください。
※2 出典：“An Economic Analysis of Reuters Market Data System Migration Using RedHat/Intel/HP Based Platform”, www.rmds-linux.com
※3 出典：Transaction Processing Council (TPC), www.tpc.org
※4 出典：SPECjAppServer 2002 results, www.spec.org
1.4 なぜLinux Standard Base（LSB）を使用するのか？
Linux人気の急上昇は，コアとなるLinuxカーネルをベースにしたさまざまな独立ディストリビューションの登場につながりました。
これらのディストリビューションはすべてLinuxであるものの，それぞれには微妙な違いがあります。その結果，Linuxをサポートす
るということは，限られたディストリビューションのみをサポートすることを意味するようになり，それぞれのディストリビューショ
ンは個別に認定を受ける必要がありました。
HPはFree Standards Group（ www.freestandards.org）の創設スポンサーであり，Linuxに標準規格を制定しようとしている
Linux Standard Base（LSB）を推進するリーダーです。LSBは，LSBに準拠したディストリビューションであれば，共通のソフトウェ
ア・アプリケーションが稼働することを目的としています。LSBおよびLSB準拠のディストリビューションを導入することにより，
Linuxにアプリケーションを導入する際に必要だった，費用のかかるディストリビューション毎の認証作業は不要になります。LSB
環境で認証を受けることにより，LSBに準拠したあらゆるディストリビューションにおいて，そのアプリケーションが正しく稼働す
ることを保証できるようになります。Linux Standard Baseの詳細については，www.linuxbase.orgを参照ください。
Free Standards Groupは，Linux Standard Baseを利用したアプリケーション開発に関する書籍を出版しています。詳細について
は，www.freestandards.orgを参照ください。オンラインでの閲覧も可能です。
10
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 11
2 ポーティング・プロセスの概要
本章では，SolarisからLinuxへのポーティングに関する情報を提供します。なお，本章は開発者，技術管理者およびプロダクト・マネー
ジャの方々を対象としており，読者はSolarisアプリケーションおよびソフトウェアの開発プロセスについて若干の技術的知識を持って
いることを前提としています。
2.1 ポーティングのプロセス
ポーティングとは，あるオペレーティング・システムやコンピュータ・アーキテクチャで実行されているソフトウェアを，別のオペ
レーティング・システムやコンピュータ・アーキテクチャで実行できるようにする作業のことです。オペレーティング・システムや
アーキテクチャが極めて似通っている場合，あるいはソフトウェアのソースコードがポーティングを考慮して設計されている場合，
この作業は容易です。ソースを再コンパイルして，新しいプログラムが元のプログラムと同様に動作することを確認する検証テ
ストを行うだけで済みます。しかし，アプリケーションのポーティングがすべて，この単純なモデルに当てはまるわけでありませ
ん。通常，ポーティング作業はいくつかの段階を踏む必要があります。本章ではこれについて説明します。
POSIX.1，UNIX 95，およびUNIX 98などの標準規格が登場し，その適用が進んだことで多様なアプリケーション・プログラム・イ
ンタフェース
（API）は徐々に収束していきました。この結果，ポーティングの難易度は大幅に下がりましたが，ポーティング作業そ
のものが完全に不要になったわけではありません。アプリケーションのポーティングを行う際には，一般に2つの問題に遭遇する
可能性があります。
• 第1の問題は，標準規格への準拠とは，既存のコードを可能な限り標準規格に近づけるという現在進行中の作業であるという点
です。たとえ，高いレベルでの適合性が達成できたとしても，標準規格では曖昧にしか規定されていない箇所で誰かがポーティ
ングをする際に不手際を起こしたり，適合スイートに厳密に規定されていなものが2つのプラットホームに異なる方法でインプ
リメント
（実装）されたりしたために，矛盾点が残ってしまうというケースもしばしば見受けられます。
• 第2の問題は，標準規格において，いくつかの動作については意図的に未定義のまま残しているという点です。特定のベンダが実
装している未定義の動作，あるいは標準規格にはないベンダ独自の拡張に依存しているアプリケーションについては，ポーティン
グに際してさらなる労力が必要となります。
アプリケーションを新たなプラットホームにポーティングする際に必要とされる作業の一般的な手順は以下のとおりです。
1. 以下の事項を含む製品について開発環境の依存性を確認します。
ツールの依存性
例
ソースコード管理
SCCS，RCS，CVS，Subversion
ビルド環境
Make，xmkmf，Antおよび依存しているツール
インストール
tar，スクリプト言語，packageまたはRPM
アプリケーション管理
SNMP機器，PAM機器，カーネル調整
サードパーティ製品
ライブラリ，アプリケーション・サーバ，アプリケーション・コンプリータ
開発
コンパイラ，デバッガ，エディタおよびIDE
プロファイリングおよびパフォーマンス
Prof，gprofおよびHP Caliper
テスト
スクリプト言語，diff, expectおよびテストフレームワーク
Documentation
TeX，javadoc，DocBook，OpenOffice.org，その他のアプリケーション
2. アプリケーションのポーティング・プロジェクトに影響を及ぼす可能性のあるオペレーティング・システムの機能，クラスタの機
能，ランタイム・ライブラリ，およびサードパーティ製品のバージョンの相違によって見込まれる影響を確認，評価します。
3. 新たな対象システムに製品を導入した結果，エンドユーザがどのような影響を受けるかを確認し，計画を策定します。この作業
にはデータ変換や移行期間のアップタイム（稼働時間）サポート，製品インストールの変更，製品管理の変更，
トレーニングなど
に関する必要性の確認が含まれる場合もあります。
4. アプリケーションのポーティングを行うチームに向けた文書作成やトレーニングの必要性を確認し，対応策を講じます。
5. 製品の開発環境のポーティングを行い，必要に応じて開発の手順を適応させます。
6. アプリケーションのソースコードを整理します。可能な箇所については，アーキテクチャへの依存性および標準に準拠していな
い部分を探し出し，取り除きます。
7. 新たな対象プラットホームをサポートするために，アプリケーション・ソースコードを拡張します。なお，この作業には条件付き
モジュールおよび条件付きコードの追加（高級言語およびアセンブラ・コードの両方）が含まれます。また，可能であれば，アー
キテクチャへの依存性を排除するために，汎用的なインプリメンテーション
（実装）を行います。
8. ソースコードをコンパイルします。潜在的な問題を検出するために，なるべくANSI，またはより厳密なエラー・チェック用スイッチ
を使用してください。コンパイル時に明らかになった問題をすべて修正します。
9. 広範囲のテスト・ケースでアプリケーションを実行して，あらゆる不具合をデバッグし，実行時に検出された問題をすべて修正
します。
10.必要に応じてコードを再コンパイルし，上記処理を繰り返します。
11
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 12
2.2 ポーティングの問題点と推奨事項
一般的に，言語，コーディング，ランタイムの標準規格に対しアプリケーション・ソースコードの準拠している度合いが高いほど，必
要とされる変更は少なくなります。ポーティングの容易な，いわゆる
「行儀のいい」Solarisアプリケーションの特性を以下に示します。
• IEEE Standard 1003.1:1996（POSIX.1）やSingle UNIX Specificationsなどの業界標準に準拠するように，
ドキュメントに記載された
インタフェースのみを使用しているソースコード。
• 適切なANSI/ISO言語の標準規格に準拠したソースコード。
• 複数のプラットホームへの移植性をすでに備えたソースコード。
アプリケーションが以下の特性のいずれかを備えている場合には，ソースコードの変更が必要となります。
• アセンブリのソース・モジュールまたはインライン・アセンブラ指示文を含むソースコード。
• Sunのハードウェアの特定の知識（例：ページ・サイズに関するハードコードされた条件）やSolarisオペレーティング・システムの知
識（例：ファイルシステムのレイアウト）を利用したソースコード。
• エンディアン固有のデータに依存するソースコード。
• ドキュメントに記載されていないSolarisの機能を利用したソースコード。
• Solarisカーネル・モードでリンクされ，稼働するソースコード。これにはカーネル・モジュールおよびデバイス・ドライバが含まれ
ます。
詳細情報，ツールおよび手法については，以下のウェブサイトを参照ください。
• www.hp.com/go/linuxdev
• devresource.hp.com/linux
2.3 その他の留意事項
アプリケーションをポーティングするための計画段階においては，アプリケーションを利用する顧客に対する保守，サポートの負
担を検討する必要があります。多くの場合，顧客サポートの必要性は移行期間に比例して増加します。新しい手順，あるいは顧客
主導で修正された手順によっては，サポート・スタッフに特殊な要求が生じる可能性があります。アプリケーションの新しい改訂
版をサポートするために，既存のリモート診断の技法やツールに変更を加える必要性が生じる可能性もあります。また，顧客やサ
ポート・スタッフのトレーニングが必要になるかもしれません。
新たにポーティングされたアプリケーションを配備する段階では，以下の点を考慮してください。
• 承認テストおよびアプリケーションの可用性/アップタイム
（稼働時間）の計画，管理が必要となる可能性があります。
• 管理者やオペレータ向けの文書の作成，エンドユーザ向けの文書の作成，およびトレーニングなどが必要になる可能性もあります。
• 顧客がポーティングに関連する問題に遭遇した場合でも，既知の基準点に戻れるように，付加的なシステム・バックアップが必要
となる可能性があります。
• アプリケーションの複数のバージョンを並列的に稼働させる場合は，アプリケーション環境（ハードウェア，ソフトウェア，あるい
は両方）の違いの程度，ビジネスに対するアプリケーションの重要性，人員の数，およびアプリケーションが影響を及ぼす情報の
量によって，その難易度は違ってきます。
• アプリケーションの変更により，顧客が保有する，ビジネスあるいは法的な理由から必要となるアーカイブが無効になってしまっ
た場合には，バックアップ・メディアへのアクセス確保など，余分な作業が必要となる可能性があります。
2.4 オペレーティング・システムのバージョン調査
本ガイドの情報は，ポーティングするSolarisアプリケーションが，SPARCハードウェアで稼働するSolaris 8またはSolaris 9向けに開発
されていることを前提としています。ただし，ポーティングするアプリケーションが他のバージョンのSolarisまたはSunハードウェ
アをベースにしている場合でも，本ガイドの大部分の内容は適用可能です。
本ガイドは，
対象とするLinuxプラットホームが，
Linux Standards Base（LSB）
バージョン1.3以降に準拠すると認定されていることを
前提としています。
これにより，
異なるLinuxベンダおよびバージョン間であっても，
アプリケーションの最大の移植性を得ることが可能
www.opengroup.org/lsb/cert/cert_prodlist.tpl
となります。
LSB認定を受けたLinuxディストリビューションに関する情報については，
をご覧ください。
以下の製品の情報も含まれています。
• SUSE Linux Enterprise Server 9（SLES 9）
• SUSE Linux Enterprise Server 8（SLES 8）
• Red Hat Enterprise Linux 3（RHEL 3）
Linuxユーザおよびアプリケーションは，lsb_release（1）
コマンドでLinuxディストリビューションのLSBバージョン情報を確認できま
す。uname（1）
コマンドでは，返されるのがカーネル・バージョン情報のみである点にご注意ください。詳細については，lsb_release（
のmanページを参照ください。
LSBに関する詳細については，www.linuxbase.orgおよびwww.freestandards.orgを参照ください。
Free Standards Groupでは，LSBを利用したアプリケーション開発を解説する「Building Applications with the Linux Standard
12
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 13
Base」
という書籍を出版しています。詳細については，lsbbook.gforge.freestandards.org/lsbbook.htmlを参照ください。
2.5 ポーティングとコーディングの方法
本ガイドで紹介しているコーディング方法は，特定のベンダや，SolarisあるいはLinuxオペレーティング・システムに依存したもので
はありません。単純に良質で，標準的なコーディング方法を採用しています。同様のスタンスで説明している書籍がいくつかあり
ますが，お勧めする書籍は以下のとおりです。
• The C Programming Language, Second Edition, by Brian W. Kernighan and Dennis M. Ritchie; Prentice-Hall Software Series,
Prentice-Hall, Inc.
• C Traps and Pitfalls, by Andrew Koenig; Addison-Wesley Publishing Company
• C++ Programming Language, by Bjarne Stroustrup; Addison-Wesley Publishing Company
• C++ Primer, by Stanley B. Lippman, Josée Lajoie, Barbara E. Moo; Addison-Wesley Professional
13
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 14
3 開発環境の概要
Linux環境では，オープンソースおよび商用の両方を含めて，豊富なアプリケーション開発ツールが提供されています。本章ではLinux
開発環境の概要を解説します。コンパイラ，リンカ，およびその他の開発ツールに関するより詳細な情報は，以降の章で説明します。
3.1 コンパイラの概要
Linux開発者は，主にGNU Compiler Collection（GCC）を利用していますが，他の無料および商用Linuxコンパイラも利用可能です。た
とえば，インテルはLinux向けにC，C++，およびFortranコンパイラを用意しています。これらのインテル製コンパイラは，非営利
目的の場合，無料で使用できます。しかし営利目的の使用の場合はライセンスの取得が必要です。なお，これらのコンパイラでは
IA-32およびインテル® Itanium® ファミリーベースのシステムに高度に最適化された出力が得られます。
GCCはほとんどのLinuxディストリビューションに収録されています。
3.1.1 Cコンパイラ
Sun Forte，GNUおよびインテル® CコンパイラはすべてC99の一部の機能に加え，C89の言語機能をサポートしています。GNU Cコ
ンパイラがサポートしているC99の機能の詳細については，http://gcc.gnu.org/gcc-3.3/c99status.html を参照ください。
ANSI C規格に厳密に準拠して書かれたコードは最高レベルの移植性を備え，さまざまなプラットホーム上で最も一貫性の高い動
作を実現します。
SolarisからLinuxへCのソースコードをポーティングする際の難関のひとつは，makefileで使用されているコンパイラ・オプションの
更新です。SunとLinuxコンパイラの相異点に関する詳細は，本ガイドの第4章に説明があります。Cコンパイラ・オプションのSun C
とgcc間のマッピングについては，付録Aを参照ください。また，Solaris-to-Linux Porting Kit（SLPK）のご利用をご検討ください。
詳細については，セクション3.5.3を参照ください。
3.1.2 C++コンパイラ
Sun，GNU G++，およびインテルのC++コンパイラは，すべて ANSI/ISO C++国際標準であるISO/IEC 14882:1998に準拠してい
ます。Sun，G++，インテル® コンパイラの最新バージョンで使用されているiostreamのデフォルトのインプリメンテーション（実
装）およびStandard Template Library（STL）は，1998 C++標準に準拠しています。拡張および下位互換性を含むG++実行時ライ
ブラリの詳細については，gcc.gnu.org/onlinedocs/libstdc++/faq/を参照ください。
C++コンパイラに関する詳細は，本ガイドの第4章で説明しています。G++コンパイラ・オプションに対するSunのマッピング
については，本ガイドの付録Bを参照ください。
“Intel® Compilers for Linux: Compatibility with GNU
インテル® コンパイラとGCCコンパイラ間の互換性に関する情報については，
Compilers”
（www.intel.com/software/products/compilers/techtopics/ LinuxCompilersCompatibility.htm）を参照
ください。
3.1.3 Java
LinuxのJava™は，アプリケーションを開発，導入するための安定した堅固なプラットホームを提供しており，ほとんどのLinuxディ
ストリビューションに収録されています。さまざまなベンダーが，32ビットおよび64ビット・システム上で利用できる，Linux向けの
Java開発キットを提供しています。必要に応じて，さまざまなインプリメンテーションが利用可能です※1。
• Sunでは，Linux用の開発キットおよびJava Virtual Machine（JVM）を提供しています。現在提供されている最新バージョンは5.0
です。IA-32，インテル® EM64Tなど，各Linuxプラットホームで利用可能な32ビットおよび64ビットのLinux版をダウンロードできます
詳細については，java.sun.com/j2se/を参照ください。
• IBMでは，IBM Developer Kit for Linuxを提供しています。このキットには，ジャストインタイム
（JIT）
コンパイラと，頻繁に呼び出され
るメソッドのためだけにJITコンパイラを利用するMixed Mode Interpreterが含まれています。詳細については，ibm.com/java/
をご参照ください。
• BEAもLinuxプラットホーム向けに信頼性の高いJVMを提供しているベンダのひとつです。BEA JRockit JVMは，JITコンパイル，
独自の最適化，スレッド管理，および適応的メモリ管理を提供します。詳細については，www.bea.com/jrockitを参照ください。
• BlackdownもLinux版のJDKを開発・配布していますが，BlackdownのJDKはここで取り上げた他のツールと比べ，数バージョン遅
れているという傾向が見られます。詳細については，www.blackdown.orgを参照ください。
この他にも，Linuxプラットホーム向けのJava開発ツールとして，GNU Compiler for Java（GCJ）
（gcc.gnu.org/java/）がありま
す。GCCに含まれるGCJは，JavaのソースコードをJavaのバイトコード，あるいは直接ネイティブな機械コードにコンパイルでき
る，移植性および最適化品質の高いAhead-of-Time（AOT）
コンパイラです。GCJの実行時ライブラリであるlibgcjライブラリは，コ
ア・クラス・ライブラリ，ガベージコレクタおよびバイトコード・インタプリタを提供します。このバイトコード・インタプリタはクラ
ス・ファイルを動的にロードし，インタプリトすることが可能なため，コンパイルされたコードとインタプリトされたコードが混在す
るアプリケーションを作成することも可能です。詳細については，gcc.gnu.org/javaを参照ください。
※1 HPはオプションのリストを提供しているだけであり，特定のベンダーを支持するものではありません。
14
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 15
3.1.4 Fortran
GNU Fortranは，現時点では標準のFORTRAN 77のみをサポートしています。しかし，Fortran 95のコンパイラも開発段階にあり，
GCC 4.0.0において部分的なインプリメンテーションが実施されています。詳細については，gcc.gnu.org/fortranおよび
www.g95.orgを参照ください。GNU Fortranは，ほとんどのLinuxディストリビューションに収録されています。
アプリケーションがFortran標準のより新しいバージョンで提供される機能に依存している場合は，コンパイラの商用インプリメン
テーションを購入する必要があります。必要に応じて，下記のようなインプリメンテーションを利用できます※2。
• Intel® Fortran Compiler（Fortran 95）
。詳細については，www.intel.com/software/products/compilers/flin/を参照ください。
• Absoft Development Toolsの Pro Fortran（ F77，F90お よ び F95モ ー ド を 備 え た Fortran 95）。 詳 細 に つ い て は ，
www.absoft.com/ Products/Compilers/Fortran/Linux/AMD64/Linux64.htmlを参照ください。
• Portland GroupのF77，F90/F95およびHPF。詳細については，www.pgroup.com/products/serverindex.htmを参照くだ
さい。
• PathscaleのF77，F90およびF95。詳細については，www.pathscale.com./ekopath.htmlを参照ください。
• Veridian SystemsのVAST/f90。詳細については，www.crescentbaysoftware.com/を参照ください。
※2 HPはオプションのリストを提供しているだけであり，特定のベンダーを支持するものではありません。
3.2 シェルとスクリプト言語の概要
Linuxでは，LinuxにポーティングされたSolarisアプリケーションの要求を満たす，数多くのシェルおよびスクリプト言語が用意され
ています。こうしたLinuxシェルおよびスクリプト言語の多くにはSolaris版も用意されているため，ポーティングを行うチームは，
Linuxへのポーティングを実施する前に，Solaris上でこれらのツールをテストできます。本セクションでは，一般的に利用されてい
るいくつかのLinuxシェルおよびスクリプト言語の概要を紹介し，より詳細な情報へのポインタを提供します。
なお，これらのシェルおよびスクリプト言語は，ほとんどのLinuxディストリビューションに収録されています。
3.2.1 シェル
多くのSolarisアプリケーションには，Bourne（sh）
，Korn（ksh）
，あるいは C Shell（csh）スクリプトのいずれかが含まれています。
これらのアプリケーションでは，シェルの方言を変更しなくともスクリプトを実行できる互換性のあるLinuxシェルが見つかるはず
です。たとえば，シェル・スクリプトおよびユーザがSolaris上でcshを使っている場合，LinuxではTurbo Cシェル（tcsh）を使用する
ことができます。
Linux上で新たなユーザ・アカウントを作成する場合，ほとんどのディストリビューションでは，Bourne Again SHell（bash）がデフォ
ルトのシェルとして設定されます。
Linuxシェルに関するより詳細な情報については，第6章に記述があります。
3.2.2 Awk
awkは，1970年代半ば，その開発者であるAlfred V. Aho, Peter J. Weinberger，Brian Kernighanの3人の頭文字を取って命名されまし
た。基本的に，awkは広範囲にわたるパターンマッチングを利用したレポート生成言語です。Linuxでは，いくつかのバージョンの
awkが利用できます。しかし，現在最も人気があるのはGNU awk（gawk）です。大部分のSolaris awkプログラムは，容易にGNU
awkにポーティングできるはずです。awkはPOSIXに必須であるため，Linuxシステムにはgawkがデフォルトでインストールされてい
ます。
gawk（1）
に関するより詳細な文書，ダウンロード，その他の情報については，www.gnu.org/software/gawk/gawk.htmlを参
照ください。
3.2.3 Perl
Perlは，当初UNIXのグルー言語として，またsed（1）およびawk（1）の代替になるものとして開発されました。Perlは，きわめて高い
移植性および拡張性を備えています。現在利用可能なPerlの最も一般的なバージョンはPerl 5です。Linuxにこれより新しいバー
ジョンが収録されている場合もありますが，SolarisとLinuxの両方で使用されているのはPerl 5です。Solaris上で書かれた大多数
のPerl 5プログラムは，最小限の手間でLinuxにポーティングできるはずです。多くのPerlスクリプトの中に存在する問題は，Perlのイ
ンタプリタの場所を記述したスクリプトの最初の行です。今日，ほとんどのシステムでは，システムの不可欠なパーツとして/usr/bin
にPerlがインストールされます。一般的な解決法は，env（1）
コマンドを使用してPATHの現在値からPerlの実行可能ファイルの場所
を探すことです。これは，スクリプトの中でPerlコードを定義している行を#!/usr/bin/perlから#!/bin/env perlに書き換えることで行う
ことができます。
大多数のLinuxディストリビューションには，より人気の高いPerlモジュールがいくつか含まれています。他のPerlモジュールが入手
できるかどうか確認するには，www.cpan.orgのComprehensive Perl Archive Network（CPAN）を参照ください。
Perlに関するより詳細な文書，ダウンロード，その他の情報については，www.perl.orgを参照ください。
3.2.4 Python
Pythonは，インタープリタ型，会話型のオブジェクト指向のプログラミング言語です。ほとんどのLinuxディストリビューションには
Pythonが同梱されています。Python 1とPython 2との間には若干の下位互換性の問題があります。Pythonのコードを，Solarisか
15
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 16
らLinuxへポーティングするにあたり，最良の手段は，Solarisプラットホーム上にインストールされているPythonと同じバージョン
のPythonをLinuxにもインストールすることです。システム上に複数のバージョンのPythonを混在させることも可能です。コードが
Pythonの特定のバージョンに依存している場合は，Pythonのより古いバージョンがLinux上で利用可能であり，Linuxプラットホーム
にインストールすることができます。
Pythonに関するより詳細な文書，ダウンロード，その他の情報については，www.python.orgを参照ください。
3.2.5 Tcl/Tk
Tcl/Tkは，非常に人気があったグラフィックス・プログラミング用のスクリプト言語ですが，近年は，Pythonの人気に取って代わら
れました。Tcl/Tkは安定しており，SolarisのTcl/Tkスクリプトは容易にLinuxにポーティングできるはずです。
Tcl/TkはほとんどのLinuxディストリビューションに収録されていますが，デフォルトではインストールされない可能性もあります。
Tcl/Tkに関するより詳細な文書，ダウンロード，その他の情報については，tcl.sourceforge.netを参照ください。
3.3 リンカとローダの概要
Solarisのリンカと実行時インタプリタ
（実行時リンカ，またはローダの別名でも知られている）機能の多くは，GNU binutilsのコン
ポーネントを利用することによりLinux上でも使用可能です。しかし，ビルドする製品，および実行時の製品構成の再検討と修正は，
ポーティング作業の一部としてあらかじめ考慮しておく必要があります。詳細についてはwww.gnu.org/software/binutils/を
参照ください。
HPは，リンカを直接呼び出すのではなく，コンパイラを使用して最終的なリンクを行うことをお勧めしています。特殊なオプショ
ンを付加する必要がある場合，あるいはより詳細なリンカ・レポート情報を見たい場合は，コンパイラ・オプション-Wl,option[,option]
を使用して，リンクエディタにオプションを引き渡します。詳細については，コンパイラ，manページのld（1）
，および付録Cをご覧
ください。
ライブラリの検索順序やシンボルの解決など，Linuxのリンカおよび実行時ローダに関する詳細な情報については，本ガイドの第5
章に記載があります。Linuxのリンカ・オプションに対するSolarisのマッピングについては，付録Cをご覧ください。
3.4 システム・ライブラリとAPI の概要
Solarisと同様，Linuxの開発環境でも，アーキテクチャに応じてILP32とLP64の両アドレス指定モデルがサポートされています。
ILP32では，integer, long, およびポインタ・データが32ビット長です。LP64では，longとポインタ・データは64ビットですが，
integerは異なります。
Linux環境では，POSIXやXOPEN標準など，多くのUNIX開発標準がサポートされています※3。Solaris固有のインタフェースは，通常
は利用できませんが，Linux環境を拡張し，Solarisのインタフェースや動作との互換性をある程度提供するパッケージが存在しま
す。このようなパッケージのひとつとして，HPで開発されたSolaris-compatible Threads Libraryがあります。詳細については，
www.sourceforge.net/projects/sctlを参照ください。
より詳細な情報および関連する情報は，セクション3.5.3，第6章および第7章に記載があります。
※3 Linuxは無料のオペレーティングシステムです。したがって，通常は，認定を得るための財源を持っていません。標準をサポートする場合，認定を必要としません。
3.5 その他の開発ツールの概要
以下のセクションでは，ポーティングを容易にしてくれる，その他のLinux開発ツールの概要をいくつかご紹介します。
3.5.1 ソースコードのバージョン管理ツール
ソフトウェア構成管理（SCM）
は，あらゆる開発作業において，変更点を追跡記録し，統合する手段として重要なツールです。Solaris
におけるデフォルトのソース管理手段はSource Code Control System（SCCS）です。ライセンス問題のため，Linuxにおいて
というSCCSと互換のあるソース管理
SCCSは提供されていません。しかし，Linuxでは，GNU CSSC（cssc.sourceforge.net）
ツールが提供されています。
Linuxで現在，デフォルトのソース管理ツールとなっているのは，Concurrent Versions System（CVS）です。CVSは，Control
System（RCS）をベースにしたネットワーク対応の管理システムであり，リモートの開発者を強く意識した開発環境向けに設計され
ています。
SubversionはCVSの機能に加えて，不分割なコミット，およびファイルやビルド生成物と同様にソースのディレクトリツリーをバー
ジョン化する機能など，多くの追加機能を含む新しいバージョン管理システムです。
，CVS（www.cvshome.org）
，およびSubversion（subversion.tigris.org）は，Solarisで
RCS（www.gnu.org/software/rcs）
もLinuxでも利用できます。また，IBM ClearCaseなどの商用のソース管理製品もLinuxで利用できます。
RCS，CVSおよびSubversionは，ほとんどのLinuxディストリビューションに収録されています。
バージョン管理ツールに関するより詳細な情報は，第6章に記載があります。
3.5.2 ビルドツール
SolarisとLinux上で最も一般的なビルドツールは，AntおよびMakeユーティリティの2つです。Antコマンドは高い拡張性を備えてお
16
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 17
り，数多くのJava開発プロジェクトで使用され，ほとんどのJava統合開発環境（IDE）でサポートされています。Antを利用すれば，
容易にLinuxにポーティングできる移植性の高いビルド環境を実現できます。
Solaris Makeユーティリティを使用している場合，ポーティングを担当するチームの課題は若干増えます。Linuxではthe GNU Makeを
使用しているためです。問題となる箇所として，文字列の代替として使用されるワイルドカード文字であるパーセント
（%）の使用，
$<マクロの使用，一部のサフィックス規則，などがあります。一般にこれらの問題は，特定さえできれば，容易に対応が可能です。
Linuxのデフォルトのシェルが異なっている可能性にも注意しなくてはなりません。ビルドに際して問題が発生した場合には，Makefile
が明示的にSHELLを定義する必要があります。
考慮に値する重要な選択肢が2つあります。第一の選択肢は，ポーティング・チームがSolaris上でGNU Makeを利用することです。
これにより，熟知した優れたソースやコンパイラ等々が使用できるSolarisホスト上で，ポーティング作業を開始することが可能に
なります。
考慮に値する第二の選択肢は，makefile内のポーティングに関する問題点，あるいは対象となるLinuxホスト上のSolaris互換のmake
環境に関する問題点などを特定するスキャナなどのアプリケーション・ポーティング・ツールを利用することです。上記の選択肢
のいずれかに関心があるなら，次のセクションを参照ください。HP Solaris-to-Linux binaryScanツール，Solaris-to-Linux Software
Transition Kit（STK）およびHP Solaris-to-Linux Porting Kit（SLPK）
に関する情報を記載しています。
AntおよびGNU Makeは，ほとんどのLinuxディストリビューションに収録されています。
ビルドツールに関するより詳細な情報は，第6章に記載があります。
3.5.3 アプリケーション移行ツール
一部のSolarisアプリケーションについては，SolarisとLinuxオペレーティングシステム間でAPIの互換性がないため，Linuxへのポー
ティングに困難が伴う場合があります。非互換性を特定し，解決を支援するために，HPはアプリケーション移行ソフトウェア・ツー
ルを開発しました。このツールを利用すれば，SolarisからLinuxへアプリケーションをポーティングする際のリスクとコストを大幅
に引き下げることができます。ツールのご利用を強くお勧めします。HPはこうしたツールを顧客，ISV，およびパートナーに提供
しています。表3-1に記載しているとおり，それぞれのツールには，コード移行サイクルにおいて，最も有効に活用できる段階があ
ります。
表3-1 HPアプリケーション移行ツール
移行ツール
利用の推奨
HP Solaris-to-Linux binaryScan
計画
HP Solaris-to-Linux Software Transition Kit（STK）
計画、ポーティング
簡単な説明
APIの数とLinux上でのそれらの性質を報告することによ
り，ポーティングの作業量を調べます。
ライブラリおよびAPIレベルで具体的なアドバイスを提示
し，詳細な評価を提供します。
HP Solaris-Linux Porting Kit（SLPK）
ポーティング、導入時
2つのプラットホーム間の互換性のギャップに対して，API
および開発ツールレベルで，容易に対処するための移行
環境を提供します。
HP Solaris-to-Linux binaryScanユーティリティは，ポーティングの計画段階で使用します。このユーティリティは，Solarisオペレーティ
ングシステム上で動的にリンクされたSolarisの実行可能ファイルを調べて，Linuxとの互換性問題の数と種類を記述したレポート
を生成します。HP Solaris-to-Linux binaryScanユーティリティに付属するデータベースは，libc，libsocket，libthread，libpthreadを
含む，主要なSolarisライブラリを網羅しています。詳細については，devresource.hp.com/drc/STK/newsol2linux.jspを参
照ください。
より詳細な計画策定ツールとして，また移行の際のポーティングの段階における指針として使用されるHP Solaris-to-Linux
Software Transition Kit（STK）
には，Solarisオペレーティングシステム上で開発されたソースコードを調べて，以下のような項目に関
するレポートを生成するソフトウェア・ユーティリティが含まれます。
• Linuxとの互換性の問題の提示
• 問題の解決方法に関するアドバイスの提示
HP Solaris-to-Linux STKには，技術参考資料，およびSolarisからLinuxへのポーティングに関する詳細な情報を提供する190項目以上
もの影響評価が含まれています。詳細については，devresource.hp.com/drc/STK/newsol2linux.jspを参照ください。
ポーティング作業の期間中，STKの補完的な役割を果たすHP Solaris-Linux Porting Kit（SLPK）は以下のような移行環境を提供し
ます。
• Linuxプラットホーム上で，プラットホームの違いに対処するための，Solarisとの互換性を備えたヘッダファイルおよびAPIの実装。
• Solaris開発環境ツールのオプションをLinuxで使用することを可能にするLinuxドライバー・プログラム。
• Linux上で稼働する，Solarisとの互換性を備えたmakeユーティリティ。
詳細については，www.hp.com/go/SLPKを参照ください。
HP Solaris-to-Linux Application Transition Toolsに関するより詳細な情報および使用例は，第6章に記載があります。
17
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 18
3.5.4 統合開発環境（IDE）
Linuxでは，さまざまな統合開発環境（IDE）が利用できます。また，これらの多くがSolarisでも利用可能です。KDEプロジェクト
（www.kde.org）
は，複数のプラットホームおよび言語（C/C++，Java，Fortran，その他）をサポートする豊富な機能を備えたIDEで
あるKDevelop（www.kdevelop.org）を提供しています。KDevelopは，CVSやClearCaseをはじめとするバージョン管理システム
をサポートしています。GNOMEデスクトップ（www.gnome.org）
もLinuxではメジャーなユーザ・インターフェイスです。GNOME
という名称のIDEを開発しました。Anjutaは複数の言語やプラットホーム，バ
プロジェクトは，Anjuta（anjuta.sourceforge.net）
ージョン管理システムをサポートしています。KDevelopも，Ajuntaも，少くとも部分的にはそれぞれのウィンドウ環境に統合されて
います。Eclipse IDE（www.eclipse.org）は，Solaris，LinuxおよびHP-UXなどの複数のプラットホーム上で，CやC++，Javaによ
る開発をサポートする先進のプラグイン・ベースのIDEです。
IDEに関するより詳細な情報については，第6章に記載があります。
3.5.5 デバッグ･ツール
デバッグ作業には，標準的なIDEデバッガを越える追加機能が必要となることがあります。Linuxコミュニティには，スタンドアローン
のデバッガがいくつか用意されており，その多くがSolarisをサポートしています。GNUデバッガ
（GDB）
（www.gnu.org/software/gdb）
は，Linuxにおける事実上の標準デバッガです。他のLinuxデバッガのほとんどは，GDBを拡張，あるいは発展させたものです。最
も人気の高いデバッガとしてData Display Debugger（DDD）が挙げられます。DDDは，GDB，XDBおよびJDBを含む多くのデバッ
ガにグラフィカルなフロントエンドを提供します。詳細についてはwww.gnu.org/software/ddd/を参照ください。
システムコール，メモリ初期化の問題，あるいはメモリ・リークを追跡するためには特殊なツールが必要となります。Solarisでは，
システムコールを追跡して，コールの頻度および方法に関するレポートを生成してくれるtruss（1）ユーティリティが利用できます。
Linuxでは，strace（1）ユーティリティ
（www.sourceforge.net/projects/strace/）が同様の機能を提供しており，他のプロセス
またはプログラムのシステムコールを追跡することができます。メモリに関する問題の追跡に関しては，商用あるいはオープン
ソース共に，いくつかの選択肢が存在します。たとえば，IBM Rational PurifyPlusという製品は，Solarisに加えて，一部のLinuxプ
ラットホームでも利用可能です。
オープンソース・コミュニティにも，メモリに関する問題をデバッグできる無料の代替ユーティリティが存在します。人気の高いユー
とValgrind（valgrind.kde.org）が挙げら
ティリティとして，Electric Fenceライブラリ
（www.freshmeat.net/projects/efence）
れます。Electric FenceはSolarisのwatchmalloc(3)ライブラリと同様の機能を提供します。一方，Valgrindは，エミュレートされた環
境でアプリケーションを実行することにより，ヒープおよびスタックの両方であらゆるメモリアクセスをモニターできる，よりアグ
レッシブなユーティリティです。これらのユーティリティはまったく趣を異にしていますが，どちらもメモリ管理やオーバーフローに
関する問題の位置特定を非常に効率化してくれます。
GCCコンパイラの修正バージョンであるMudflapの利用も可能です。Mudflapは，コンパイル時インスツルメントをベースにした
ポインタ・チェック技術を提供します。Mudflapは，空ポインタの使用やバッファオーバーランなどの標準的なメモリエラーに加
えて，メモリ・リークや未初期化データの使用も検出します。Mudflapは，GNUコンパイラ・コレクション用の新しい最適化エンジ
ン の 一 部 として 開 発 さ れ ，GCC 4.0.0に 統 合 さ れ まし た 。詳 細 に つ い て は ，gcc.gnu.org/projects/tree-ssa，お よ び
gcc.gnu.org/gcc-4.0/changes.htmlのGCC 4.0のリリースノートを参照ください。
GDB，DDDおよびstrace（1）を含むデバッグ・ツールの多くは，ほとんどのLinuxディストリビューションに収録されています。
3.5.6 欠陥追跡ツール
変更を追跡する目的は，変更が加えられた理由を追跡することにあります。あらゆる開発プロジェクトでもうひとつの重要な要素
は，欠陥追跡ソフトウェアです。Linux開発環境においては，この種のユーティリティを複数の候補から選択することが可能です。最
も人気のあるユーティリティとして，Bugzilla（www.bugzilla.org）が挙げられます。Bugzillaは，Mozillaウェブ・ブラウザ・プロジェ
クト
（www.mozilla.org）が作成したプログラムですが，それ自体がプロジェクトとなり，人気，機能の両面において成長を続けて
も人気を集めています。
います。この他に，GNU GNATS（www.gnu.org/software/gnats）
3.6 Linux 環境のセットアップ
HPサイト（ www.hp.com/go/linux）では，HPの特定のハードウェア，すなわち，HP ProLiantおよびHP Integrityの両サーバで
Linuxを運用できるようにするために，数多くのガイドを提供しています。
“Getting Started with Linux on HP Servers”
という文書では，
HP ProLiantおよびHP Integrityの両サーバへの新規インストールのプロセスを詳しく説明しています。同文書はDSPP Linuxサイトで
入手可能です。詳細はwww.hp.com/go/linuxdevを参照ください。
3.7 サードパーティへの依存性
アプリケーションを移行する際には，すべての依存性を記録した完全なリストを作成し，移行対象となる環境においてそれらが利
用できるか否かを判断することが重要です。依存する特定のアプリケーションのリリースが利用できない場合には，別のバージョ
ンを使用するのか，あるいはアプリケーションがその依存性を解決できるのかを判断する必要があります。スケジュールを立てる
際には，これらの新たなバージョンあるいはアプリケーションへ移行するために必要な時間を考慮しておく必要があります。
18
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 19
HPは，ISV製アプリケーションの利用に関する情報を提供しています（www.hp.com/go/linuxsolutionpartners）
。なお，最新
の情報については，ベンダにお問い合わせください。
3.8 アプリケーションの移行
どんなツールが必要なのか，環境をどのように移行するのかを決定したら，アプリケーション自体の移行を開始できます。オープ
ンソース・ユーティリティの性質から，2つのアプローチが考えられます。
• 新しいツールおよびコンパイラを使用するSolarisの環境に，既存のSolaris環境を移行する。このステップが完了したら，新しい
Linux環境にコードを移行する。
• アプリケーションと環境を同時にLinuxに移行する。
いずれの方法にも長所と短所があります。最初の方法では，事実上2度の移行を伴いますが，移行の正否を確認する上でより直接
的な比較が可能になるという利点があります。第2の方法は，移行が1度で済み，Solaris環境ときっぱり決別することができますが，
ツールに起因する問題と環境に起因する問題とを識別することがより困難になります。
19
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 20
4 コンパイラ
Linuxの開発環境では，特殊なものや一般的なものを含めて，数多くのコンパイラが用意されています。本章では，Sun Studio 8のCお
よびC++コンパイラと，GNU Compiler Collection（GCC）のCおよびC++コンパイラとの比較を行います。GCCのコンパイラ・スイート
は，そのコアとしてC，C++，Java，FORTRAN 77をサポートしています。また，他の言語のための追加プラグインやモジュールも数多
く用意されています。GCCは，ほとんどのLinuxディストリビューションに収録されています。詳細については，gcc.gnu.orgを参照く
ださい。
GCCは，Solarisをはじめとするさまざまなプラットホームで使用できます。SolarisからLinuxへの移行に際しては，まずSolaris上のGNU
コンパイラに移行し，その後Linuxに移行するという方法を取ることも可能です。この方法では，プラットホームに依存する修正の多く
を，コンパイラに依存する修正と切り分けることが可能です。これは優れた方法ですが，本章では，別の方法を取り上げます。Solaris
上のSun Studioコンパイラから，Linux上のGNUコンパイラに直接移行するという方法です。
Linuxで利用可能なコンパイラのうち，GNUコンパイラとの互換性を高いレベルで実現しているのはインテル® 製のものです。インテル®
では， CもサポートするC++コンパイラ，およびFortran 95コンパイラを提供しています。これらのコンパイラは，非営利目的の場合
は無料で使用できますが，営利目的の使用の場合はライセンスを取得する必要があります。インテル® コンパイラの詳細については，本
ガイドの本版においては取り上げていませんが，将来の版では追加する予定です。インテル® コンパイラ，およびGNUとの互換性に
関するより詳細な情報については，www.intel.com/software/products/compilers/linuxを参照ください。
4.1 Cコンパイラ
本セクションの情報は，Solaris向けのSun Studio 8 Cコンパイラ，およびLinux向けのGNU Compiler Collection（GCC）3.3.3 Cコンパ
イラに基づいて書かれています。本稿の執筆時点で利用できる，GCCコンパイラの最新バージョンはGCC 4.0.0です。HPは，ご
利用中のLinuxディストリビューションでサポートされている最新のGCCパッチを使用することお勧めしています。
GCCに関する詳細な情報については，gcc.gnu.orgを参照ください。
可能なかぎりANSI Cに厳密に準拠したコードを書くことで，あらゆるプラットホームにおいて最高レベルの移植性，そして最も一貫
性のある動作を実現することが可能になります。以下のセクションでは，これらの2つのコンパイラをさらに詳細に説明します。
4.1.1 言語のモード・オプション
SunおよびGNU C（GCC）のコンパイラは，どちらもC言語の規格であるISO/IEC 9899-1999に記述されているC99の機能に加え，
ISO/IEC 9899-1990に記述されているC89の言語機能をサポートしています。SunのCコンパイラでは，C99機能がデフォルトで使用
可能に設定されています（詳細については，manページ cc（1）の-xc99=%allコンパイラ・オプションを参照ください）
。GCCコン
パイラでは，-std=c99または-std=gnu99オプションを明示的に指定する必要があります。どちらのプラットホームも，デフォルトで
標準に対する拡張が可能となっています。SunのコンパイラはK&R互換の拡張をサポートしており，GCCはGNUの拡張をサポート
しています。GCCについては，プリプロセッサだけがK&Rモードをサポートしているため，Solarisで-Xsオプションに依存するアプ
リケーションは，Linux上でのコンパイルを成功させるために，アップデートする必要があるかも知れません。
表4-1は，Sun CとGCCコンパイラの言語のモード・オプションを比較したものです。Cコンパイラのオプションのマッピング
を記載した完全なリストについては，付録Aをご覧ください。
表4-1 C言語のモード・オプション
Sun C
-Xc
説明
GCC
-std=c99 -pedantic
C99のサブセット
-Xa（デフォルト）
-std=c99
C99 + K&R C（C99で普及）
-Xt
対応なし
C99 + K&R C（K&R Cで普及）
-Xs
対応なし
K&R C
なし
-std=gnu89（デフォルト）
C89 + GNU拡張
なし
-std=gnu99
C99 + GNU拡張
-xc99=%none
-std=c89（-ansiと同じ）
C89
20
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 21
4.1.2 プリプロセッサ・マクロ
表4-2では，Sun CコンパイラおよびGCCによって定義されているプリプロセッサ・マクロを記載しています。各コンパイラのマ
クロ の 完 全 なリスト を 表 示 す るに は ，Sun Cで は cc -#を ，GCCで は gcc -dMを 使 用し ま す。な お ，GCCが デ フォルト で
__STDC__=1を設定するのに対して，Sunコンパイラは，-Xcオプションが使用されている場合にのみ， __STDC__=1を設定する
という点に注意してください。
表4-2 定義されているC言語のプリプロセッサ・マクロ
Sun C
GCC
__SunOS_<version>
__linuxおよび__linux__およびlinux
__SUNPRO_C=<version>
__VERSION__ “<version>”
__SVR4
対応なし
__unix
__unixおよび__unix__およびunix
__sun
対応なし
__sparc
__i386
または__ia64
または__amd64
または__x86_64
__STDC__=1 1（ -Xc 使用時のみ）
__STDC__=1（デフォルト）
4.1.3 最適化
表4-3は，Sun CコンパイラとGCCで使用されるコンパイラの最適化レベルを比較したものです。Sunは -xO[n]オプション
（n=1-5）
に
よって，5段階の最適化を提供しています。GCCは -O[n]オプション（n=0-3）
によって，4段階の最適化を提供しています。最適化
は，どちらのコンパイラでも，デフォルトでは無効になっています。なお，-O は，Sun Cコンパイラの場合は-xO2に，GCCの場合は
-O1に相当するという点に注意してください。
表4-3 Cコンパイラの最適化の比較
Sun Cの最適化レベル
Sun Cの説明
GCCの最適化レベル
-xO1
基本的な局所的最適化（ピープホール）
-O[1]
-xO[2]または-O
基本的な局所的および大域的最適化
-O2
GCCの説明
コンパイル時間は増えずに，コード・サ
イズと実行時間を削減
サイズと速度のトレードオフを伴わない
最適化
-xO3
ループ展開とソフトウェアのパイプライン化 対応なし
-xO4
同一ファイル内のインライン機能
-O3
-xO5
-xprofile=pと共に使用
対応なし
インライン展開およびレジスター割付
けによる最適化
4.1.4 プラグマ
GCCでは，Sun Cコンパイラの提供するプラグマの大部分をサポートしていませんが，オブジェクトの宣言または定義に情報を付
加する__attribute__キーワードを提供しています。
注意が必要なのは，GCCは認識できない，あるいはサポートされていない#pragmaステートメントを単に無視するだけであるとい
う点です。したがって，__attribute__キーワードに変換するか，プラットホーム固有のプラグマを条件付きコードに置き換えてくだ
さい。gcc -Wallコンパイラ・オプションを使用すれば，無視された#pragmaステートメントに関する警告を得ることができます。
__attribute__キーワードの後には，2つの左小括弧が続きます。これにより，以下の例で示すように，コンパイラが属性を理解でき
ない場合に使用できるマクロを定義することが可能となります。
#define __attribute__(ignore)
属性は，前後にダブルアンダースコアを付けて指定することができます。これにより，同じ名称のマクロとの名称コンフリクトを
引き起こすことなく使用することが可能となります。
表4-4では，Sun Cのプラグマに対応するGCC属性へのマッピングを示しています。また，ダブルアンダースコアの名称変換の使
用についても示しています。
21
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 22
表4-4 Sun CのプラグマとGCCの属性
Sun Cのプラグマ
説明
GCCの属性
__aligned__
リストされた変数の境界合わせをバイトで指定
init
__constructor__
初期化関数を指定
fini
__destructor__
終了処理関数を指定
weak
__weak__
弱いシンボルを定義
redefine_extname
extern int oldname (int)
align
__asm__ ("newname");
新しい外部名をシンボルに割り当てる
（GCCのために，インラインアセンブ
ラのステートメントを使用）
ident
#ident “string”を使用
.comment のセクションにstringを挿入
int_to_unsigned
対応なし
intを返す際に，符号なしの値を返す関数に印付けをする
nomemorydepend
ループポインタと配列にC99の
いかなるループの繰り返しにもメモリ依存がないことをコンパイラに通知
restrictキーワードを使用
no_side_effect
__pure__ または __const__
指定された関数には副作用がないことを宣言
pack
__packed__
指定された構造がパディングなしで配置されるように指定
pipeloop
対応なし
ループ運搬依存の最小依存距離を指定
unknown_control_flow
__noreturn__
正常なコントロールフローのプロパティに違反する関数の名称を指定（GCC
unroll
対応なし
では，__noreturn__は値を返さない関数に印付けをする）
ループのアンロール係数を提示
Solarisで一般的に使用されるプラグマの一例を以下に挙げます。この例では，Solarisのpragma packによって，指定された構造がコ
ンパイラによりパディングなしで配置されるように指定しています。
#pragma pack(1)
/* Set alignment to one byte */
struct foo { ... };
/* declare the structure(s) to pack */
#pragma pack(0)
/* Reset to default alignment */
GCCでこれを表現する方法は，以下のとおりです。
/* declare a packed structure */
struct foo { ... } __attribute__ ((__packed__));
この方法により，構造を最もコンパクトな形式にパックできます。しかし，GCCではさらに詳しく表現することもできます。たとえ
ば，個別の構造メンバを強制的にパックし，他の構造メンバを通常の方法で境界合わせさせることも可能です。そのための構文は，
以下のようになります。
/* pack only the second field of struct foo */
struct foo {
char aaa;
short int bbb __attribute__ ((__packed__));
short int ccc;
};
この場合，メンバbbbは，境界合わせされませんが，メモリ上ではオフセット量1でメンバaaaの直後に続きます。また，メンバccc
は境界合わせされ，オフセット量4で続きます。
4.2 C++コンパイラ
本セクションの情報は，Solaris用のSun Studio 8 C++コンパイラ，およびLinux用の3.3.3 GNU Compiler Collection（GCC）3.3.3
C++コンパイラ（G++）に基づいて書かれています。本稿執筆時点に利用できる最新バージョンはG++ 4.0.0コンパイラです。最
新の機能を利用し，バグフィックスするために，gcc.gnu.org.で入手可能な現行リリースのコンパイラを利用することをお勧め
します。
Sun C++，およびGNU G++コンパイラは，どちらもANSI/ISO C++国際規格のISO/IEC 14882:1998に準拠しています。ポーティング
を容易にし，異なるプラットホームにおいても一貫性の高い動作を実現するために，ANSI C++標準に準拠したコードを書いてく
ださい。
G++コンパイラのオプションに対するSun C++のマッピングについては，付録Bをご覧ください。Sun C++およびG++用に定義され
ているプリプロセッサ・マクロは，2つのプラットホームでCコンパイラ用に定義されているものと類似しています。詳細について
は，表4-2をご覧ください。Sunでは-vオプションを，またG++では-dMオプションを使用してコンパイルすることにより，マクロを
表示できます。
SunとGNUのコンパイラの現行バージョンで使用されているiostreamおよびSTLのデフォルトの実装は，1998 C++標準に準拠し
ています。
拡張および下位互換性を含むG++実行時ライブラリの詳細については，gcc.gnu.org/onlinedocs/libstdc++/faqを参照くだ
さい。
22
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 23
4.2.1 テンプレートの実装
以下のテンプレート機能は，SolarisとLinuxで共通しています。
• どちらも，テンプレートの特殊化が可能です
• コンパイラが推論できる場合，どちらもテンプレート引数を省略することができます。
• どちらも，テンプレート・メンバ，およびテンプレートの部分的な特殊化を実装しています。
• どちらも，デフォルトのテンプレート・パラメタをサポートしています。
4.2.2 テンプレートのインスタンス化
Sun Studio 8およびそれ以降のバージョンでは，SunコンパイラとGNU C++コンパイラは，同様のテンプレートのインスタンス化方
式をデフォルトで実装しています。デフォルトでは，それぞれの翻訳単位が自身の使用するテンプレートのインスタンスを含みま
す（Sunでは，-instances=globalオプション）
。しかし，巨大なアプリケーションの場合には，極めて大量のコード複製につながる可
能性があります。そこで，どちらのコンパイラもリポジトリを使用するオプションを提供しています
（Sunの場合は，-instances=extern
オプション，G++の場合は-frepoオプション）
。これにより，テンプレート・キャッシュ内も含め，オブジェクト・ファイルの総サイズを
小さくすることができます。
Sun Forte Developer 7のC++コンパイラは，デフォルトでリポジトリを使用するようになっています。このバージョンのコンパイラで
ビルドしたアプリケーションの場合，Linux上で同様のテンプレート・インスタンス化方式を利用するために，G++オプションのfrepoオプションを使用してください。
23
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 24
5 リンカとローダ
本章では，リンカと実行時ローダの違いを説明します。より詳細な情報は，Linuxシステム上，あるいはwww.gnu.org/software/binutils/
においてオンラインで閲覧できる，関連のmanページおよびGNU binutils info（1）のページを参照ください。
5.1 リンクエディタ
最終リンクは，
「コンパイラを使用して実行する」
とすることをお勧めします。これは，リンク行で明示的に指定していない追加的な
実行時ライブラリまたはオプションを，コンパイラが自動的に付加するためです。特殊なオプションを指定する必要がある場合，あ
るいはより多くのリンクエディタのレポート情報を確認したい場合には，コンパイラの-Wl,option[,option] リンカ・オプションを使用
して，オプションをリンクエディタに渡します。詳細については，コンパイラとld（1）のmanページ，および付録Cをご覧ください。
「リンクエディタ」は，一般に「リンカ」
と呼ばれています。以降のセクションでは，このリンカについてさらに詳細に説明します。
5.1.1 コマンド行オプション
Solarisで慣れ親しんでいるリンカ・オプションの多くは，Linuxでも共通です。GNUリンカは多様な環境において機能することを
目標に開発されました。このため，多くの一般的なオペレーティング・システムのリンカに対する，ネイティブ形式のGNUリンカ
のマッピングも含まれています。一般的に使用されるリンカ・オプションの一部を，表5-1に示します。Solarisリンカ・オプションに
対するGNUリンカの完全なマッピングについては，付録Cを参照ください。
表5-1 一般的に使用されるリンカ・オプション
Solarisのオプション
説明
Linuxのオプション
-shared
共有オブジェクト
（ライブラリ）を生成する
-h name
-h name
内部ライブラリ名をnameに設定する
-l libname
-l libname
リンクにライブラリlibnameを含める
-L path
-L path
ライブラリの探索パスにpathを追加する
-o outfile
-o outfile
オブジェクト・ファイル outfile を生成する
-R path
-rpath path
pathを使用して実行時に依存を探す
-s
-s
シンボリック情報を取り除く
-V
-V
ld（1）のバージョンを印刷する
-G
5.1.2 環境変数
Solarisと異なり，Linuxではリンクの際，LD_LIBRARY_PATHやLD_LIBRARY_PATH_64などの環境変数を使用しません。これによ
り，他の実行可能ファイルのために実行時に必要なライブラリのパスに起因する問題がリンクに干渉することを防いでいます。
LD_RUN_PATH環境変数は，Solaris上でもLinux上でも同様に機能します。これが設定されている場合，値は実行時ライブラリ
の検索パスとして格納されます。
GNU ld（1）は，LD_OPTIONS環境変数，およびSGS_SUPPORT環境変数の使用をサポートしていません。make（1）からリンカを
呼び出しているアプリケーションに対して，GNUのmakeは，LDOPTS環境変数をデフォルトのリンカ・オプションとして利用するリ
ンカに関するデフォルトの規則を用意しています。
5.1.3 ライブラリの検索順序
SolarisとLinuxでは，リンク行で指定されているライブラリを探し出す際に使用する検索アルゴリズムが異なります。GNU ld（1）
は，以下の項目を検索し，-lオプションで指定されているライブラリを探し出そうとします。
1. -rpathが使用されていない場合は，LD_RUN_PATH
2. -Lで指定されているディレクトリ
3. システムのデフォルトディレクトリ
システムのデフォルトディレクトリには，/lib，/usr/lib， /usr/local/lib，さらにGCCまたはbinutilの生成時に指定されたあらゆるディ
レクトリが含まれます。この最後の要素は変化しますが，これらのファイルは開発環境のコアの一部であり，内部ライブラリ以外の
ライブラリは一切含まれていないため，アプリケーションへの影響はありません。ディレクトリ・リストの検索パスは以下のとおり
です。
1. /usr/*-linux/lib
2. /usr/local/lib
3. /lib
4. /usr/lib
5.1.4 リンカ定義シンボル
Solarisのオブジェクトファイル形式はELFです。Linuxにおいても，現在，大部分のプラットホームでELF形式がデフォルトとして使用
されています。リンカ定義シンボルはすべてELF標準によって定義されているため，この点については，SolarisとLinux間に高い互
換性があります。どのようなシンボルが定義されているのか，そして，それぞれ何を意味しているのかについては，Linux Standard
Baseのドキュメンテーションセットに詳細な情報が掲載されており，http://www.linuxbase.orgから入手可能です。
24
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 25
5.2 実行時リンク
「実行時リンカ」は，Solaris上においてはしばしば「インタープリタ」
と呼ばれます。その性質上，Linuxは複数のオブジェクトと実行
可能なフォーマットをサポートしています。現在，ELFのみが標準となっていますが，カーネルは引き続き複数の他のバイナリ形式
をサポートし，追加フォーマットを登録するためのシステムを提供しています。binfmt_miscカーネル・モジュールに関する詳細な
情報については，www.tldp.org/LDP/intro-linux/html/x9025.htmlを参照ください。
「ローダ※1」という用語は，一般的には「実行時リンカ」の意味で使用されます。この用語を使用すれば，リンクエディタとの
区別が容易になります。以降のセクションでは，実行時リンクのプロセスをさらに詳しく説明します。
※1 ダイナミックローダ，あるいは実行時ローダと呼ばれる場合もあります。
5.2.1 ライブラリの解決
ローダは，イメージ内の未解決シンボルを解決するために，実行可能ファイルとそれが依存するライブラリに含まれる情報を使用
して，共有ライブラリのリストを作成します。SolarisとLinuxは，どちらもローダのために構成ファイルを提供します。これらの構
成ファイルは，ライブラリを探し出す際にデフォルトで使用される検索パスを決定します。Solaris上では，これらのファイルを設定
するために crle（1）を使用します。Linux上では，ldconfig（8）
コマンドにより，この機能が利用できます。Linuxのローダに関する
詳細な情報は，ld.soのmanページと info（1）ページの両方に記載があります。
同一のアーキテクチャ内で32ビットと64ビットの両方のライブラリをサポートするLinuxディストリビューションの場合，1つの単純
な構成ファイルを使用します。これは，32ビットと64ビットの各ライブラリ用で異なる構成ファイルを使用しているSolarisと異なる
点です。Solaris上で，32ビットのライブラリは*/libに，64ビット・バージョンは*/lib/64に置かれることが一般的です。一方，Linuxの
場合，デフォルトの位置はアーキテクチャに依存します。32ビットx86システムのライブラリは通常 */lib に置かれています。32
ビットおよび64ビット環境の両方をサポートできるよう，64ビットx86システムにはライブラリが2セット用意されています。32ビッ
ト用は */libに，64ビット用は */lib64に置かれることが一般的です。64ビット・ライブラリを使用するインテル® Itanium® ベースのシス
テムの場合，ライブラリは通常*/libに置かれています。これらの情報を要約したものが表5-2です。
実行可能ファイルの共有ライブラリの必要条件に合致するライブラリを実際に探し出す際には，Solarisでも，Linuxでも同様の
プロセスを用います。
1. setuid（2）
，またはsetgid（2）バイナリではない場合， LD_LIBRARY_PATHを検索します。Solarisと違い，64ビット実行ファ
イルのために分離されている環境変数（LD_LIBRARY_PATH64）を，Linuxでは使用しません。
2. リンク時に格納された埋め込み検索パスを検索します。このパスは，リンカの-rpathオプションを使用して定義します。
3. その後，ldconfig（8）構成ファイルで指定されたディレクトリを検索します。
4. 最後に，-z nodeflibオプションでバイナリがリンクされていない場合，システムのデフォルトのライブラリを検索します。
表5-2 Linuxにおけるデフォルトのシステム・ライブラリの位置
アプリケーションのアーキテクチャ
デフォルトのシステム・ライブラリの位置
x86
/lib/
x86 on x86_64
/lib/
x86_64
/lib64
/usr/lib/
/usr/lib/
/usr/lib64
インテル® Itanium® ベースのシステム
/lib/
/usr/lib
Linuxでは，非ネイティブのバイナリを実行できるエミュレータがいくつか提供されています。これらのエミュレータは，それぞれ
特有の規則を使用して，依存ライブラリを探し出します。通常，これは chroot（1）を使用して作られた環境を必要とします。詳細
は，各エミュレータのドキュメントを参照ください。
5.2.2 シンボル・バインディング
SolarisとLinuxは共に，デフォルトでレイジー・シンボル・バインディングを実行します。つまり，まず呼び出しを行わない限り，シン
ボルは実際に解決されないということです。この動作は，シンボルの参照に際してわずかな遅延をもたらします。しかし，必要の
あるシンボルだけが解決されるため，起動中のパフォーマンスは大きく向上します。多数のシンボルを使用するアプリケーション
ほど，パフォーマンスの向上は著しくなります
Solarisでも，Linuxでも，デフォルトであるレイジー・バインディングに加え，アプリケーションの起動時にすべてのシンボルをバイ
ンドすることが可能です。LD_BIND_NOW環境変数を空でないストリングに設定する，あるいはリンク中に-z nowオプションを使
用することによって，これが実現できます。
25
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 26
5.2.3 環境変数
表5-3に示すように，SolarisおよびLinuxのローダは共に，ローダの動作を変更する環境変数をいくつかサポートしています。これ
らの変数には，共有できるものと，2つのプラットホーム間での移植性がないものとがあります。
表5-3 Linuxに対するSolarisローダの環境変数のマッピング
Solarisの環境変数
Linuxでの使用の可否
LD_AUDIT
対応なし
LD_AUDIT_64
対応なし
LD_BIND_NOW
同一機能
LD_CONFIG
対応なし
LD_DEBUG
同一機能
LD_DEBUG_OUTPUT
同一機能
LD_FLAGS
対応なし
LD_LIBRARY_PATH
同一機能
LD_LIBRARY_PATH_64
対応なし, use LD_LIBRARY_PATHを使用
LD_LOADFLTR
対応なし
LD_NOAUXFLTR
対応なし
LD_NOCONFIG
対応なし
LD_NODIRCONFIG
対応なし
LD_NOOBJALTER
対応なし
LD_NOVERSION
対応なし
LD_ORIGIN
対応なし
LD_PRELOAD
同一機能，さらに，Linuxでは /etc/ld.so.preloadをシステム全体で使用
LD_PROFILE
同一機能
LD_PROFILE_OUTPUT
同一機能
5.3 リンカ関連のツール
アプリケーションのポーティングに伴うデバッグを行う際，問題の原因の特定は，時に，バイナリイメージの内部まで踏み込むこと
を意味します。以降のセクションで説明するツールは，様々なシンボルがどこで解決されているのか，アプリケーションがどんな
依存性を持っているのか，シンボルの衝突がどこで発生しているのかなどの特定を支援してくれます。
これらのリンカ・ツールは，ほとんどのLinuxディストリビューションに収録されています。
5.3.1 ldd
ldd（1）ツールは，呼び出しを共有する実行可能ファイル，または共有ライブラリの依存関係を表示します。また，システム
ローダが使用するライブラリのパスやその他の情報のレポートを生成し，アプリケーションの依存性の解決に利用することも
可能です。このツールは，ライブラリを解決する際，現在の環境設定やイメージのrpathといった情報を考慮に入れています。
Linuxでのldd（1）の実装は，ld.soを呼び出すシェル・スクリプトであり，強力な機能一式を提供する特殊なオプションを備え
ています。結果的に得られる出力は，Solarisのldd（1）コマンドでの出力に似ていますが，出力書式には若干の相違があり，い
くつかの追加情報も提供してくれます。
Linux上でldd（1）の機能をすべて利用するには，コマンド・ライン・オプションに加え， LD_DEBUG環境変数をlibsなどの値に設定す
る必要があります。libsオプションを使用すれば，Solarisのldd -sとほぼ同等の出力を生成できます。詳細についてはLinux ldd（1）お
よびld.so（8）のmanページを参照ください。サポートされているLD_DEBUGオプションを確認するために，以下のコマンドを実行
してください。
$ LD_DEBUG=help ldd
Valid options for the LD_DEBUG environment variable are:
libs
display library search paths
reloc
display relocation processing
files
display progress for input file
symbols
display symbol table processing
bindings
display information about symbol binding
versions
display version dependencies
all
all previous options combined
statistics
display relocation statistics
help
display this help message and exit
5.3.2 elfdump
Solarisでは，イメージやライブラリの選択された部分をシンボリックにダンプするために elfdump（1）ユーティリティを使用しま
す。Linuxでは，objdump（1）
ツールが同じような機能を提供しています。objdump（1）は，ELFイメージ以外にも，数多くの形式を
サポートしています。サポートする形式は，使用しているアーキテクチャとディストリビューションに依存します。
26
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 27
5.3.3 ar
ar（1）ユーティリティは，主に扱いやすくすることを目的に，複数のオブジェクトファイルを結合して1つのアーカイブ・ライブラリに
まとめるために使用します。SolarisとLinuxは共に，類似したar（1）
コマンドを提供しています。
5.3.4 lorder
Solarisでは，リンク行でライブラリを指定する最も効果的な順序を決定し，すべての依存を解決するために，lorder（1）
ユーティリテ
ィを使用できます。しかし，現在ではSolarisリンカがすべてのシンボルを解決するために複数パスを実行してくれるため，このユー
ティリティはもはや必須ではなくなっています。Linuxリンカも，マルチパスのリンクを実行できます。Linuxにおいて，lorder（1）
ユー
ティリティはもはや引退状態であり，Solarisアプリケーションのビルドとの互換性が必要な場合にだけ使用を考慮してください。
5.3.5 nm
nm（1）ユーティリティは，指定されたイメージからシンボルテーブルを表示します。Solarisでも，Linuxでも，nm（1）
コマンドに対
して，同様の基本的なコマンド・ラインがサポートされています。非標準の追加オプションは異なる可能性があります。また，出力
書式にわずかな違いが発生するかもしれません。
27
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 28
6 その他の開発ツール
開発環境を完全なものにするには，コンパイラとリンカだけでなく，他のツールも必要となります。Linuxで利用可能なツール群の選
択肢の充実度，増加ぶりは，Linuxプラットホームの重要性の高まりをまさに証明するものといえます。本章では，コンパイラやリンカ
以外の開発ツールを取り上げ，追加情報へのリンクも提供します。
6.1 ソースコードおよびバージョン管理
アプリケーションをポーティングする際に，ソフトウェア構成管理（SCM）の重要な役割は，バージョンの管理とアプリケーション・
ソースコードの保全性の管理，そして，変更管理における方針の適切な実行と，その積極的な活用を保証することにあります。そ
こで，ソースコードのバージョン管理という要望に応じるために，バージョン管理ソフトウェアと呼ばれるソフトウェアが開発され
ました。この分野のソフトウェアとして，Sunは，Solarisオペレーティングシステムと共に，同プラットホーム上でソースコードを管
理するためのSource Code Control System（SCCS）を提供しています。また，SCCSに加え，Sunでは，SCCSをベースにして多くの
追加機能を提供するForte Code Management Software（以前はTeamWare）
という製品ラインを有しています。こうした製品以外
にも，Solarisオペレーティング・システムでは，多くのサードパーティによる商用およびオープンソースのバージョン管理製品が利
用できます。
表6-1は，人気の高いオープンソースのバージョン管理ソフトウェア製品のリストです。表では，SolarisおよびLinux上での利用の可
否も示しています。Solaris上で，商用のバージョン管理ソフト製品を利用している場合は，ベンダにご相談の上，その製品がLinux
で利用可能か否かを確認してください。
表6-1 オープンソースのバージョン管理ソフトウェアの利用の可否
Solaris
連絡先
Linux
SCCS
CSSC
CVS
利用可能
RCS
利用可能
Subversion
利用可能
cssc.sourceforge.net
www.gnu.org/software/cvs
www.gnu.org/software/rcs
subversion.tigris.org
オープンソース化への動きが本格化したことで，オープンソースのバージョン管理製品が数多く生まれました。しかし，最も広く
利用されているのは，Concurrent Versions System（CVS）です。
以降のサブセクションでは，SunのSCCS実装に対するオープンソースの代替製品CSSCを紹介し，Linuxで広く利用されている
RCS，CVSおよびSubversionについて説明，比較を行います。
6.1.1 CSSC
SolarisからLinuxへの移行に際して検討すべきSCMツールのひとつに，Compatibly Stupid Source Control（CSSC）ユーティリティ
があります。CSSCは，SCCSに対するGNUプロジェクトの代替製品です。CSSCの背後にある目的は，SCCSと同じような機能を
備えたオープンソース・ユーティリティを提供することにあります。しかし，このソフトウェアは未完成であるため，作業上どうして
もSCCSが必要なのに，RCSなどの他の選択肢が一切使用できないという場合以外は，SCCSの完全な代替製品としての利用をお
勧めしません。上記のような場合は，CSSCの使用もやむを得ませんが，将来的にはより新しいバージョン管理製品に乗り換える
ことを検討してください。
CSSCの詳細については，cssc.sourceforge.netを参照ください。
6.1.2 RCS
Revision Control System（RCS）
はFree Software Foundationによってサポートされています。RCSに関する情報およびその使用法に
ついては，www.gnu.org/software/rcsを参照ください。機能面でRCSとSCCSは似ていますが，以下のような顕著な例外があ
ります。
• SCCSはバイナリ・ファイルをサポートしていませんが，RCSはサポートしています。
• 初めて使用するユーザにはRCSのほうが使いやすいといわれます。SCCSよりもコマンドが少なく，直観的に使用でき，一貫性
があるという点でも優れています。
• SCCSにおいては，ブランチを明確に生成する必要があります。一方，RCSにおいては，ブランチは他のバージョンとしてチェッ
クアウトされます。
SCCSの代わりに，RCSを使用する利点のひとつとしては，ファイルにセット名でタグを付けることができるという点が挙げられま
す。以降，このセットは，そのセット名を使用してグループとして参照できます。SCCSには相当する機能はなく，主として個別のフ
ァイルの改訂履歴を保存するようになっています。
RCSは，通常ほとんどのLinuxディストリビューションに収録されています。
SCCSからRCSまたはCVSへの移行を支援するために，www.cvshome.org,またはsccs2cvs.cvshome.orgで入手可能なCVS
のソースにはスクリプト一式が同梱されています。
28
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 29
6.1.3 CVS
Concurrent Versions System（CVS）は，遠隔地在住の開発者やリモート環境において動作するという柔軟性において，RCSや
SCCSとは異なっています。RCSやSCCSの基本的機能に加え，CVSには以下のような機能が追加されています。
• 開発者がファイルの集まりをモジュールと呼ばれる1つのオブジェクトとして取り扱うことを可能にする，グループ機能を備えて
います。
• クライアント/サーバーのコミュニケーション・モデルをサポートしています。ネットワーク接続が確立されている場合，チームは
同一のCVSリポジトリを共有することができます。これらの接続においては，セキュアシェル（ssh）接続のトンネルを利用するこ
とも可能です。
• リザーブされていないチェックアウトをサポートしています。つまり，複数の開発者が，同一のファイルに対して同時に作業を行
い，チェックインの際に変更されたファイルをマージすることが可能です。
CVSは元々RCSをベースにして開発され，引き続きRCSファイル形式を使用しているため，RCSからCVSへの移行は比較的容易な
作業です。つまり，RCSのファイルをCVSのリポジトリに直接コピーすることが可能なのです。RCSからCVSへの移行に際しては，
以下のステップに従ってください。
1. CVSのリポジトリを作成してください。このリポジトリ内で， RCSファイルを保管する空のディレクトリ構造を作成します。元
の場所には，RCSファイルのバックアップ・コピーを保管しておいてください。
2. ファイルをリポジトリにコピーします。ファイルの日付やその他の情報が保持されるように注意してください。たとえば，ファイ
ルがローカルな場合は，tar（1）
またはcp -rpを使用します。
3. CVSROOT内のモジュール・ファイルを更新してください。更新には，cvs co modulesまたはcvs co CVSROOTを使用して，モ
ジュール・ファイルを編集し，再度検査します。リポジトリ内の各ディレクトリ
（トップレベルおよびサブディレクトリ）のモジュー
ル・ファイル内にエントリがあることを確認してください。
4. 変更を検証します。追加した新しいファイルのいくつかのチェックアウト
（cvs co ... ）を試みて，チェックアウトしたファイルの
いくつかにcvs logまたはcvs statusを実行してください。
CVSは，通常ほとんどのLinuxディストリビューションに収録されています。
CVSのより詳細な情報は，www.cvshome.orgのプロジェクト・ウェブサイトをご覧ください。
6.1.4 Subversion
Subversionは，Linuxプラットホーム向けのバージョン管理ツールとしては比較的新しいツールですが，着実にその人気を高めてい
ます。CVSに取って代わることを意図して設計されたSubversionは，ディレクトのバージョン化や不分割なコミットといった機能を
搭載し，CVSの短所の多くを解消しています。CVSと比較した場合，Subversionには以下の機能が追加されています。
• Subversionには，バージョン管理されたファイルシステムが実装されています。これは，時間経過に従って，ディレクトリ・ツリー
全体にわたって変更を追跡する
“仮想”
ファイルシステムであり，ファイルおよびディレクトリをバージョン化します。
• Subversionでは，ファイルおよびディレクトリの両方の追加，削除，コピー，名称変更が可能です。新しく追加されたファイルには，
新しくクリーンな履歴が与えられます。一方，CVSのバージョン化はファイルに限られているため，コピーや名称変更といった操
作は，ファイルに対して行われているように思われますが，実際にはファイルを包含するディレクトリの内容に対する変更であり、
CVSではサポートされていません。さらに，CVSでは，バージョン化されたファイルを同一名称の新しいファイルで置き換える
と，古いファイルが持っていた全く無関係な履歴も受け継いでしまします。
• Subversionは，不分割なコミットをサポートしています。これは，一連の修正を完全にリポジトリに入れるか，あるいは全く入れ
ないかのいずれかであることを意味します。これにより，開発者は，論理的にひとまとまりの変更を構成し，コミットすることが
可能になります。また，一連の変更のうち一部だけがリポジトリに無事に送信されることによって発生する問題を回避すること
も可能になります。
• 各ファイルとディレクトリには，一連の属性（キーおよびその値）が関連付けられます。任意のキー/値の組を作成，格納すること
が可能です。ファイルの内容と同様，属性は時間経過に従ってバージョン化されます。
• Subversionは，リポジトリアクセスの抽象的な概念を備えているため，新しいネットワーク・メカニズムを簡単に実装することが
可能です。また，Subversionは，Apache HTTPサーバの拡張モジュールとして組み込むこともできます。これは，Subversionが
安定性および相互運用性の点で大きな利点を得ると同時に，同サーバによって提供されている認証，許可，ワイヤ圧縮などの既
存の機能を即座に利用できることを意味します。より小型のスタンドアロンのSubversionサーバも利用可能です。このサーバー
は，独自のプロトコルによってSSHを利用したトンネル通信を簡単に実行できます。
• Subversion は，バイナリ差分アルゴリズムを使ってファイルの差分を表現します。これは
（人間が読める）
テキストにも，
（人間が読
めない）バイナリのファイルに対しても同様に動作します。どちらのタイプのデータもリポジトリ内に圧縮されて格納され，差分
はネットワーク上でどちらの方向にも転送されます。
Subversionの詳細については，subversion.tigris.orgのプロジェクト・ウェブサイトをご覧ください。
29
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 30
6.1.5 機能の比較
表6-2は，RCS，CVSおよびSubversionの機能を要約，比較したものです。この情報は，LinuxおよびSolaris上の両方のバージョン管
理ユーティリティに適用できます。
表6-2 一般的なバージョン管理システムの機能比較
機能
SCCS/CSSC
RCS
CVS
ASCIIおよびバイナリ・ファイルのサポート
なし
あり
あり
あり
不分割なコミット
なし
なし
なし
あり
なし
なし
なし
あり
リモートリポジトリの複製
なし
なし
なし
限定的（サードパーティ
親リポジトリへの変更の伝播
なし
なし
なし
限定的（サードパーティ
リモートリポジトリの別の部分に対するパーミッション定義
なし
限定的
限定的
あり
変更セットのサポート
なし
なし
なし
部分的
履歴を保持したまま，ファイルまたはディレクトリを
別の場所にコピー，移動する
Subversion
のスクリプトを使用）
のスクリプトを使用）
行単位のファイル履歴のサポート
あり
あり
あり
あり
リポジトリの1つのディレクトリのみで作業する機能
なし
なし
あり
あり
コミットされなかった変更に対するシステムサポート
あり
あり
あり
あり
プレイベント・トリガのサポート
なし
なし
なし
あり
ポストイベント・トリガのサポート
なし
なし
なし
あり
GUIインタフェイスのサポート
なし
なし
あり
あり
なし
なし
あり
あり
独占的/GPL
GPL
GPL
GPL
ウェブ・インタフェイスのサポート
ライセンス
6.1.6 他のバージョン管理システムへのソースのポーティング
表6-3では，Linux上で最も普及している3つのバージョン管理システムを使い始めるための支援として，基本的なSCCSコマンドと，
Linuxで相当するコマンドを示します。
表6-3 SCCSコマンドの比較
説明
SCCS
RCS
CVS
Subversion
初めてファイルをチェックインし，履歴を作成する
sccs create file
ci file
cvs add file
svn add file
読み込みのためファイルをチェックアウトする
sccs get file
co file
cvs ﾐr checkout file
svn checkout file
編集のためファイルをチェックアウトする
sccs edit file
co -l file
cvs checkout file
svn checkout file
以前ロックしたファイルをチェックインする
sccs delta file
ci file
cvs commit file
svn commit file
ファイルの履歴を印刷する
sccs prs file
rlog file
cvs history file
Svnlook history file
2つのバージョンを比較する
sccsdiff -rx -ry file
rcsdif -rx -ry file
cvs diff -rx -ry file
svn diff -rx:y file
現在のバージョンを最後のリビジョンと比較する
sccs diffs file
rcsdiff file
cvs diff file
svn diff file
2つのバージョン間の変更を1つのファイル
にマージする
sccs edit -ix -y file
rcsmerge -rx -y file
cvs update -jx -jy file
svn merge -r x:y file
ファイルに掛けられたロックを解除する
sccs unget file
rcs -u file
cvs release file
対応なし
現在のファイルへの作業を放棄する
sccs unget file
rcs -u file
cvs unedit file
svn revert file
6.2 ビルドツール
Solaris上で最も普及している２つのビルドツールがAntおよびMakeユーティリティです。これらのツールはLinuxでも利用可能です。
以降のセクションで示すとおり，これらの2つのツールをベースにしたビルドの移植性には大きな違いがあります。
6.2.1 Ant
Antは，機能面において，make（1）
コマンドに類似したJavaユーティリティです。Antは，Sun One Studio，Eclipse，NetBeans，および
その他のJavaツールに加え，いくつかの非Java開発システムでも使用されています。Antは，デフォルトでbuild.xmlとなるXMLファ
イルを使用します。このファイルは，makeコマンドのMakefileに類似しています。Antは異なるシステム間で高い移植性を実現する
ことを意図してはいますが，拡張性も備えているため，他のシステムへのポーティングを行う際には注意が必要です。ほとんどの
場合，build.xmlファイルは高い移植性を備えているはずです。しかし，移植性を低下させる誤りとして数多く見受けられるのは，Ant
のビルド内でのシステム固有のパスの使用です。
NetBeansなどのAntを組み込んでいる一部の統合開発環境（IDE）では，複数バージョンのAntがインストールできるようになってい
ます。スペースの占有以外には，まったく問題はありません。
6.2.2 Make
makeユーティリティは，記述ファイルといくつかのテンプレートを入力として受け取り，ユーザーのために実行される一連のシェル
コマンドを生成するコマンド生成プログラムです。記述ファイルは，一般的にMakefileと呼ばれます。通常，Makefileには一連の変
数定義と，それに続く一連の規則が含まれています。また，規則にはターゲットリストと，それに続く一連の前提条件または依存
30
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 31
性リストが含まれています。ターゲットリストおよび依存性リストは，コロンとタブの文字シーケンスによって区切られます。規則
の後には，先頭のタブ文字と0個以上のコマンドが続きます。テンプレートでは，デフォルトの環境値（たとえばSHELL）や規則（た
とえばサフィックス規則）を定義します。
UNIXの make（3）
コマンドにはいくつかの種類があります。SolarisにはSystem V makeに加えて，オプションとしてGNU makeコマン
ドが含まれています。一方，LinuxにはGNU makeコマンドが含まれています。幸いにも，GNU makeコマンドにはSystem Vの機
能がすべて備わっています。2つのmakeコマンドの違いの多くは，以降のセクションで記載しています。また，makeの-pオプショ
ンを利用すれば，デフォルトを印刷することができます。
GNU makeの詳細については，www.gnu.org/software/make/manual/make.htmlを参照ください。
6.2.2.1 シェルの問題
複雑なビルド環境内にあるMakefileの多くは，デフォルトのシェルに依存しています。Solarisインストレーションの多くでは，Cシェ
ル（/bin/csh）を使用する傾向があります。一方，ほとんどのLinuxインストレーションでは，GNU Bourne Again SHell（/bin/bash）が標
準化されています。makeコマンドは SHELL環境変数を利用して，どのシェル構文を解析するのかを決定します。幸いにも，以下
のように，実行時にこれを変更することができます。
$ make SHELL=/bin/csh
これにより，デフォルトの SHELL 変数が無効化され，makeが適切にCシェル構文を処理することが可能となります。
GNU makeコマンドおよびbashシェルはSolarisで利用可能です。このため，ポーティングを行う前に，Makefileを検査することが
できます。なお，LinuxシステムでもCシェルはサポートされています。
6.2.2.2 文字列置換における%ワイルドカード
SolarisとGNUのmakeコマンドはどちらも，規則の依存性およびコマンドの部分で，ワイルドカード文字としてパーセント記号（%）
を使用することが可能です。GNU makeにおいては，最初の%だけはパターンによる置換を行うことが可能ですが，それ以降
の%文字は不変です。一方，Solarisのmakeコマンドにおいては，以降の ％ 文字を置換することができます。例6-1では，
SOURCES 変数内の3つのソースファイルが，3つの通常（.o）オブジェクトファイルと3つのデバッグ（.dbg）オブジェクトファイルに
なります。例6-2では，GNU makeコマンドのために修正されたMakefileを示します。
Example 6-1 %文字を使用したパターンによる置換
SOURCES=a.c b.c d.c
OBJECTS=$(SOURCES:%.c=%.o %.dbg.o)
all:
@echo OBJECTS is $(OBJECTS)
Solaris makeで例6-1を実行すると，変数OBJECTSの値は以下のようになります。
a.o a.dbg.o b.o b.dbg.o d.o d.dbg.o
GNU makeで例6-1を実行すると，変数OBJECTSの値は以下のようになります。
a.o %.dbg.o b.o %.dbg.o d.o %.dbg.o
注意したいのは，Solaris makeで処理した場合は，デバッグ（.dbg）オブジェクトファイルが定義されているのに対し，GNU make
を使用した場合は，デバッグ（.dbg）オブジェクトファイルが定義されていないという点です。
Example 6-2 GNU make向けに修正されたパターン置換
SOURCES=a.c b.c d.c
OBJECTS=$(SOURCES:%.c=%.o)
OBJECTS+=$(SOURCES:%.c=%.dbg.o)
all:
@echo OBJECTS is $(OBJECTS)
例6-2は，OBJECTS変数が以下の値を持つように，Makefileを修正する方法を示したものです。
a.o b.o d.o a.dbg.o b.dbg.o d.dbg.o
31
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 32
6.2.2.3 The $<マクロ
$<マクロは，サフィックス規則と.DEFAULT規則においてのみ使用されることを意図しています。サフィックス規則は，単一の依存
性に対する単一のターゲットのマッピングです。$<マクロは，この依存性を参照するために定義されます。例6-3では，一般的なサ
フィックス規則を示します。
例6-3 サフィックス規則における$<マクロの使用
.c.o :
$(CC) $(CFLAGS) -c $<
SolarisとGNUのmakeは，どちらも$<を定義しており，サフィックス規則にとどまらない使用を認めていますが，その方法は異なり
ます。例6-4は，Solaris makeにおいて，対応する依存性を取得するために $<マクロがどのようにターゲット・サフィックス規則を
使用することができるかを示しています。GNU makeではこれと異なり，$<マクロは空です。例6-5は，より移植性を高め，GNU
makeで実行できるようにMakefileを変更する方法を示したものです。
例6-4 アクション行における$<の使用
foo.o bar.o:
cc -c $<
Solaris makeで例6-4を実行すると，出力は以下のようになります。
> make -f targets.mk
cc -c foo.c
cc -c bar.c
GNU makeで例6-4を実行すると，出力は以下のようになります。
> make -f targets.mk
cc -c
cc: no input files
例6-4のような，未定義の依存性を持つ規則を伴ったSolarisのMakefileについては，例6-5で示すとおり，ターゲットとなる依存性を
明示的に指定するように修正しなくてはなりません。このアプローチは，こうした明示的な規則によって単一のターゲットを指定
するため，マクロ拡張の曖昧さが解消される，という付加的な利点があります。
例6-5 GNU makeのアクション行における$<の使用
foo.o : foo.c
cc -c $<
bar.o : bar.c
cc -c $<
Solaris makeおよびGNU makeで例6-5を実行すると，出力は以下のようになります。
> make -f targets.mk
cc -c foo.c
cc -c bar.c
HPは，適切な場合には，$<マクロの代わりに，Makefileの移植性を高めるため $?マクロの使用を検討することもお勧めします。
6.2.2.4 サフィックス規則
SolarisとGNU makeのコマンドには，定義されたサフィックス規則に若干の違いがあります。これらのサフィックス規則の比較に
ついては，付録Dをご覧ください。
6.2.2.5 ソース管理のサポート
Solarisのmakeコマンドには，SCCSソース管理システムをサポートしている一連のサフィックス規則が含まれています。.cc~.o.な
どのチルダ（~）を含む規則です。SCCSはLinuxで利用可能ですが，GNU makeコマンドにおいて，SCCSサフィックス規則はデフォル
トでは実装されません。したがって，MakefileにSCCSへの依存性がある場合には，SCCSサフィックス規則を手動で追加する必要
があります。
6.3 HP Solaris-to-Linux Application Transition Tools
本セクションでは，HPが開発したSolaris-to-Linux Application Transition Toolsというスイートを説明します。このスイートは，コード
移行サイクルのさまざまな段階で役立つことを意図した3つのツールで構成されています。表6-4は，これらの移行ツールの説明
です。
32
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 33
表6-4 Solaris to Linux Application Transition Toolの概要
移行ツール
推奨用途
簡単な説明
HP Solaris-to-Linux binaryScan
計画策定
APIの数およびLinuxにおける対応策を示すことにより，
HP Solaris-to-Linux Software
計画策定，ポーティング
ライブラリおよびAPIレベルで具体的なアドバイスを示し，
ポーティングの作業量を調べる。
Transition Kit（STK）
ポーティングの詳細な評価を行う。
HP Solaris-to-Linux Porting Kit（SLPK） ポーティング，導入時
APIおよび開発ツールレベルで，2つのプラットホーム間の互換性の
ギャップに容易に対処するための移行環境を提供する。
6.3.1 HP Solaris-to-Linux binaryScan Utilityの概要
HPは，Solaris 8からRed Hat Enterprise Linux 3，あるいはSUSE Linux ES 9へアプリケーションをポーティングする計画を策定する
段階で役立つユーティリティとして，Solaris-to-Linux binaryScanを開発しました。
binaryScanユーティリティは，ソースにアクセスすることなく，ポーティングに伴う作業量を瞬時に調べることを支援します。この
ユーティリティは，Solarisオペレーティングシステム上の動的にリンクされたあらゆる実行可能ファイルをスキャンして，Linuxと
の互換性の問題の数とその性質に関するレポートを生成します。binaryScanに含まれるSolarisからLinuxへの移行のためのデータ
ベースは，libc，libsocket，libthread，libpthreadなどの主要なSolarisライブラリを網羅しています。
HP Solaris to Linux binaryScan Utilityの入手には申し込みが必要です。binaryScanの詳細を知りたい方，あるいは他のプラットホー
ムとの組み合わせについて確認するために本ユーティリティをダウンロードしたい方は，アプリケーション移行のポータルサイト，
devresource.hp.com/drc/STK/newsol2linux.jspをご覧ください。
6.3.2 HP Solaris-to-Linux Software Transition Kit概要
HPは，Solaris 8からRed Hat Enterprise Linux，あるいはSUSE Linux Enterprise Serverへのアプリケーション・ソースコードの移行を
支援するために，ソフトウェア移行キット
（STK）を開発しました。
HP Solaris-to-Linux STKには，シェルスクリプトおよびmakeファイルに加え，CまたはC++で書かれたソースコードをスキャンす
るソフトウェア・ツール群が含まれています。STKファイル・スキャナは，ポーティングに伴う潜在的な問題を特定し，それらの問題
に対処する指針を示す，簡易的なレポート，あるいは詳細なレポートを生成するために使用します。Solaris-to-Linux STKには，技
術的な参考文書に加え，数多くのAPIに関する詳細なポーティング情報を提供する190以上もの説明文書が含まれます。
The Solaris-to-Linux STKの入手には申し込みが必要です。
キットの入手方法については，devresource.hp.com/drc/STK/newsol2linux.jspの案内をご覧ください。
HP STKの詳細を知りたい方，あるいは他のプラットホームとの組み合わせについて確認するために本ユーティリティをダウンロー
ドしたい方は，HP STKのポータルサイト，www.hp.com/go/STKをご覧ください。
6.3.3 HP Solaris-to-Linux Porting Kit（SLPK）概要
HP Solaris-to-Linux Porting Kit（SLPK）は，SolarisからLinuxへの移行プロセスの自動化を支援するポーティング環境です。このポー
ティング支援キットは，SolarisアプリケーションをLinuxで稼働させるようにするための時間と労力を節約してくれます。
SLPKの主要な構成要素は移行環境です。この環境は以下の機能を提供します。
• 一般的なプラットホームの差異に対応するヘッダファイルおよびAPI
• Solaris開発環境のオプションを使用可能にするコンパイラおよびリンカドライバ
• LinuxにおけるSolaris makefileのサポート
SLPK移行環境は，ポーティング不可能なヘッダファイル，システムレベルの機能，システムAPI，開発ツールなどの問題を特定し，
多くの差異に自動的に対処します。SLPKは，バージョンの改訂ごとに自動化のレベルを高め，これらの差異の大部分に対処する
ことを目指しています。
手動によるコードの変更が必要な箇所については，Solaris-to-Linux Software Transition Kit（STK）の利用をお勧めします。必要な
コード修正のタイプについてより詳細に記載されています。また，STKは，いつSLPK移行環境が利用できるのかを理解するため
に利用することもできます。
SLPKは，32ビットおよび64ビットのC，C++コードをサポートしています。現在，以下のプラットホームとツールセットをサポートし
ています。
• Solarisバージョン：Solaris 8，Solaris 9
• Linuxディストリビューション：RHEL 2.1，RHEL 3，SLES 8，SLES 9
• Linuxコンパイラ：gcc 2.96，gcc 3.2.x，インテル® C++7.x，インテル® C++8.x
• Linuxプラットホーム：IA-32，インテル® EM64T，インテル® Itanium® ベースのシステム
最新情報については，www.hp.com/go/SLPKを参照ください。SLPK製品の入手方法に関する詳細については，同ページの案
内に従ってください。
33
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 34
6.4 シェル
UNIXのシェルは，Stephen Bourneのオリジナルのシェルから，2つの異なるシェルのジャンルを経由して進化を遂げました。第1
のジャンルは，POSIXシェル，Kornシェル（ksh）
，Bourne Again SHell（bash）
およびその他のいくつかを含む，Bourneシェルの派生
シェルです。第2のジャンルとしては，カリフォルニア大学バークレー校で開発されたCシェル
（csh）
とオープンソースのtcshが挙げ
られます。
以降のセクションでは，SolarisにインストールされているシェルのバージョンとLinuxにインストールされている同等のシェルとの
違いについて述べます。シェルを考察する場合には，2つの観点があります。1つはインタラクティブの観点，もう1つはシェルスク
リプトの観点です。SolarisからLinuxへの移行において，これらの観点はどちらも極めて重要です。Linuxで利用可能なシェルは，す
べてSolarisでも利用可能です。このため，ポーティングを行う前にシェルスクリプトの移植性を検査できます。
6.4.1 Bourne Again SHell（bash）
Bourne Again SHell（bash）は，Free Software FoundationのGNUプロジェクトの開発によるIEEE POSIX.2の完全な実装であり，
BourneシェルとPOSIXシェルの両方に対する互換性モードをサポートしています。デフォルトのモードは拡張されたBourneシェル
です。BASHシェルにはインタラクティブなコマンドライン編集，ジョブ制御など，Cシェル（csh）やKornシェル（ksh）
にも備わって
いる機能が含まれています。BASHシェルはほとんどのLinuxシステムでデフォルトのシェルです。
BASHシェルのデフォルトのモードは拡張されたBourneシェルです。POSIXモードでBASHシェルを起動するには，--posixオプショ
ンを使用してください。BASHが起動ファイルを読み込む前に --posixモードで起動するため に，BASHを起動する前に
POSIXLY_CORRECT環境変数を定義してください。
BASHシェルはSolarisでも利用可能なため，BourneおよびPOSIXのシェルスクリプトをSolaris上でBASHに移行し，その後，その
BASHスクリプトをLinuxに移行することも可能です。bash（1）の詳細については，www.gnu.org/software/bash/bash.html
を参照ください。
6.4.2 Bourneシェル（sh）
ほとんどのSolarisシステムにインストールされるデフォルトのシェルは，System V Bourneシェル（/bin/sh）です。このシェルを使
用しているSolarisのアプリケーション・スクリプトは，BASHのデフォルトのモード
（拡張されたBourneシェル・モード）を使用するは
ずです 。これは，Linuxシェルとの優れた互換性を提供しますが，若干の相違はあります。この他に，移植性の問題として，ps（1）
など，シェルスクリプトのコマンドの使用が挙げられます。これらのコマンドは，Solaris System V環境とLinux環境とでは動作が
異なります。
アプリケーションがSolaris Job Control Shell（jsh）を使用している場合にも，移植性の点で問題の発生する可能性があります。こ
のシェルは，最近のLinuxシェルの一部で見られる追加的なジョブ管理機能を備えたBourneシェルです。
6.4.3 POSIXシェル（sh）
Solarisでは，/usr/xpg4/bin/shにPOSIX準拠のシェルが含まれています。通常，このパスはLinuxには存在しません。ほとんどのLinux
システムにインストールされているデフォルトのシェルはBASHシェルです。BASHシェルはほぼPOSIX 1003.2および1003.2a規
格に適合するように制限されてきましたが，現在では拡張されています。Linuxコマンド/bin/shは，通常/bin/bashに対するシンボ
リックリンクです。セクション6.4.1にBASHシェルに関する追加情報を記載しています。
6.4.4 Kornシェル（ksh）
Kornシェル（ksh）は，1980年代半ば，ベル研究所のDavid Kornによって書かれたもので，既存のBourneシェルとの上位互換性を
備えています。KornシェルはCシェルの先進的な機能を数多く取り入れています。基本であるAT&Tバージョンのkshは11/16/88で
あり，これがSolarisで使用されているものです。kshの詳細については，www.kornshell.comを参照ください。Linux上にインス
トールされるKornシェルのバージョンは，Kornシェルのパブリックドメイン・バージョン（ksh または pdksh）です。コマンド
/bin/pdkshは，通常，/bin/kshに対するシンボリックリンクです。pdkshの詳細については，web.cs.mun.ca/~michael/pdksh/
を参照ください。
6.4.5 Cシェル（csh）
Cシェル（csh）は，構文がプログラミング言語Cに似たシェルとして，カリフォルニア大学バークレー校のBill Joyによって書かれ
ました。Cシェルによって追加された機能にはジョブ管理，履歴，エイリアス，チルダ置換，カスタマイズ可能な環境属性などがあ
ります。Joyは，サン・マイクロシステムズ社の創設者のひとりでもあり，Cシェルは多くのSolarisインストールでデフォルトのユー
ザー・シェルとなっています。CシェルはUNIXのシェルであり，LinuxではTurbo Cシェル
（tcsh）
と呼ばれるCシェルのオープンソース・
バージョンが利用できます。Cシェルのために書かれたスクリプトは，tcshに対して高い移植性を備えています。
6.4.6 Turbo Cシェル（tcsh）
Turbo Cシェル（tcsh）は，元々Berkeley Cシェルに対するパッチとして配付されたCシェルのスーパーセットです。現在は，同シェ
ルを無料バージョンとして書き直したChristos Zoulasが管理しています。Cシェルの機能のすべてに加え，コマンドライン・エディ
タ，インタラクティブ・ワードコンプリーションなどの新機能を備えたtcshは，Solarisでも，Linuxでも利用可能です。tcshの詳細に
ついては，www.tcsh.orgを参照ください。
34
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 35
6.4.7 Zシェル（zsh）
Zシェル（zsh）は，Solarisでも，Linuxでも利用可能であり，bash，kshおよびcshの機能を取り入れています。Solaris上でzshの
ために書かれたスクリプトは，Linuxに対する高い移植性を備えています。通常，Zシェルはデフォルトではインストールされま
せん。zshの詳細については，www.zsh.orgを参照ください。
6.4.8 環境の制限
ほとんどのSolarisシェルが使用するコマンドライン長の制限は，POSIXによって定義されているコマンドライン長を越えています。
Linuxの場合，コマンドライン長は，ベンダだけではなく，パッチのレベルによっても異なります。デフォルトのコマンドライン長は
通常，ほとんどの開発者にとって十分ですが，非常に長いコマンドラインが必要であれば，変更することも可能です。これらの制
限は，通常LINE_MAXおよびARG_MAX制限マクロ内に設定されています。制限の現在値をチェックするには，getconf（P）ユーティ
リティを使用してください。ポーティングに際するもう1つの問題は，シェルスクリプト内におけるハードコードされたパスの使用
です。一般にシステム固有の情報を設定するには，環境変数を使用するのが望ましい方法です。
6.5 統合開発環境（IDE）
Linuxでは，さまざまな統合開発環境(IDE)が提供されており，そのうちの多くがSolarisでも利用可能です。KDEプロジェクト
（www.kde.org）は，複数のプラットホームおよび言語（C/C++，Java，Fortran，その他）をサポートすると共に，CVSやClearCase
を含むいくつかのバージョン管理システムをサポートする豊富な機能を持ったIDEであるKDevelop（www.kdevelop.org）を提
供しています。GNOMEデスクトップ（www.gnome.org）
グループは，Anjuta（www.anjuta.org）
という名前のIDEを開発しまし
た。Ajunta IDEは複数の言語，プラットホーム，およびバージョン管理システムをサポートするフル機能のIDEです。KDevelopも，
Ajuntaも，少くとも部分的にはそれぞれのウィンドウ環境に統合されていますが，一般的な開発に利用することも可能です。
Eclipse IDE（www.eclipse.org）はSolaris，LinuxおよびHP-UXを含む複数のプラットホーム上で，C，C++およびJavaの開発をサ
ポートする先進的なプラグイン・ベースのIDEです。NetBeans IDE（www.netbeans.org）も複数のプラットホームで利用可能な
Java IDEです。NetBeansは，基本的には一般的なデスクトップ・アプリケーションである，核となる実行時環境を含む開発プラッ
トホームを提供します。この実行時環境はGUIを詳細に記述できます。
（Kdevelopと同様）Qtライブラリを
Linuxプラットホームでは商用の開発環境も利用できます。Trolltech（www.trolltech.com）は，
用いた開発をサポートするQt Designerを提供しています。Qtは完全なC++アプリケーション開発フレームワークであり，クロスプラ
ットフォーム開発と国際化のためのクラス・ライブラリとツールを含んでいます。QtのAPIおよびツールは，サポートされたすべて
のプラットホームで一貫しており，プラットフォームに依存しないアプリケーション開発と導入を可能にします。ここで，Kdevelop
とQt Designerの違いを説明する必要があります。
KDEおよびKdevelopは，どちらもQt C++GUIツールキットに依存しています。このツールキットはフリーソフト開発のため，無料
でソースコード形式が入手可能であり，自由な配布も可能です。しかし，これらのライブラリを利用して商用の開発を行う場合は，
TrollTechからライセンスを購入する必要があります。
BlackAdder（www.thekompany.com/products/blackadder/）も，Linuxプラットホームで使用できる商用アプリケーション
開発環境のひとつです。BlackAdderは，Pythonプログラミング言語，Ruby開発言語，Qtグラフィカル・ユーザ・インタフェース
（GUI）
ツールキット，ODBCデータベース接続性に加えて，エディタ，GUIデザイナ，デバッガ，インタラクティブPythonインタプリタを含
むIDEを提供します。
Linuxプラットホームで利用可能な商用のJava IDEのいくつかを以下に示します。
および
• Rational XDE（www.ibm.com/software/awdtools/developer/java/）
Websphere Studio（ www.ibm.com/software/awdtools/studioenterprisedev/）は，どちらもオープンソースのEclipse
IDEをベースにしていますが，UMLによる開発やWYSWYG GUIデザインといった付加機能が追加されています。
• Intellij（ www.jetbrains.com/idea/）の提供する商用Java IDEは，インテリジェントなコード支援，高度なリファクタリング，
CVSとJunitの統合など，数多くの先進的な機能を備えています。
• Borland’s JBuilder（www.borland.com/jbuilder/）は，JavaServer Facesエディタ，分散リファクタリング，Optimizeitパフォー
マンス・ツールを含む商用のJava IDEを提供します。
35
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 36
7 システムライブラリ，APIおよび実行時環境
本章では，アプリケーションのソースコード変更が必要となる可能性のある，ヘッダファイル，構造，API，および動作の違いについて
説明します。また，利用できるポーティングオプションについても，ある程度の指針を示します。しかし，Solaris APIの数量を考慮す
ると，すべてのAPIの完全な比較を行うことは本ガイドの範囲を越えています。
一般的に，SolarisからLinuxオペレーティングシステム
（OS）
にアプリケーションをポーティングすることは，単純かつ直接的な作業です。
この事実はポーティングに成功したアプリケーションの数の多さが実証しています。ほとんどのポーティングが円滑に進むことの根底
にある理由は，SolarisとLinuxがUNIX標準に準拠するように設計されていることにあります。しかし，注目すべきは，Solarisはいくつか
のUNIX標準への準拠を認定されていますが，Linuxはそうではないという点です。これは認定にかかるコストのためです。Linuxは正式
には認定を受けてはいませんが，標準を理解し，認定を受けた環境を利用してきた人々によって開発されました。この結果，標準に対
応したコードを，わずかな変更で，あるいは一切の変更なしに利用することが可能となっています。
HPは，Linux Standard Base（LSB）認定を受けたLinuxディストリビューションへアプリケーションをポーティングすることをお勧めしてい
ます。LSBは，POSIXを含む既存の標準規格群に強く依存したバイナリ標準です。LSBへのポーティングは，Solarisからのポーティング
作業の取りかかりを容易にしてくれる訳ではありません。しかし，いったんポーティングが完了すれば，より幅広いLinuxディストリ
ビューションを，より容易にサポートすることが可能となります。認定を受けたLinuxディストリビューションなど，LSBの詳細な情報
については，www.linuxbase.orgを参照ください。
7.1 システムライブラリおよびAPI
システム実行時ライブラリ
（libc，その他）は，SolarisおよびLinuxにおいて，同じような機能を提供しています。SolarisとLinuxは，ど
ちらも優れたPOSIX互換性を提供します。これらの標準に基づいて開発されたアプリケーションは，非常に高い移植性を備えてい
ます。
しかし，違いがないわけではありません。SolarisからLinuxへのアプリケーションのポーティングに伴う重要な作業として，非標準
システムAPIや非標準ライブラリの使用を確認することが挙げられます。これまでポーティングされたことがない古いアプリケー
ションの場合は特にこれが重要です。たとえば，Solarisは，POSIXスレッド標準よりも前にスレッド・ライブラリを提供しています。
アプリケーションがこれらの非標準スレッドAPIを使って開発されている場合には，移植性の問題に対処する必要があります。
一般的に，アプリケーションの移植性の問題は，以下の種類のうちの１つ，あるいは複数に分類されます。
• ライブラリの必要条件の違い
一部のSolaris APIはLinuxにも存在しますが，異なるライブラリにあります。たとえば，exp2（3M）は，Solaris上ではlibsunmathラ
イブラリに実装されています。Linuxにこのライブラリは存在しませんが，exp2（3）はlibmライブラリに実装されています。
• インクルードファイルの必要条件の違い
一部のSolaris APIはLinuxにも存在しますが，異なるインクルードファイルを必要とします。たとえば，getopt（3C）は，Solaris上
では stdlib.hを必要とするのに対し，Linux上ではunistd.hが必要です。
• APIおよびヘッダファイルの欠落
一部のSolaris APIおよびヘッダファイルはLinuxには存在しません。これらは主として非POSIX APIおよび非標準ヘッダファイル
に限定されます。この種の問題の例としては，openat（ 2）APIが挙げられます。このAPIはSolaris 9で追加されたものであり，
POSIXでは定義されておらず，Linuxには存在しません。
• APIプロトタイプおよびヘッダファイルの違い
一部のAPIプロトタイプおよびヘッダファイル宣言は，SolarisにもLinuxにも存在しますが，違いがあります。この種の例としては，
getdents（2）APIが挙げられます。このAPIは，SolarisとLinuxのどちらにおいてもdirent構造の引数を用います。しかし，Linuxにお
いてはこの構造が固定長であり，Solarisにおいては可変長のdirent構造となっています。
• APIのリターンタイプの違い
一部のAPIプロトタイプは，SolarisとLinuxで異なるリターンタイプを指定します。たとえば，Solarisのendhostent（3NSL）のリタ
ーンタイプはintですが，Linuxのendhostent（3）のリターンタイプはvoidです。
• errnoの違い
SolarisとLinuxには，動作が問題なく完了した場合には同様に機能するAPIがあります。しかし，errno値がPOSIXで指定されていな
い場合には，障害に際して異なるerrno値を返す可能性があります。たとえば，Linuxのopen（2）manページには，障害に際して，
errnoがENOMEMの値を返す可能性があるとが記載されています。しかし，Solarisにおいては，アプリケーション・コードがこの値
を取り扱うようにはなっていません。Solarisのopen（2）のためにドキュメントに記載されたerrno値ではないからです。このような
違いは，両方向に存在します。たとえば，Solarisにおいては，open（2）
に対する呼び出しの後に，EIO errno値を処理するアプリケー
ション・コードが存在するかもしれません。しかし，Linuxの実装においては，open（2）は，障害に際し，EIO値を設定するようには
ドキュメントに記載されていません。
36
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 37
• 機能と意味の違い
一部のLinux APIの実装においては，単に異なる機能が提供されていたり，わずかに違いのある機能が提供されていたりします。
たとえば，Solarisの実装において，fcntl（2）はF_DUP2FD，F_SHAREおよびF_UNSHAREフラグに対するサポートを提供していま
すが，これらのフラグはLinuxではサポートされていません。
ソースコード内に存在するこうした移植性の問題を確認するにはさまざまな方法があります。たとえば，コンパイラやリンカの
エラーや警告のメッセージを利用すれば，タイプの不一致やLinuxにおいて未定義のシンボルなどを確認することができます。ま
た，アプリケーション・コードに関する知識，慎重なコード点検，Linux APIに関する詳細な知識，そしてmanページの学習によっ
て，Linuxとの相違点の多くを確認することも可能です。最終的には，顧客にアプリケーションを最初にリリースする前に，テスト
スイートの使用、障害解析および実行時デバッギングを行うことにより残された移植性の問題の多くを確認することができます。
本章では，アプリケーションのポーティングを遂行するにあたって準備をよりうまく整えられるよう，特定のLinux APIに関する知
識を提供します。ただし，本章の冒頭で述べたとおり，Solaris APIの数の膨大さ，さらにアプリケーション実装に対してこの膨大
な量の情報ベースをマッピングすることの困難さのため，すべてのSolarisおよびLinux APIの完全な比較を行うことは困難です。
そこでHPは，このプロセスを自動化できるバイナリまたはソースコード・スキャン・ツールの使用をお勧めしています。これらの
ツールは完全無欠なものではありませんが，アプリケーション・モジュール全体にわたって反復可能なプロセスを実行し，一貫性
のある結果を提供します。また，こうしたツールを利用すれば，分析データを簡単に収集することができるので，ポーティングの
計画策定プロセスの初期において，移植難易度の査定，問題の確認，必要なスタッフの見積もりなどに利用することも可能です。
HP Solaris-to-Linux binaryScanユーティリティおよびHP Solaris-to-Linux Software Transition Kit（STK）
に関する詳細については，
セクション6.3をご覧ください。STKには，この作業において特に役立つ詳細なAPIの影響評価を収めたAPIアナライザが含まれて
います。
さらに，ポーティングチームの要望に応じて，コード変更における支援を提供するツールや，必要なコード変更を最小限に抑える
ためにLinuxシステム上でSolaris互換の実行時環境を提供するツールも用意しています。HP Solaris-to-Linux Porting Kit（SLPK）
には，2つのプラットホームの間の互換性のギャップに，APIおよび開発ツールのレベルで対処するためのソースコード・アナライ
ザと移行環境が含まれます。HP SLPKに関する詳細については，セクション6.3をご覧ください。
HPは，ポーティングチームがポーティングを開始する前に，可能な限り標準に準拠したAPIや機能を使用するようにアプリケーショ
ンのソースコードを修正することを検討するようお勧めしています。これにより，新しい対象となるLinuxプラットホームへのポーテ
ィングに必要な労力が軽減されると同時に，Solarisのコードベースも改善されます。この種のソースコード修正に対する一般的な
アプローチは，非POSIX APIをマクロセットやポーティングライブラリ内に隔離することです。Solarisの実装においては，ポーティング
不可能なSolaris API，またはポーティング可能なPOSIX APIとグルーコードのいずれかを使用することができます。その後，新しい
ポーティング可能なマクロセット，またはポーティングライブラリに対してSolaris上でユニットテストを行い，互換性を検証します。
一部のポーティングプロジェクトでは，アプリケーションのメモリモデルの変更がその目標として含まれる場合があります。一般
に，これは32ビットから64ビットのメモリモデルへの移行に伴うものです。この種のコードベース変更は，SolarisからLinuxへのア
プリケーションポーティングの前でも，または後でも行うことができます。これは，両方のオペレーティングシステムが，32ビット
および64ビットの開発環境をサポートしているためです。詳細については，第10章をご覧ください。
ポーティングの方法や目標に関わらず，コンパイラおよびリンカの警告オプションをすべて有効にしておくことを強くお勧めしま
す。発せられたビルド・メッセージについては，すべてを慎重に検討してください。また，ビルドツールが警告やエラーを報告する
ように設定しておくことはLinuxシステムにおいては重要なことですが，Solarisのビルドツールにおいてもメリットのある場合が少
なくありません。
7.2 Linuxで利用できないSolarisライブラリ
表7-1は，Linuxの同等のライブラリに対するSolarisライブラリのマッピングを示したものです。ただし，このマッピングは，Solaris
ライブラリに含まれるすべてのAPIについて，厳密に同等なライブラリを示したものではありませんので，ご注意ください。これら
のSolarisライブラリのAPIを使用するアプリケーションは，再コーディングやビルドの変更が必要となる可能性があります。これら
のAPIやライブラリを確認するには，Linuxのコンパイラおよびリンカが役に立ちます。これらのAPIに関しては，SolarisおよびLinux
のmanページを熟読することをお勧めします。
37
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 38
表7-1 欠けているSolarisライブラリおよびLinuxにおける代替
Solarisライブラリ
Linuxにおける代替
libcrypt.so
libbsdmalloc.so
libmalloc.so
libc.so
libmapmalloc.so
libmtmalloc.so
libsocket.so
libm9x.so
libm.so
libsunmath.so
libaio.so
librt.so
libposix4.so
libmd5.so
libsmbclient.so
libthread.so
Solaris互換のスレッドライブラリ
（SCTL）
に関する情報については，第8章をご覧ください。
Linuxには存在しないSolarisライブラリはかなりの数に上ります。これらのライブラリのAPIを使用するアプリケーションのポーテ
ィングには，再コーディングおよびビルドの変更が必要となります。これらのAPIやライブラリを確認するには，Linuxのコンパイラ
およびリンカが役に立ちます。表7-2は，こうしたライブラリの一部を示したものです。
表7-2 Linuxには存在しないSolarisライブラリ
liba5k.so
libdevinfo.so
liblcl.so
lib300.so
libdhcpagent.so
liblm.so
libssagent.so
libssasnmp.so
lib300s.so
libdhcpsvc.so
libmail.so
libsx.so
lib4014.so
libdhcputil.so
libnls.so
libsys.so
lib450.so
libdoor.so
libnvpair.so
libsysevent.so
libadm.so
libexacct.so
libpctx.so
libtermlib.so
libami.so
libExbridge.so
libplot.so
libtnf.so
libbz2.so
libfn_p.so
libprint.so
libtnfctl.so
libc2.so
libfn_spf.so
libproc.so
libtnfprobe.so
libc2stubs.so
libg_fc.so
libproject.so
libUil.so
libcfgadm.so
libGLw12.so
librac.so
libvolmgt.so
libcmd.so
libinetutil.so
librcm.so
libvt0.so
libcpc.so
libkcs.so
librtld_db.so
libwsreg.so
libcrypt_i.so
libkstat.so
libsecdb.so
libxfn.so
libdemangle.so
libkvm.so
libsmartcard.so
libxil.so
libdevice.so
liblayout.so
libsmedia.so
libXol.so
libdevid.so
7.3 Linuxで利用できないSolarisヘッダファイル
POSIXに対するSolarisおよびLinuxの互換性は，POSIX API由来のヘッダファイルの優れた互換性につながっています。一部の非
POSIXのSolaris APIについては，Linux上では異なるヘッダファイルで宣言されています。これらの一部については，表7-3で示す
ようにマッピングできます。
表7-3 Linuxヘッダファイルに対するSolarisヘッダファイルのマッピング
Solarisヘッダファイル
Linuxヘッダファイル
floatingpoint.h
math.h
sys/ieeefp.h
stdlib.h
rpc/rpcent.h
rpc/netdb.h
sunmath.h
math.h
widec.h
euc.h
wchar.h
さらに，異なるヘッダファイルのインクルードを必要とするAPIに遭遇する可能性も考慮しておく必要があります。たとえば，Solaris
においては， wctype（3C）関数やiswalpha（3C）などのisw*関数は，すべてwchar.hヘッダファイルをインクルードさせる必要があ
ります。一方，Linuxにおいては，これらの関数がwctype.hインクルードファイルをインクルードするようにアプリケーションを修正
する必要があります。
38
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 39
7.4 ファイルおよびファイル・ハンドル
ファイル管理に関しては，SolarisとLinuxのどちらもがPOSIXへの高い準拠性を備えています。読み込み，書き込み，ファイル状態
の管理，ファイルの所有権，ファイルのパーミッション，ファイルのシーク，ファイルのロック，ディレクトリ・エントリのAPI，およびそ
の他の類似したAPIに加え，creat（2）
，open（2）
，close（2）
，dup（2）などのAPIが，両方のオペレーティング・システムにおいてシス
テムコールとして実装されています。
mount（2）APIは，SolarisとLinuxの実装において，かなりの相違があります。主な相違点としては，引数の違い，Linuxにおいてはサ
ポートされているフラグが少ないこと，が挙げられます。この違いに対応するには，アプリケーションを再コーディングすることが
必要です。詳細については，mount（2）のmanページを参照ください。
directio（3C）APIは，Solarisでは利用できますが，Linuxには存在しません。HPは，より移植性の高い方法で同一の機能を実現する
ために，フラグをO_DIRECTにしてfcntl（2）を使用するようにアプリケーションを再コーディングすることをお勧めしています。
llseek（2）APIは，Solarisでは利用できますが，Linuxには存在しません。HPは，Linux上でlseek64（2）関数を使用するようにアプリ
ケーションを再コーディングすることをお勧めしています。
Solarisのflock構造体には，クラスタリングに対するより優れたサポートを提供するため，l_sysidメンバが含まれています。この構
造体メンバはLinuxには存在しません。
7.5 ネットワーク機能
Linuxのネットワーキング・スタックは，業界における最速のネットワーキング・スタックのひとつであり，長年にわたってIPv4とIPv6
をサポートしてきました。Linuxのデフォルトのネットワーキング・スタックはBSDソケットを提供します。STREAMSを必要とする
アプリケーションについては，www.gcom.com/home/linux/lis/でパッケージを入手可能です。
Linuxには，カーネルレベルでファイアウォールおよびルーティング機能が組み込まれています。さらに，IPX/SPX（Novell）
，DDP
（Apple）
，DECnet（Pathworks）など，他の伝送プロトコルをサポートするように設定することも可能です。
セキュリティやファイル共有についても，Linuxでは，Solarisと同様の方法がサポートされており，NFS（Version 2およびVersion 3）な
どの古典的なUNIXファイル共有技術が完全にサポートされています。また，LinuxはSMB（MS Windows）
ファイル共有など，他の
さまざまなネットワークのファイル共有技術に対する直接マウントをサポートしており，UNIXおよびWindowsの両方のホストに対
して，単一ソースからのファイルの共有を可能にしています。Solarisと同様，Linuxにおいても，セキュリティ認証はPluggable
Authentication Modules（PAM）を使用して処理されます。標準的なインストールでは，NIS/NIS+，LDAPなどを使用した認証を可
能にするモジュールが提供されます。
7.6 数学ライブラリ
SolarisとLinuxの数学ライブラリの基本的機能はよく似ています。本セクションでは，既存の標準に準拠したSolarisとLinuxに共通
する数学ライブラリ機能を詳述します。また，移植性に問題がある箇所を取り上げます。
7.6.1 組込まれた数学形式の比較
二進浮動小数点演算のためのIEEE標準規格であるIEEE Std 754-1985に規定されているとおり，SolarisとLinuxの32ビットおよび
64ビット・システムにおいては，float のサイズは32ビット，double は64ビットと定義されています。
long doubleの形式については，IEEE標準による規定がありません。long doubleはSolarisにおいても，64ビットLinuxにおいても，
128ビットであるため，32ビットまたは64ビットのアプリケーションをSolarisから64ビットLinuxへポーティングする際には問題とな
りません。しかし，32ビットLinuxシステムにおいては，long doubleの形式が96ビットであるため，この非標準形式においては精度が
失われます。
7.6.2 IEEEとFast Math
SolarisとLinuxシステムはどちらもIEEE Std 754-1985に準拠しています。この標準は浮動小数点の数や演算のビット・パターンと
動作を定義していますが，denormalやinfinityなど，いくつかの動作においては，期待できるパフォーマンスよりも低い結果となり
ます。Solarisの-fast，およびGCCの-ffast_mathコンパイラスイッチは標準への準拠度を緩和することで，パフォーマンスの大幅な
向上という結果をもたらします。わずかな精度の損失は許容できるトレードオフである場合が少なくありません。
7.6.3 ISO C数学ライブラリ関数
SolarisとLinuxはどちらも，虚数や複素数の浮動小数点のタイプや演算を含むC99※1標準を実装しています。これらの関数をSun
Studio 9あるいはそれ以前のリリースで使用するには，-lcplxsuppコンパイラフラグおよびlibcplxsupp.aライブラリをそろえる必
要があります。LinuxのGCCでは，complex.hをインクルードする以外には，いかなる特別なサポートも必要ありません。標準の数
学ライブラリへのリンクには，通常，両システム共に-lmコンパイラフラグが必要です。
※1 ANSI/ISO/IES-9899:1999 C 国際標準
7.6.4 POSIX数学ライブラリ関数
SolarisおよびLinuxはどちらも，IEEE Std 1003.1-2001（POSIX.1）標準の数学関数を実装しています。この標準は，C9910には含
まれていないベッセル関数などの数学関数をサポートしています。
39
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 40
7.6.5 Solaris数学ライブラリの拡張
Solarisの数学ライブラリには，ASCIIエンコードされた10進数の変換機能が含まれていますが，この機能はLinuxの数学ライブラリ
では利用できません。
Solaris 10以前のSolarisの数学ライブラリ関数の一部はlibsunmath.soに包含されました。Solarisはベクトル数学ライブラリ
（libmvec.a）
も提供しています。ベクトルライブラリ関数は，ほとんどのLinuxディストリビューションに含まれていませんが，サード
パーティから入手可能です。詳細についてはセクション7.6.6をご覧ください。
7.6.6 独自開発の数学ライブラリ
以下のような独自開発の数学ライブラリがLinuxで利用できます。
• HP Vector Math Library for Linuxは，CERNおよびヒューレット・パッカード研究所の共同開発による高パフォーマンス，高精度のベ
クトル数学ライブラリです。インテル® Itanium® 2 プロセッサベースの製品で利用可能であり，無料でダウンロードできます。詳細
については，www.hp.com/go/linuxdev/を参照ください。そこで，Linuxソフトウェアのリンクをたどるか，HP Vector Math
Library for Linuxを検索してください。
• Intel® Math Kernel Libraryは，インテル® プロセッサ上で最高のパフォーマンスを必要とするエンジニアリング，科学，金融アプ
リケーションのために設計された，高度に最適化されたスレッドセーフな数学ルーチンのセットです。最新のライブラリは，
インテル® のwww.intel.com/software/products/mkl/で入手可能です。
このライブラリには，以下の関数が含まれています。
— 線形代数（BLAS および LAPACK）
— 線形代数（PARDISOスパースソルバ）
— 高速フーリエ変換
— ベクトル数学ライブラリ
（VML）
— ベクトル統計ライブラリ
（乱数ジェネレータ）
• Intel® Cluster Math Kernel Libraryは，クラスタをサポートしていること以外は，Math Kernel Libraryとよく似ています。最新バージ
ョンは，インテル® のwww.intel.com/software/products/clustermkl/で入手可能です。
• Mathworks, Inc.のMATLAB® は，C，C++，FORTRANおよびJavaと互換性を持つ，人気の高い商用数学言語システムです。最新
バージョンのMATLABはMathworksのwww.mathworks.com/products/matlab/で入手可能です。MATLABは，32ビットお
よび64ビットlinuxの両方をサポートしています。
7.6.7 その他の検討事項
標準の数学ライブラリ関数を使用しているアプリケーションの大多数については，数学ライブラリごとに明確にポーティングを行
う必要があります。数値の最適化を行っている場合は，コンパイラによって動作が異なる可能性があるので注意が必要です。Linux
と共に提供される標準の数学ライブラリ，および前のセクションで述べた数学ライブラリに加え，インテル® のC++コンパイラ・
スイートも，標準ライブラリの代替ライブラリを提供しています。このライブラリはインテル® プラットフォーム向けに高度に最適
化されています。
GCCおよびインテル® C++コンパイラ・スイートは，どちらも特有の浮動小数点最適化機能を数多く備えています。
7.7 ライブラリの開発
SolarisとLinuxはどちらも，共有ライブラリという別名でも知られる，ダイナミック共有オブジェクト
（DSO）をバージョン管理する
方法を提供しています。外部的なバージョン管理の場合は，異なる名称，通常はバージョン文字列が埋め込まれた同一の名称を持
つ複数のライブラリが作成されます。また，一般に，最新リリースに対する参照として，バージョン文字列のないライブラリ名も同
時に作成されます。この方法は効果的であるものの，ほぼ同一のライブラリが数多くできてしまう原因ともなります。これに対処
するため，内部バージョン文字列を持つライブラリというコンセプトが誕生し，単一のライブラリで複数のリビジョンをサポートす
ることが可能となりました。Linuxはこのコンセプトをさらに推し進め，APIレベル毎のバージョン管理を可能としました。
Linuxにおいては，変更がごくわずかで，ほぼ互換性があるライブラリは，内部的なバージョン管理機能のみを利用してバージョン
管理が行われまています。一方，
（V1からV2などの）メジャーバージョンのリリースなど，大きな変更があった場合には，外部的な
バージョン管理機能も使用されます。たとえば，Linuxのlibcは，内部的なバージョン管理と外部的なバージョン管理の両方を使用
します。現行のlibcリリースは，x86システム上のlibc.so.6のファイル名を使用して，このライブラリがどのメジャーリリースをサ
ポートしているかを示します。内部的なバージョンは文字列GLIBCによって示され，ピリオド（.）
によって区切られた一連の数字が
その後に続きます。最初の数字はメジャーリリースを，2番目の数字はマイナーリリースを示し，それ以降の数字はパッチを示しま
す。たとえば，GLIBC_2.3.2は，GLIBCの2番目のメジャーリリースの3番目のマイナーリリースで，2番目のパッチレベルであるこ
とを示しています。
Linuxでの共有ライブラリ
（DSO）開発の歴史とプロセスを網羅した優れた文書が，people.redhat.com/drepper/dsohowto.pdf
で入手可能です。
40
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 41
7.8 セキュリティAPI
Linuxシステムのセキュリティは，SunSoftのDCE-RFC 86 Pluggable Authentication Modules（PAM）の仕様をベースにしています。
これはSolarisのPAMがベースにしているオープン標準と同一のものなので，LinuxはSolarisの実装に対して優れた互換性を提供し
ます。
SolarisとLinuxはともに，PAMによる認証を利用してローカルのDESおよびMD5暗号化パスワードファイルをサポートしています。
またPAMを利用してNISおよびNIS+サービスもサポートしています。NISサービスは，イエローページまたはYPサービスという別
名でも知られています。
詳細については，www.kernel.org/pub/linux/libs/pam/を参照ください。
ファイル・アクセス制御リスト
（ACL）は，標準的なUNIXファイルのオーナー，グループ，およびその他のアクセス許可よりもきめ細
かな許可モデルを実装しています。ファイルACLにより，追加ユーザやグループもファイルに対するアクセスを許可，拒否すること
が可能となります。ファイルACLは，Linuxのカーネル2.6以降ではデフォルトで利用可能であり，カーネル2.4用のパッチは
acl.bestbits.at.で入手可能です。RHEL 3.0およびSLES 8.0のカーネル2.4には，このパッチが収録されています。
41
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 42
8 スレッド
Solarisは3つの別個のスレッド・パッケージをサポートしています。
• Lightweight Processes。これはポーティング不可能な，プロプライエタリのスレッド・ライブラリです。
• Solaris Threads。プロプライエタリなスレッド・ライブラリです。類似したLinuxインタフェースにある程度マッピングすることがで
きます。代替として，オープンソースのSolaris互換のスレッド・ライブラリもLinuxで利用可能です。
• POSIX Threads。プラットホーム間の移植性が非常に高いスレッドです。
Linuxには，2つのPOSIXおよびSolarisスレッド互換のライブラリ実装をはじめとして，数多くのスレッドパッケージがあります。以下の
POSIXスレッドパッケージは問題なくLinuxで利用できます。
• LinuxThreadsは，2.2および2.4のカーネルで利用可能であった古いモデルです。
• Native POSIX Thread Library（NPTL）は新しいモデルであり，2.6のカーネルで利用できます。可能であれば，NPTLの使用をお勧め
します。
Solaris-compatible Threads Library（SCTL）
は，SolarisからLinuxへの移行を支援するためにHPが開発しました。このライブラリは他のプ
ラットホームでも利用可能です。LinuxのためのSolarisのスレッド・ライブラリの詳細は，www.sourceforge.net/projects/sctlを参
照ください。また，追加情報については，www.opensource.hp.com/the_source/linux_papers/scl_solaris.htmを参照くだ
さい。
Linuxでは，LWPやDCE実装など，別のスレッド・パッケージも利用できます。これらのパッケージに関しては，Linux Documentation
Projectに情報があります。 www.tldp.org/FAQ/Threads-FAQ/を参照ください。
8.1 Solarisのスレッド・モデル
スレッド化されたSolarisアプリケーションの大半は，以下の3つのスレッド・モデルのうちの1つを使用します。本セクションで説明
しますが，使用するモデルによって移植性は大きく変化します。
8.1.1 Lightweight Processes（LWP）
Lightweight Processes（LWP）は，Solaris上のプロプライエタリなスレッド実装であり，POSIX 1003.1c標準には準拠していませ
ん。このスレッド・モデルを使用しているアプリケーションは移植性がないため，ポーティングするにはPOSIXスレッドに変換する
必要があります。この変換はSolaris上で実装することが可能であり，アプリケーションのポーティングを始める前に，アプリケー
ション・ソースを準備することができます。あるいは，アプリケーションのポーティング作業の一環として，このスレッド作業を
Linux上で行うことも可能です。
8.1.2 Solaris Threads
Solaris Threadsは，プロプライエタリな非POSIXスレッド・ライブラリで，libthread.soというライブラリを使用します。セクション
8.3に記述しているとおり，Solaris Thread APIの多くがNPTL APIにマッピング可能です。
この他にも，移植性を高めるためにアプリケーションがPOSIXスレッドを使用するように変換する，あるいは，Linuxにおいて最小
限の修正でコードをサポートできるようにSCTLを使用する，という選択肢もあります。
8.1.3 Solaris POSIX Threads
Solarisは，libpthread.soを使用するPOSIX 1003.1cスレッドをサポートしています。POSIX Threads自体はSolaris Threads，あるいはLWP
上に階層化されます。POSIXインタフェースを使用しているSolarisプログラムは，Linuxに容易にポーティングできるはずです。
8.2 Linux POSIX Threadsモデル
2つのLinuxスレッド・モデルは，いずれもPOSIX 1003.1c APIを実装しています。以降のセクションでは，2つのモデルについてさ
らに詳細に説明します。
8.2.1 LinuxThreads
LinuxThreadsは，1つのLinuxスレッドが単一のLinuxプロセスであるというカーネル・スレッド・モデルとして，1996年に開発されま
した。これは，1対1のスレッド・モデルと呼ばれており，スレッド間のコンテキスト切り替えはLinuxカーネルによって実行されます。
このモデルの利点のひとつとして，マルチ・プロセッサを活用できるという点が挙げられます。LinuxThreadsは，POSIX 1003.1
ベースの機能に加え，シグナルハンドリングを除くオプション機能の一部を実装しています。
このスレッド・パッケージは2.4カーネル上で最も一般的なLinuxスレッド・パッケージで，GNU libcバージョン2に含まれており，す
べての現行ディストリビューションの一部として提供されています。LinuxThreadsはPOSIXのスレッド実装によく似ていますが，多
くの違いがあります。標準的なLinuxスレッド・パッケージの詳細については，pauillac.inria.fr/~xleroy/linuxthreads/を参照く
ださい。
8.2.2 Native POSIX Thread Library for Linux（NPTL）
Native POSIX Thread Library（NPTL）は旧式のLinuxThreadsの代替であり，POSIX標準により近くなっています。NPTLに対するサ
ポートは2.6カーネルで開発され，NPTL APIはGNU libcに含まれています。LinuxThreadsと同様，NPTLは1対1のモデルとして実
装されていますが，新しいカーネルへの変更により，パフォーマンスが大きく向上しています。さらに，NPTLでは，シグナルおよ
42
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 43
びNUMAのサポートも提供されています。NPTLは2.6カーネルと共に開発されましたが，2.4カーネルのディストリビューションの
一部にもバックポーティングされています。
新しいスレッド実装に関するいくつかの有用な洞察を提供している設計ホワイト・ペーパーが，
www.redhat.com/whitepapers/developer/POSIX_Linux_Threading.pdfで入手可能です。
8.3 Linux NPTL APIに対するSolaris Threadsのマッピング
表 8-1は ，Solaris Threadsと NPTLスレッド の インタフェー ス を 比 較し た も ので す。こ の マッピ ング に 関 す る 追 加 情 報 は ，
www.redhat.com/docs/wp/solaris_port/c1347.htmlで入手可能です。
表8-1 Solaris Threads と Linux NPTL Solaris Threadsの比較
Solaris Threads
thr_create
Linux NPTL
pthread_create
thr_create（daemon）
プロセスが終了しても，終了しないデーモンスレッドを生成
対応なし
thr_min_stack
スレッドに許容される最小のスタックを戻す
PTHREAD_STACK_MIN
POSIXスレッドによって定義される定数
thr_exit
pthread_exit
thr_join
pthread_join
thr_self
pthread_self
thr_main
43
呼び出しているスレッドが一致するスレッドであれば，trueを戻す
対応なし
thr_continue
対応なし
thr_suspend
対応なし
thr_yield
sched_yield
thr_getconcurrency
pthread_getconcurrency
thr_setconcurrency
pthread_setconcurrency
thr_getprio
pthread_getschedparam
thr_setprio
pthread_setschedparam
mutex_init
pthread_mutex_init
mutex_destroy
pthread_mutex_destroy
mutex_lock
pthread_mutex_lock
mutex_trylock
pthread_mutex_trylock
mutex_unlock
pthread_mutex_unlock
cond_init
pthread_cond_init
cond_wait
pthread_cond_wait
cond_timedwait
pthread_cond_timedwait
cond_signal
pthread_cond_signal
cond_broadcast
pthread_cond_broadcast
cond_destroy
pthread_cond_destroy
rwlock_init
pthread_rwlock_init
rw_rdlock
pthread_rwlock_rdlock
rw_tryrdlock
pthread_rwlock_tryrdlock
rw_wrlock
pthread_rwlock_wrlock
rw_trywrlock
pthread_rwlock_trywrlock
rw_unlock
pthread_rwlock_unlock
rwlock_destroy
pthread_rwlock_destroy
sema_init
sem_init
sema_wait
sem_wait
sema_trywait
sem_trywait
sema_post
sem_post
sema_destroy
sem_destroy
thr_sigsetmask
pthread_sigmask
thr_kill
pthread_kill
sigaction
sigaction
kill
kill
sigwait
sigwait
sigaction
sigaction
thr_keycreate
pthread_key_create
thr_setspecific
pthread_setspecific
thr_getspecific
pthread_getspecific
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 44
8.4 Linuxスレッドの実装に関する追加情報
本セクションでは，LinuxにおけるNPTLとLinuxThreadsの実装に関する追加情報を提供します。
8.4.1 移植性のない Solaris POSIX Threadインタフェース
SolarisとLinuxはどちらもPOSIX 1003.1cを実装しています。したがって，POSIXスレッドのAPIを使用するSolarisコードは，
Linuxに簡単にポーティングできるはずです。しかし，“_np” APIサフィックスで示されている以下のSolaris POSIXスレッド・イ
ンタフェースはLinuxでは利用不可能であり，ポーティングできません。アプリケーションのソースコードがこれらのルーチン
のいずれかを使用している場合は，若干の再コーディングが必要です。
pthread_cond_reltimedwait_np()
pthread_mutexattr_getrobust_np()
pthread_mutexattr_setrobust_np()
pthread_mutex_consistent_np()
pthread_mutex_reltimedlock_np()
pthread_rwlock_reltimedrdlock_np()
pthread_rwlock_reltimedwrlock_np()
また，以下のスレッド機能は，オプションのPOSIXスレッドAPIの一部です。Solarisのpthreadsはオプションの実装を提供しますが，
Linuxの実装は提供しません。
_pthread_mutexattr_getpriorceiling()
_pthread_mutexattr_setpriorceiling()
pthread_mutexattr_getprotocol()
pthread_mutexattr_setprotocol()
pthread_mutex_getpriorceiling()
pthread_mutex_setpriorceiling()
8.4.2 POSIXスレッド属性デフォルト値
表8-2は，Solaris，NPTLおよびLinuxThreadsの，POSIXスレッドの属性およびそれらのデフォルト値を示しています。これらは，POSIX
標準，およびNPTLとLinuxThreadsのヘッダファイルで定義されてます。詳細は，LinuxおよびSolarisの pthread_attr_init（3）を参照
ください。
表8-2 SolarisおよびLinuxにおけるPOSIX属性のデフォルト値
Solaris Threads Attribute［デフォルト値］
contentionscope
［PTHREAD_SCOPE_SYSTEM］
detachstate
［PTHREAD_CREATE_JOINABLE］
guardsize
LinuxThreads および NPTL Attribute［デフォルト値］
scope
［PTHREAD_SCOPE_SYSTEM］
detachstate
［PTHREAD_CREATE_JOINABLE］
［ドキュメントに記載なし，黙殺］
［PAGESIZE］
inheritsched
［PTHREAD_EXPLICIT_SCHED］
policy
［SCHED_OTHER］
priority
［0］
stackaddr
［なし］
stacksize
［Solarisの調整可能なパラメータとして設定］
inheritsched
［PTHREAD_EXPLICIT_SCHED］
schedpolicy
［SCHED_OTHER］
schedparam
［0］
stackaddr
［なし］
stacksize
［プラットホーム※1に依存］
※1 設定されている場合は，プロセス制限に影響を受けます。
8.4.3 POSIX Threadsヘッダファイル
ほとんどのLinuxシステムでは，NPTLのヘッダファイルは /usr/include/nptl/pthread.hにあります。また，LinuxThreadsのヘッダフ
ァイルは，一般に/usr/include/pthread.h.にあります。アプリケーションをビルドする際に適切なインクルードパスを指定するには，
コンパイラの-I<path>オプションを使用します。
8.4.4 POSIX Threads共有ライブラリ
NPTLライブラリは，一般に/usr/lib/nptlディレクトリに置かれています。このライブラリにアクセスする好ましい方法は，-L<path>リ
ンカ・オプションを使用することです。
44
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 45
8.4.5 POSIX Threadsアプリケーションのコンパイル
GNU GCCコンパイラを使用する際には，-pthreadコンパイラフラグを使用します。ビルド時には，CFLAGSおよびLDFLAGSとい
うmake変数と環境変数を使用して，適切なヘッダファイルとライブラリを指定します。これにより，間違ったスレッド・パッケージ
のコンポーネントを参照することに起因する問題を回避することができます。
8.4.5.1 LinuxThreadsを使用したコンパイル
以下の例は，単純なLinuxThreadsアプリケーションをコンパイルする方法を示したものです。
gcc -pthread testthread.c -o testthread
8.4.5.2 Native POSIX Thread Libraryを使用したコンパイル
以下の例は，NPTLを使用してスレッド化された単純なアプリケーションをコンパイルする方法を示したものです。
gcc -pthread testthread.c -o testthread -I/usr/include/nptl -L/usr/lib/nptl
45
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 46
9 エンディアンについての検討事項
本章では，Solarisが稼働するSun SPARCシステムからLinuxが稼働するHP IntegrityまたはProLiantサーバへ，コードおよびデータを移行
する際の問題について説明します。
9.1 概要
Sun SPARCシステムと，Linuxが稼働するHP Integrity，ProLiantサーバとでは，エンディアンのモデルが異なります。これは，アプ
リケーションをポーティングする際に大きな問題となる可能性があります。エンディアンとはデータが格納される形式のことで，
整数および浮動小数点データ形式においてバイトがどのようにアドレス指定されるのかを定義しています。HP Integrityおよび
ProLiantサーバー上のLinuxはリトル・エンディアンとして実装されています。リトル・エンディアンでは，最下位のバイトが最下位の
メモリアドレスに，最上位のバイトが最上位のメモリアドレスに格納されます。Sun SPARCプラットホームはビッグ・エンディアン
です※1。ビッグ・エンディアンでは，最上位のバイトが最下位のメモリアドレスに，最下位のバイトが最上位のメモリアドレスに格納
されます。以下は，64ビット長の整数の配置の例です。
※1 Sun Solaris Operating System x86 Platform Editionはリトル・エンディアンです。
下位アドレス
上位アドレス
リトル・エンディアン
バイト0
バイト1
バイト2
バイト3
バイト4
バイト5
バイト6
バイト7
ビッグ・エンディアン
バイト7
バイト6
バイト5
バイト4
バイト3
バイト2
バイト1
バイト0
たとえば，1025という値を持つ32ビットの整数を，4バイトの配列として見た場合は，まったく違って見えます。
リトル・エンディアン
ビッグ・エンディアン
Char*[0] = 0x01
Char*[0] = 0x00
Char*[1] = 0x04
Char*[1] = 0x00
Char*[2] = 0x00
Char*[2] = 0x04
Char*[3] = 0x00
Char*[3] = 0x01
エンディアンの問題は，ポーティングにおいて，ビットマスクが使用された際，または間接ポインタがオブジェクトの部分をアドレ
ス指定した際に顕在化します。CおよびC++言語は，エンディアン問題への対処を支援するビットフィールドを実装します。HPは，
マスクフィールドよりもビットフィールドの使用をお勧めします。
エンディアンを理解することが重要である局面のひとつとして，エンディアンの順序が異なるシステム間で，ファイルあるいはネッ
トワーク経由でデータ交換する必要のある場合が挙げられます。整数あるいは浮動小数点データをバイナリ形式で保存する場合，
データを保存したシステムのエンディアン方式も保持されます。同様に，他のシステムにバイナリの整数あるいは浮動小数点デー
タを送信する場合も，送信を行うシステムのエンディアン方式が保持されます。整数あるいは浮動小数点データをやりとりする際
には，共有ストレージメディアにデータを保存する場合も，データ通信経由で送信する場合も，データを共有するシステムで使用
する共通形式に変換してください。
IPネットワーク標準は，ネットワークのパケット・ヘッダがネットワークのバイト・オーダを使うことを指示しています。ネットワーク
のバイト・オーダは，プラットフォームに依存しないバイト配列の基準となる形式であり，ビッグ・エンディアンとして定義されてい
ます。これは，ホストのバイト・オーダとは対照的です。ホストのバイト・オーダはプラットホーム固有であり，ビッグ・エンディアン
あるいはリトル・エンディアンのどちらかです。16ビットおよび32ビットの整数をホストのバイト・オーダからネットのバイト・オー
ダに変換するために，関数が用いられます。32ビット整数を変換するにはhtonl（3）
とntohl（3）を，16ビット整数を変換するにはhtons（
とntohs（3）を使用します。64ビット用の標準的な関数群はありませんが，Linuxではbswap_16，bswap_32およびbswap_64マクロ
が提供されています。これらの関数およびマクロは，ビッグ・エンディアン・システムにも，リトル・エンディアン・システムにも存在
します。
9.2 永続的データ
データの読み込み，あるいは書き込みの際には，バイト・オーダに注意を払う必要があります。マルチバイトの値は，作成元および
引き渡し先のシステムのエンディアンが，それぞれどちらであっても構わないように，前処理する必要があります。以下のコード
の例を考えましょう。ここでは，データの書き込みと読み込みを行うシステムが，どちらも同じエンディアン方式を実装しているも
のとします。
書き込み側のコード
#include <unistd.h>
#include <inttypes.h>
46
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 47
int64_t val = 1;
ssize_t result = write( fileDes, &val, sizeof(val) );
読み込み側のコード
#include <unistd.h>
#include <inttypes.h>
int64_t valRead;
ssize_t result = read( fileDes, &valRead, sizeof(valRead) );
書き込み側のシステムと読み込み側のシステムが同じエンディアン方式を使用していれば，valReadの内容は1です。しかし，書き
込み側と読み込み側のバイト・オーダが異なる場合，valReadの内容は0x0100000000000000になります。
永続的データをネイティブのエンディアン形式で格納しているアプリケーションについては，共有または移行されたデータ・ソー
スのエンディアン問題を回避できるように再設計する必要があります。古いデータの変換は別のプロセスで行うことにより，主要
なアプリケーションに対するエンディアン非依存の開発に集中することができます。前の例では整数データを使用していますが，
浮動小数点データもエンディアンに依存します。
以下に，エンディアンに依存しない形式でデータを格納する方法をいくつか示します。
• 定義されたエンディアン形式でデータを格納する。
• 形式を示す追加データを付加する。
• すべてのデータをASCII 文字列として格納する。
定義されたエンディアン形式でデータを格納するのが，オーバヘッドが最小なので，最も好ましい方法です。
これは，エンディアンに依存しない入出力関数を開発することにより実現できます。入出力関数は以下の方法で開発できます。
• コンパイル時の制御を使用する
• 実行時の制御を使用する
• データ形式が標準化されている関数を使用する
（htons( )および類似した関数を使用）
以下のセクションでは，これらの方法をひとつひとつ説明します。
9.2.1 プリプロセッサによるバイト・オーダ制御
エンディアンに基づいて実装方法を変える必要のある関数を制御するために，プリプロセッサを使用できますが，標準化はされて
いません。コンパイラがエンディアンを調べる手段を提供するように規定している標準は現在ありません。しかし，提供できない
わけではありません。これを実現するには，プラットフォームのエンディアンの種類を調べる手段を独自に実装する必要がありま
す。Linuxには，BYTE_ORDERを定義するendian.hヘッダファイルがあります。また，Solarisにも/usr/includeに類似したファイルが
あります。
例9-1は，このような状況に対処するコードを開発する方法の例を示したものです。
例9-1 プリプロセッサを使用したマルチバイト・オーダのサポート
#if defined(__linux)
#include <endian.h>
#endif
#if !defined (BIG_ENDIAN)
#define BIG_ENDIAN 4321
#endif
#if !defined (LITTLE_ENDIAN)
#define LITTLE_ENDIAN 1234
#endif
#if !defined(BYTE_ORDER)
#if defined(__hpux) || defined(__sparc)
#define BYTE_ORDER BIG_ENDIAN
#elif defined(__osf__) || defined (__linux)
#define BYTE_ORDER LITTLE_ENDIAN
#endif /* BYTE_ORDER */
#if BYTE_ORDER == BIG_ENDIAN
/* some code that depends on big-endian byte ordering */
⋮
47
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 48
#else
/* some code that depends on little-endian byte ordering */
⋮
#endif
9.2.2 実行時のバイト・オーダ制御
エンディアン対応のコードを開発するためのもうひとつの方法としては，実行時にエンディアンの種類を動的に調べる方法が挙げ
られます。この方法は，ソフトウェアには通常エンディアンに関するバグがあるということを利用しています。例9-2のルーチンを
使用して，エンディアンの種類を調べてください。これにより，コードがリトル・エンディアン・システムで実行されているか，ビッ
グ・エンディアン・システムで実行されているかを調べ，リトル・エンディアンまたはビッグ・エンディアンのデータのいずれかを動
的に取り扱うことが可能になります。
例9-2 バイト・オーダのテスト
#include <inttypes.h>
bool TestBigEndian(void)
{
int16_t one = 1;
char *cp = (char)&one;
if ( *cp == 0 ) {
return true;
}
return false;
}
9.2.3 標準のバイト・オーダAPIの使用
標準化されたエンディアン関連のAPIを使用すると，コードの移植性を高めることができます。このようなAPIセットとしてhost-tonetworkファミリがあります。これらのAPIを使用してアプリケーション・データを格納すると，データはビッグ・エンディアン（ネッ
トワーク・バイト・オーダ）で格納されるため，エンディアン・ネイティブの形式よりも移植性が良くなります。
host-to-network/network-to-hostのバイト・オーダ変換関数（htons（3）
，htonl（3）
，ntohs（3）
，およびntohl（3））は高度に最適化され
ており，リトル・エンディアン・システムではわずか数個の命令になるはずです。例9-3は，htons（ ）関数を使用して，16ビット整数
をホスト・バイト・オーダからネットワーク・バイト・オーダに変換しています。
例9-3 16ビット整数にhtons（3）ルーチンを使用する
#include <inttypes.h>
int16_t w = 0x1234;
printf(“Host Order w=%04x\n”, w);
printf(“Network Order w=%04x\n”, htons(w));
例9-4では，htonl（ ）関数を使用して，符号無し32ビット整数をホスト・バイト・オーダからネットワーク・バイト・オーダに変換して
います。
例9-4 32ビット整数にhtonl（3）ルーチンを使用する
#include <inttypes.h>
int32_t w = 0x12345678;
printf(“Host Order w=%08x\n”, w);
printf(“Network Order w=%08x\n”, htonl(w));
host-to-network APIの問題点は，扱えるのが16ビットと32ビットのデータ要素のみであるという点です。Linuxでは，bswap_16，
bswap_32，および bswap_64というバイト・スワップ・マクロ群が提供されています。これらの関数およびマクロは，ビッグ・エン
ディアン・システムにも，リトル・エンディアン・システムにも存在します。byteswap.hヘッダファイルには，これらのマクロが含ま
れます。例9-5は，bswap_64マクロの使用法を示したものです。32ビット，または64ビットのLinuxシステムでも検証できます。
48
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 49
例9-5 bswap_64()マクロを使用した64ビットのHost to Network
#include <inttypes.h>
#include <byteswap.h>
uint64_t w = UINT64_C(0x123456789abcdef);
printf(“Host Order w = %016llx\n”, w);
printf(“Network order w =%016llx\n”, bswap_64(w));
9.3 バイト・スワッピング
マルチバイトの値を持つデータをリトル・エンディアン・システムとビッグ・エンディアン・システムの間で転送する必要がある場合
には，バイト・オーダをスワップするプログラムを用意しなくてはなりません。ネットワークやソケット通信では，host-to-network
API（htons（3）
，htonl（3）
，ntohs（3）
，および ntohl（3）
）を使用します。
残念ながら，これはデータ構造のレイアウト，およびデータ構造内のデータの形式を熟知していなければ解決できない問題です。
このような知識があれば，データを再整理する正しい方法を決定することができます。たとえば，文字列は通常スワップする必要
はありません。64ビット要素は，8バイトの両端を逆にするようにスワップする必要があります。32ビット要素は，4バイトの両端を
逆にするようにスワップする必要があります。一般に，それぞれのデータ形式に関して，そのデータがソース
（ネットワーク，ディス
ク，その他）
においてはどのように表現されるのか，行先ではどのように表現されるのかを理解しておく必要があります。
以下に示す種類の入出力はエンディアンに関して透過的なので，スワップを行う必要はありません。
• バッファのデータ。これは，下位のアドレスのバイトを下位のアドレスに格納したままにするので，実際にはバイトの配列です。
• C++のフレームワーク・クラスで読み書きされるデータ。フレームワーク・クラスでは，常に型のタグが付いた圧縮したバイナリ
形式でデータをディスクに格納します。この処理は，どちらのコンピュータでもデータの読み書きができるようにするために行
われます。ディスク上のデータ形式はどちらの種類のコンピュータでも同じになります。
• 一時ファイル。起動中のアプリケーションが書き込んだ後に読み取り，アプリケーションの終了前に削除されるファイルです。
• バイトをスワップするもうひとつの方法としては，swab（3）
（バイトのスワップ）APIの使用が挙げられます。構文は以下のとおり
です。
void swab (
const void *src,
void *dest,
ssize_t nbytes);
プリプロセッサ・マクロを定義することもできます。32ビット・データでリトル・エンディアンをビッグ・エンディアンに変換するコード
は，例9-6に示したようになります。
例9-6 32 ビットのエンディアン・バイト・スワップ・マクロ
#include <inttypes.h>
#define SWAP_4_MACRO(value) \
((( (value) & UINT32_C(0x000000FF)) << 24) | \
(( (value) & UINT32_C(0x0000FF00)) << 8) | \
(( (value) & UINT32_C(0x00FF0000)) >> 8) | \
(( (value) & UINT32_C(0xFF000000)) >> 24))
64ビット・データのバイト・オーダを入れ替えるためのマクロを，例9-7に示します。
例9-7 64 ビットのエンディアン・バイト・スワップ・マクロ
#define SWAP_8_MACRO(value) \
(((((((( (value)>>8) & EVENBYTESL)
|\
(( (value)<<8) & ODDBYTESL))>>16) & EVENWORDSL) | \
((((( (value)>>8) & EVENBYTESL)
|\
(( (value)<<8) & ODDBYTESL))<<16) & ODDWORDSL))>>32 ) | \
((((((( (value)>>8) & EVENBYTESL)
|\
(( (value)<<8) & ODDBYTESL))>>16) & EVENWORDSL) | \
((((( (value)>>8) & EVENBYTESL)
|\
(( (value)<<8) & ODDBYTESL))<<16) & ODDWORDSL)) << 32 ))
異なるアーキテクチャ間でデータを移動する際には，バイト・スワップが必要になる可能性があります。しかし，このバイト・スワッ
プは，必ずしもコードのパフォーマンスに大きな影響を及ぼすわけではありません。2，4または8-バイトの値をスワップするのに
49
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 50
必要なコードはわずか数個の命令であり，すべてレジスタ内で簡単に実行されます。大規模な配列のようにスワップするデータ
が多い場合でも，コード全体がキャッシュに収まるように小さなループに収めることで，データ・キャッシュからシーケンシャル
にデータを取り出せるため，きわめて効率良く処理できます。コードを移行する前に，データの形式をよく把握してください。こ
うしておけば，データの保全性に関する問題を避けることができます。
9.4 浮動小数点データ
浮動小数点データもエンディアンに影響を受けます。たとえば，値1.0の浮動小数点形式は，リトル・エンディアン・システム上では
以下の整数値として保存されます。
0x0000803f
ビッグ・エンディアン・システムでは，同じ値が以下のようにメモリに保存されます。
0x3f800000
例9-8に，浮動小数点の値をリトル・エンディアン・システムからビッグ・エンディアン・システムに変換する方法のひとつを示します。
例9-8 浮動小数点値のスワップ
#include <inttypes.h>
union int_float {
int32_t int_val;
float flt_val;
};
union int_float my_var, swapped_var;
swapped_var.int_val = htonl(my_var.int_val);
9.5 未使用バイト
メモリを効率的に使用しようとするプログラムにおいては，32ビット整数内の4バイトがすべて使用されているわけではない，とい
う事実を利用することがあります。たとえば，あるレコードの特定のintフィールドに0から10,000,000の範囲の値しか格納されな
いとすれば，最上位を意味するバイト は必ず0 になります。1バイトの領域しか必要としない要素を格納するため，構造体に要素
を付加する代わりに，この空きバイトを使用することも少なくありません。
最上位を意味するバイトが，文字配列を用いて，またはポインタをキャスト，デリファレンスすることによってアクセスされている
場合，コードには移植性がなくなり，ビッグ・エンディアン・コンピュータとリトル・エンディアン・コンピュータで少し異なるバー
ジョンが必要になります。例9-9に，この直接バイト・アクセスの例を示します。
例9-9 直接バイト・アクセス
#include <inttypes.h>
typedef union freebyte {
int32_t intdata;
char chardata[4];
} mystruct;
#define set_int(s, x) \
(s).intdata = (((s).intdata&0xFF000000) | (x&0x00FFFFFF))
#define get_int(s) ((s).intdata & 0x00FFFFFF)
/* The char accessors are endian specific! */
#define set_char(s, x) (s).chardata[3] = x
#define get_char(s, x) (s).chardata[3]
これに対して，名前付きビット・フィールドとして実装すると，コンパイラはエンディアンの形式を問わず，正しい命令列を生成でき
るようになります。例9-10に示すように，直接バイト・アクセスの問題を解決することができます。
例9-10 名前付きビット・フィールド
#include <inttypes.h>
typedef union freebyte {
int32_t _3byte:24;
int32_t _1byte:8;
} mystruct;
50
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 51
#define set_int(s, x) (s)._3byte = x
#define get_int(s) (s)._3byte
#define set_char(s, x) (s)._1byte = x
#define get_char(s) (s)._1byte
このようにビット・フィールドを使用することで，エンディアンの問題を解決できると同時に，メモリ占有量を削減することができ
ます。また，それぞれの要素が正当な要素になるため，アクセス・マクロも不要となります。
9.6 共用体
共用体を利用し，共用体内のデータ・レイアウトに仮定を設けているアプリケーションでは，エンディアンによって移植性が問題に
なります。例9-11に，このような共用体の例を示します。
例9-11: エンディアンと共用体
#include <inttypes.h>
union int_byte {
int32_t int_val;
char byte[4];
};
union int_byte my_var;
my_var.int_val = 1000000;
if(my_var.byte[3] == 0)
printf(“The number is divisible by 256\n”);
ビッグ・エンディアン・マシンでは，このコードは正しく動作します。byte[3]は，数値が0，または256の倍数のときだけ0になります。
しかし，リトル・エンディアン・マシンでは，byte[3]は最上位のバイトです。この問題を回避する最も簡単な方法は，コンパイラの裏
をかこうとしないことです。エンディアンに依存しないコードを使用すれば，問題を回避し，同じ結果を得ることができます。以下
にその例を示します。
If ((my_var.int_val & 0xFF) == 0)
printf(“The number is divisible by 256\n”);
さらに良い例を以下に示します。
If ((my_var.int_val % 256) == 0)
printf(“The number is divisible by 256\n”);
9.7 マルチワード・エンティティの32ビット単位での初期化
マルチワード・エンティティを32ビット・エンティティで初期化しているコードをポーティングする場合は，注意が必要です。たとえ
ば，Solarisなどのビッグ・エンディアン・システムにおいて，2つの32ビット整数値からなる配列を使用して，64ビットの倍精度浮動
小数点数を初期化する場合を考えます。
u.ul[0] = 0xFFFFFFFF;
u.ul[1] = 0x7FFFFFFF;
Linuxなどのリトル・エンディアン・システムで正しい結果を得るには，次のように，要素を逆にして，バイト・オーダを正しくする必
要があります。
u.ul[1] = 0xFFFFFFFF;
u.ul[0] = 0x7FFFFFFF;
可能な限り，データ要素はその自然な型で初期化します。言語標準には，サポートされている最大のデータ型を初期化できる定数
イニシャライザのサポートが含まれています。limits.hおよびfloat.hのヘッダファイルには，ISO C標準で定義されているとおり，数値
データ型の最小値および最大値のためのマクロに加え，サイズの情報も含まれています。
9.8 バイト配列として使用される16進定数
32ビットの値を，32ビットの値（整数）
としてだけでなく，4文字の配列としても扱った場合には，エンディアンの問題が発生します。
たとえば，次に示す配列は，リトル・エンディアンのマシンでは0x44332211という数値に相当しますが，ビッグ・エンディアンのマ
シンでは0x11223344という数値に相当します。
char a[4] = {0x11, 0x22, 0x33, 0x44};
定数を使用してマスクされた値も，特定のバイト・オーダを前提にしている場合は，影響があります。
51
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 52
9.9 その他の留意事項
リトル・エンディアンのコードではよく使用される手法でも，クロス・プラットフォームの作業では禁じられているものがあります。
たとえば，intへのポインタをcharへのポインタにキャストし，ポインタが指しているアドレスに最下位を意味するバイト があると
みなす手法がこれにあたります。以下に例を示します。
unsigned int value = 0x03020100
unsigned int *ptr = &value;
unsigned char charVal;
charVal = *(unsigned char*)ptr;
リトル・エンディアンのシステムでは，charValには値0が割り当てられます。ビッグ・エンディアンのシステムでは値3が割り当てら
れます。このようなコードをプログラムで使用することは望ましくありませんが，実際には普通に使用されています。リトル・エン
ディアンのプラットフォーム用に書かれた古いコードでは，見つけ出して，根絶するのがもっとも難しい問題のひとつです。
移植性のある方法で同じ成果を得るには，以下のように一時的数値変数を使用します。
unsigned int temp = *ptr;
charVal = (unsigned char)temp;
2行目は，どんなアーキテクチャにおいても，最下位を意味するバイトから値を取得します。最下位を意味するバイトが一時的数値
変数の最上位アドレスにあっても，最下位アドレスにあっても変わりません。細部については，コンパイラが引き受けてくれます。
なお，エンディアン変換は，処理の途中ではなく，入力時と出力時に行う必要があります。これは分かりきったことなのですが，見
落とされがちです。
52
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 53
10 32ビットから64ビットへのポーティング
Solarisのアーキテクチャは，32ビットと64ビットのアプリケーションの両方をサポートしています。しかし，これまでの経緯から，
既存コードの多くは32ビットのまま残されています。SolarisとLinuxは共にLP64モデルをサポートしており，SolarisからLinuxへの
64ビット・コードのポーティングは，32ビットから64ビットへの移行に伴う問題に影響を受けないはずです。LP64のメモリモデル
の詳細については，www.opengroup.org/public/tech/aspen/lp64_wp.htmを参照ください。
過去10年にわたり，64ビット・コンピューティングは，高性能な技術計算を必要とするコミュニティで重用されてきました。しかし，最
近，インテル® Itanium® 2 プロセッサやインテル® EM64Tチップが出現してきたことで，64ビット・コンピューティングは，サーバおよびデ
スクトップの両市場で急速に主流となりつつあります。
32ビットから64ビットへのポーティングは，元の32ビット・プログラムに対して，移植性の問題に対するソリューションを適用しさえすれ
ば，それほど複雑な問題とはなりません。既存の32ビットコードのいくつかは，64ビット環境においてもそのまま正しく動作するかも
しれません。しかし，関数プロトタイプや移植性の高いプログラミング技術が用いられていない既存アプリケーションのいくつかでは，
ポーティングに要する時間が大幅に増える可能性があります。本章では，32ビットから64ビットへのポーティングに伴う一般的な問題
と，その問題を回避する方法を提案します。
10.1 なぜ64ビットなのか？
64ビット・アプリケーションは4エクサバイトの仮想メモリに直接アドレスすることが可能であり，インテル® Itanium® 2 プロセッサは
連続リニア・アドレス空間を提供します。もうひとつの利点は，ファイル・サイズをより大きくできることです。Linuxの64ビット・シ
ステムは，デフォルトで最大4エクサバイト
（263）のファイル・サイズを許可しています。これは，巨大なデータベースにアクセスす
るサーバにとって重要な利点となります。32ビット・システムでは，通常，カーネルとファイルシステムの両方にデフォルトで2ギガ
バイトの制限があります。
64ビットの演算自体は，C言語のlong longデータ型を使用している32ビット・システムでも利用可能ですが，64ビット・コンピュー
ティングの著しい高速性はハードウェアのサポートによるものです。通常，科学計算は浮動小数点演算に依存しています。一方，金
融計算が必要とするのは浮動小数点演算よりも狭い範囲で高精度な演算です。64ビットの演算は，適切な範囲でより高い精度の固
定小数点演算を提供します。現在のC言語の標準では，long longのデータ型は最低でも64ビットです（実装ではさらに大きなサイ
ズを定義できます）
。
もうひとつの重要な改良は，日付です。従来のLinuxの日付は，1970年1月1日からの秒数に相当する符号付きの32ビット整数とし
て表現されています。この日付は2038年で無効な日付となります。64ビットのシステムでは，日付は符号付きの64ビット整数とし
て定義されています。はるか将来にわたる日付を必要とする多くの機器を使用している金融業界にとって，64ビットへの変更はき
わめて重要です。
インテル® EM64Tハードウェア上で稼働する64ビットのLinuxディストリビューションは，IA-32の実行可能ファイルの実行をサポー
トしています。これらの実行可能ファイルは，通常の32ビット制限の下で32ビット・アプリケーションとして稼働し続けます。また，
これによって，アプリケーション開発者には，32ビットのIA-32ライブラリ一式を64ビット・システム上で検証，管理する必要性が生
じます。
10.2 Linux 64ビット環境
“long, pointer 64”（LP64）
は基本的に，ポインタおよびlong整数が64ビットを使用すること，intのデータ型は32ビットであることを規
定しています。“integer, long, pointer 32”（ILP32）
は，32ビットLinuxおよびWindowsのための規定です。表10-1では，LP64とILP32の
データ型を比較しています。“long-long, pointer 64”（LLP64）
は，Microsoft Windows製品の64ビット実装で使用するために採用され
たもう1つの64ビット・モデルです。
表10-1 データ型と規定
データ型
ビットに基づく規定
LP64
ILP32
char
8
8
LLP64
8
short
16
16
16
int
32
32
32
long
64
32
32
long long
64
64
64
pointer
64
32
64
浮動小数点の型であるfloatとdoubleは，32ビットおよび64ビットの両システム上でそれぞれ，32，64ビットであり，標準の一部では
ありません。一部のシステムでは，独自のチップベースの浮動小数点形式が使用されています。
整数の定数は，
（符号付き，または符号なしの）intまたはlongのいずれかです。デフォルトでは，コンパイラはサイズを決定するため
にこの定数の値を使うようになっています。サフィックスLは定数がlong整数であることを意味します。また，サフィックスUは定数
53
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 54
が符号なしであることを意味します。
ほとんどのシステムにおいて，コンパイラは自然な境界にデータ型を合わせます。64ビットのシステムにおいては，32ビットのデー
タ型を32ビットの境界に，64ビットのデータ型を64ビットの境界に合わせるということです。構造体において，これは，境界合わせ
を実行するために，コンパイラが充填文字（またはパディング）
を挿入する可能性があることを意味します。構造体自体も，最大幅
のメンバを基にして境界合わせされます。これは，64ビット・システムにおいて，structまたはunion自体を64ビットの境界に合わせる
ことを意味します。例10-1と表10-2は，コンパイラが境界合わせをどのように適用するのかを示しています。
例10-1 典型的なCの構造体
struct align {
int a;
double b;
int c;
long d;
};
32ビット・システムにおいては，コンパイラは変数bを境界合わせしないかもしれません。これは，たとえその変数が64ビット・オブ
ジェクトであっても，ハードウェアが2つの32ビット・オブジェクトとして取り扱うためです。64ビット・システムにおいては，bおよび
dは共に境界合わせされ，2つの4バイト充填文字（またはパディング）が付加されます。
表10-2 自然な境界合わせ
構造体の宣言
32ビット・システム
サイズ
64ビット・システム
オフセット
struct align {
サイズ
オフセット
0x00
32ビット
int a;
0x00
0x00
32ビット
0x00
32ビット充填文字
double b;
64ビット
0x04
64ビット
0x08
int c;
32ビット
0x0C
32ビット
0x10
long d;
32ビット
0x10
32ビット充填文字
64ビット
構造体サイズ 20バイト
};
0x18
構造体サイズ 32バイト
Single UNIX Specificationバージョン 2がサポートする64ビット・プログラミングに関する詳細は，
www.unix.org/version2/whatsnew/login_64bit.htmlを参照ください。
10.3 ポーティングの問題
C言語は，1970年代初期，システム実装言語として設計されました。その遺産として，ターゲットとなるプロセッサに対する最も効
率的なサイズを考慮し，intなどの基本的なデータ型が定義されました。また，異なる型の演算変数がどのように動作するのかに
関して，型変換の規則一式も作成されました。整数型は，char型からlong型まで多岐にわたります。また，これらの型には，それぞ
れsignedとunsignedが含まれます。C言語標準は各型の最小サイズと型間の関係を定義しています。しかし，各型の実際のサイズ
は実装によって定義されます。理論上は，intは64ビット，longは128ビットにすることができます。
FORTRANなど，他のいくつかの言語は，32ビットから64ビットへの移行に際し，意識しておくべき問題は少ないですが，移植性の
点で問題の発生する可能性があります。
以降のセクションでは，問題が多く発生しやすい箇所を指摘します。
10.3.1 標準の型定義
型定義のいくつかは開発者の特別な関心を引くでしょう。それらの使用法によってはコードの移植性を強化できるからです。表
10-3は，一般的な定義済みの型定義を一覧表にしたものです。
表10-3 一般的な型定義
型
説明
ptrdiff_t
2つのポインタを減算した結果の符号付きの整数型です。
size_t
符号なしの整数で，sizeof（3）演算子の結果です。パラメタをmalloc（3）などの関数に渡すとき，あるい
は，fread（2）などのいくつかの関数から戻ってきた時に使用されます。
int32_t, uint32_t, int64_t, ...
定義済みの幅の整数型を定義する型定義です。1999 C標準で定義されており，Linuxでも利用可能です。
intptr_t, uintptr_t
voidを指すあらゆる有効なポインタを変換できる整数型を定義します。
54
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 55
10.3.2 ポインタと整数
セクション10.2で述べているとおり，Linuxは，ポインタとlong整数が64ビットで，intが32ビットであるLP64モデルをサポートしてい
ます。よくあるプログラミングの誤りとして，ポインタが時折intに代入されたり，その逆が行われたり，というものがあります。ポ
インタが32ビットのintに代入されると，上位の32のビットは切り捨てられます。反対に，32ビットの符号付きのintがポインタに代入
される際には，代入される前に64ビットのlongに符号拡張されます。たとえば，以下のCプログラムを実行してみましょう。
int foo;
void *bar, *pfoo = &foo;
foo = pfoo; /* truncate 64-bit pointer to 32-bit int */
bar = foo;
結果的に，変数pfooおよびbarは以下の値を含みます。
pfoo: 0x60000fffffffb340
bar: 0xffffffffffffb340
10.3.3 式
CおよびC++言語の式は，演算子の結合性と優先順位，および一連の算術昇格の規則に基づいています。一般に，2つの符号付き
の整数の単純な加算結果は，signed intの式になります。intがlongに足される場合，式自体はlongの式になります。オペランドの1
つがunsigned intで，もう1つが符号付のintの場合，式はunsigned intになります。64ビット環境において，符号なしの32ビットの式
は，unsigned longに昇格することがあります。これは32ビットの式をパラメタとして渡した，64ビットの値に代入した，あるいは
式の評価の間に昇格した結果です。なお，この場合，符号ビットは伝播されません。
表10-4は，CおよびC++で指定されている単純な式とその式の型を一覧表にしたものです。
表10-4 式の型
データ
int i;
式
式の型
コメント
i+u
unsigned
符号ビットは伝播されません。
i + ul;
unsigned long
iはsigned longに昇格して，ulに足されます。符号ビッ
i + d;
double
unsigned u;
int i;
トは加算の前に伝播されます。
unsigned long ul;
Int i;
iは加算の前にdoubleに変換されます。
double d;
0xFFFFFFFF
unsigned int
この定数は64ビット・オブジェクトに代入される際にも，
符号拡張されません。
10.3.4 ビット・シフト
2つの式が関係しているため，ビット・シフトはかなりの混乱を招きます。1つはシフトされるビット，もう1つはシフトするビット
数を表すシフト・オペランドです。式の型を定義するのは2番目のオペランドではなく最初のオペランドです。表10-5は，式の型
とビットを31ビット左にシフトした結果を一覧表にしたものです。2番目のオペランドの型は式の型には影響を及ぼしません。
表10-5 シフトの式
式
long val = 1 << 31
型
結果
int
-2147483648 or 0xffffffff80000000
long val = 1 << 31UL
int
-2147483648 or 0xffffffff80000000
long val = 1L << 31
long
2147483648 or 0x80000000
long val = 1U << 31
unsigned long
2147483648 or 0x80000000
この違いが発生する原因は，1番目と2番目のケースでは，式の右側がintであるためです。intは符号拡張されてからvalに代入され
ます。3番目のケースでは，右側はlongなので，ビットは31ビット左にシフトされます。しかし，64ビットの式なので，代入の際に符
号拡張は発生しません。4番目のケースでは，式は符号なしの32ビットなので，符号拡張は発生しません。
10.3.5 関数パラメタ
CおよびC++では，パラメタは値で関数に渡されることが一般的です。また，C++には参照機能 による呼び出しがあります。
すべてのケースで，まず最初にパラメタが十分に評価され，単一の変数なのか，定数なのか，式なのかが評価されます。パラ
メタの評価の順序については特に指示がなく，システムによって異なるだけでなく，同一のシステムで異なる場合もあります。
C言語の標準は関数のプロトタイプを定義しています。関数に渡されるパラメタは以下のように記述します。
double AMathFunction(double, int);
この場合，すべてのパラメタが完全に定義されます。
C言語では，可変の数のパラメタを使える場合があります。次のケースでは，関数は未確定数のパラメタを受け取ることができ
ます。
int printf(const char *, ...);
省略記号（…）は，関数の呼び出し側が1つ以上のパラメタを提供する場合があることをコンパイラに伝えます。また，追加のパラ
55
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 56
メタに対しては，型のチェックを行いません。
3番目のケースは，関数のプロトタイプがまったく含まれていないか，あるいは関数の宣言は含まれている，レガシーなCアプリ
ケーションに対する互換性として提供されています。この関数の宣言にはパラメタのリストは含まれていません。また，すでに説
明した可変のパラメタのリストと同様，型のチェックは行われません。こうした一連のレガシーな互換性は，C言語の考案者であ
るBrian KernighanとDennis Ritchieに因んで，しばしば“K&R”と呼ばれます。
データ型が定義されていない場合，パラメタは標準で定義されている昇格規則に基づいて昇格します。データ型が関数プロトタ
イプによって定義されている場合，パラメタは標準の規則に基づいてその型に変換されます。パラメタの型が指定されていない
場合，パラメタはより大きな型に昇格します。64ビット・システムにおいては，整数型は64ビットの整数型に変換されます。また，
単精度の浮動小数点型は倍精度に昇格します。戻り値が指定されていない場合，関数のデフォルトの戻り値はintです。
C++言語が完全にプロトタイプ化された関数を必要とするのに対して，C言語の場合，必須ではありません。しかし，Cのプログラ
ムでも，常に関数プロトタイプを使用すべきです。強力なデータ型機能をサポートし，プロトタイプの備えるエラー低減という特
性を活用することができるからです。また，関数プロトタイプの使用により，データの昇格と降格で使用される追加コードを減ら
せるため，パフォーマンスも向上します。さらに，プログラム内に存在するかもしれない潜在的なバグを明らかにすることができ
るので，アプリケーションを64ビットにポーティングにする際に大いに役立ちます。
パラメタは式として動作し，昇格する前に評価されます。例10-2は，このケースを示したものです。
例10-2 パラメタの式
long testparm(long j) {
return j;
}
int main() {
int i = -2;
unsigned k = 1U;
long n = testparm(i + k);
⋮
}
64ビット・システムでは，結果が4294967295となります。これは，式i + kが符号なしの32ビットの式であり，longに昇格する際に
も符号が拡張されないためです。
多くのシステムでは，パラメタを渡すためにスタックではなくレジスタが使用されています。これはほとんどのプログラムにおい
ては透過的ですが，ある一般的なプログラミング手法によって，誤った結果が導き出される場合があります。floatの16進の値を印
刷するための以下のコードを考えてみましょう。
float f = 1.25;
printf(“The hex value of %f is %x\n”, f, f);
スタック・ベースのシステムでは，適切な16進の値が印刷されます。一方，レジスタ・ベースのシステムでは，16進の値が，浮動小
数点レジスタからではなく，整数レジスターから読み込まれます。お勧めしたい解決法は，以下のようにポインタを使用すること
です。
printf(“The hex value of %f is %x\n”, f, *(int *)&f);
この場合，浮動小数点の変数fのアドレスがintを指すポインタにキャストされ，その後，逆参照されます。
通常，倍精度は64ビット長であり，32ビットおよび64ビットの両システム上でIEEE-754の浮動小数点の標準に準拠しています。
10.3.6 数値定数
一般に，整数定数は，符号付きの32ビット整数として扱われます（例：1234）
。サフィックスLは long定数を示します（例：1234L）
。
サフィックスUは符号なしの定数を示し，単独で，あるいはLと共に使用できます。16進定数はマスク，または特定のビット値とし
て使用されることが一般的です。サフィックスのない16進定数は32ビットに収まり，かつ高位のビットがオンになっている場合，符
号なしのintとして定義されます。表10-6は，数値定数の特性を一覧表にしたものです。
表10-6 数値定数
定数
定数型
0xFFFFFFFF
32ビットの unsigned int
0xFFFFFFFFL
これは符号付きのlongです。64ビット・システムでは，下位の32ビットのみが設定され，値は0x00000000FFFFFFFF
となります。
0x7FFFFFFF
32ビットの符号付きの int
すべてのビットをオンにしたい場合は，値が-1の符号付きのlong定数を定義することにより，移植性を高めることができます。この
方法では2の補数演算を使うため，すべてのビットがオンになります。
56
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 57
long x = -1L;
もうひとつの一般的な方法は，最上位ビットの設定です。32ビット・システムでは，定数0x80000000を使用することが一般的です。
より移植性の高い方法は，limits.hヘッダファイルにある定義された定数LONG_MINを使ったシフト式を使うことです。以下の例を
考えてみましょう。
1L << ((sizeof(long)*8) - 1);
これは定数式であり，コンパイラはこの式を適切な定数に畳み込むため，16ビット，32ビット，64ビットのすべてのシステムで機能
します。
10.4 ポーティングツール
32ビット・アプリケーションの64ビット環境へのポーティングを支援するツールがいくつか用意されています。しかし，これらの
ツールの一部は，32ビットから64ビットへのコードのポーティングに特化して設計されたツールではないため，いくつかの問題点
を見落とす可能性があります。
環境の変則性の多くは実行時まで明らかになることはないため，確固とした検査戦略が必要です。
10.4.1 Intel® C++ Compiler
Intel® C++ Compilerは，64ビットのポーティングに特化した診断をレポートするモードを備えています。コンパイラフラグ-Wp64を使
用すれば，有用な警告を得ることができます。Intel® C++ Compilerは，www.intel.com/software/products/compilers/linux/で
入手可能です。
例10-3のコードには，32ビットから64ビットへのコードのポーティングに伴う典型的な問題が含まれています。
例10-3 32ビットから64ビットへのコードのポーティングに伴う典型的な問題
long anumber = 5;
int number;
number = anumber;
Intel® C++ Compilerは，ポーティングに伴うこの問題を特定するのに役立つ，以下のような警告を出します。
warning #810: conversion from "long" to "int" may lose significant bits.
10.4.2 GNU Compiler Collection（GCC）
GNU Compiler Collection（GCC）には，C，C++，およびその他の言語のためのコンパイラが含まれています。通常，GCCはディスト
リビューション・ベンダによって提供されます。追加資料およびGCCの代替バージョンは，gcc.gnu.orgで入手可能です。
10.4.2.1 GCC
GCCは，GNU C Compilerの略称です。アプリケーションを整理するために利用できますが，32ビットから64ビットへのポーティング
に特化した診断機能は一切備えていません。
しかし，-Wall，-ansi，あるいは-pedanticフラグを使用すれば，いくつかの疑わしい問題点を検出できます。例10-4のコードには，
32ビットから64ビットへのコードのポーティングに伴う別の典型的な問題が含まれています。
例10-4 32ビットから64ビットへのコードのポーティングに伴う別の典型的な問題
llong anumber;
char *number_string = “123”;
sscanf(number_string, "%d", &anumber);
GCCで-Wallを使用すると，以下の警告が発せられます。
warning: int format, different type arg (arg 3)
この例では，引き数3（anumber）が，%d 変換仕様に対して適切なサイズではありません。
10.4.2.2 G++
G++は，GNU C++コンパイラです。G++には，GCCとほぼ同じフラグが用意されていますが，-Wabiなど，有用な追加のフラグも
含まれています。abi 警告は，コンパイラが特定のベンダに依存するコードを生成する可能性があることを示します。
10.4.2.3 GDB
GDBとは，GNU Debuggerのことで，Linuxシステムのための標準デバッガです。GDBデバッガは，ほとんどのLinuxディストリビュー
ションに収録されています。また，www.gnu.org/software/gdb/gdb.htmlで無料で入手可能です。
10.4.2.4 Data Display Debugger（DDD）
DDDと は ，Data Display Debuggerの こ と で ，ほ と ん ど の Linuxデ ィ ス ト リ ビ ュ ー シ ョ ン に 収 録 さ れ て い ま す 。
www.gnu.org/software/ddd/で無料で入手可能です。DDDは，GDB上に階層化され，ソース・ウインドウを提供します。さら
に，見つけにくい異常を突きとめる際に，開発者を支援してくれるダイナミック・データ・ディスプレイを提供します。
57
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 58
10.4.2.5 Splint
Splintは，Cプログラムを静的にチェックするツールで，32ビットから64ビットへのポーティングのための診断機能を備えています。
Splintは，多くのUNIXシステムで見られる由緒あるlintコマンドの無料のバージョンです。-strictフラグはかなり冗長ですが，ポー
ティングには役立ちます。Splintは，ほとんどのLinuxディストリビューションに収録されています。www.splint.orgに追加情報
があります。
58
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 59
11 ファイル・システムおよびクラスタについての検討事項
SolarisからLinuxへアプリケーションをポーティングしているISVは，数々のファイル・システムおよびクラスタ・オプションを利用する
ことができます。本章では，Linuxに対して提供されているファイル・システムおよびボリューム・マネージャについて説明します。ま
た，Linuxで利用できるクラスタ・オプションの概要についても説明します。クラスタ・ソリューションには2つの種類があります。ハイ
アベイラビリティ
（高可用性）クラスタとハイパフォーマンス・コンピューティング（高性能コンピューティング）クラスタです。本章で
は，高可用性クラスタに重点を置き，Sun Cluster，HP ServiceguardおよびVERITASの高度な機能について比較し，説明します。なお，本
章では触れていませんが，この他にもOpenSSIプロジェクトやLustreといった注目すべきクラスタ・オプションがあります。
11.1 ファイル・システム・サポート
Linuxは30種類以上ものファイル・システムをサポートしているため，SolarisからLinuxへポーティングされるアプリケーションにと
って，必要とする容量や機能を見つけるのは難しいことではないでしょう。サポートされるLinuxファイル・システムとしては，Ext2，
Ext3，ReiserFS，JFS，VxFS，FAT32，NTFS，NFSv2，NFSv3，UFS，HSFS※1，UDF※2などが挙げられます。Red Hatのデフォルトの
ファイル・システムはExt3であり，SUSEはReiserFSを使用しています。ReiserFSおよびExt3ファイル・システムは，どちらも2.6以降
のカーネルで，ジャーナリングと数TBのストレージをサポートしています。
Solarisがサポートするファイル・システムはLinuxよりも少なく，種類の異なるストレージメディアをサポートすることに主眼が置か
れています。Solarisでは，CD-ROMのためのHSFS，DVDのためのUDF，ハードディスク装置のためのデフォルトのファイル・システ
ムであるUFSなどがサポートされています。SolarisのUFSはデフォルトでロギング可能に設定されており，ジャーナリング・ファイ
ル・システムとなっています。UFSファイル・システムはLinuxでもサポートされています。Solaris 8およびLinuxの2.4（およびそれ
以前の）カーネルのUFSについては，ファイル・システム・ストレージに1TBの制限があります。しかし，Solaris 9，Linux 2.6カーネ
ルでは，数TBのUFSのサポートが実現されました。両システムとも，ラージファイルをサポートしています（Solarisでは64ビット・
カーネルが必須）
。また，SolarisとLinuxはどちらも，NFSリソースをマウントするためにAutoFSを，/tmpのためにローカルメモリ・
ベースのTMPFSを，サポートしています。一般に，Linuxでは，TMPFSは/tmpディレクトリのデフォルトではありません。このファイ
ル・システム形式はLinuxカーネルでうまくサポートされ，glibc 2.2以降でPOSIX共有メモリを実装するために使用されます。
一般的に使用されているLinuxのファイル・システムのより詳細な情報を知りたい方は，以下のリンクを利用ください。
• Ext2/Ext3: e2fsprogs.sourceforge.net/ext2.html
• ReiserFS: www.namesys.com/
• JFS: jfs.sourceforge.net/
※1 High Sierra - ISO9660（CDFS）に対するUNIXに似たファイル・システム拡張，CD-ROM向け
※2 Universal Disk Format - DVD向け
11.2 ロジカル・ボリューム・マネージャ（LVM）
ロジカル・ボリューム・マネージャ（LVM）は，1台または複数台の物理ディスクからなる仮想ディスクや，仮想ボリュームの作成を
可能にするストレージ管理ツールです。ロジカル・ボリューム・マネージャは，ファイル・システムの下層として稼働し，論理ディス
ク・ボリュームに対する要求を物理デバイス・コマンドに変換します。ロジカル・ボリューム・マネージャにより，複数台の小容量デ
ィスクを1つの大容量仮想ディスクにしたり（ディスク・スパニング）
，1台の大容量ディスクを複数の小容量ディスク領域に分割し
て（ディスク・パーティショニング）利用することができます。このため，大きなファイルが複数台のディスクにわたって保存される
場合もあります。
ロジカル・ボリューム・マネージャがなければ，ファイル・システムや個々のファイルは，物理ディスクのサイズを越えることがで
きないという制限を受け続けることになります。これは，データ集約型のアプリケーションにおいて問題となります。複数台のデ
ィスクを組み合わせて論理ボリュームを作成することで，容量，信頼性，パフォーマンスの向上を図ることが可能となります。初
期のファイル・システムや物理的なパーティションのアプローチと異なり，論理ボリュームは，管理者が再起動することなく，オン
ラインで操作することを可能にしてくれます。ロジカル・ボリューム・マネージャは，物理ボリュームではなく，論理ボリュームとし
て，ディスクを監視します。
多くのオープンソース・プロジェクトが，ボリューム管理機能をLinuxプラットホームのために提供しています。
• Software RAID ドライバ（MDドライバの別名でも知られる）
。
詳細については，mdadm（1）および cgi.cse.unsw.edu.au/~neilb/mdadmを参照ください。
• Linuxで最も普及しているボリューム管理パッケージは，LVM2および旧版のLVMを含むLogical Volume Managerです。LVM2お
よびLVMの詳細については，sourceware.org/lvm2およびsourceware.org/lvmを参照ください。
• Linuxで普及している別のボリューム管理パッケージとしては，Enterprise Volume Manager（EVMS）も挙げられます。EVMSの詳細
については，evms.sourceforge.netを参照ください。
RAIDの背後にあるコンセプトは単純です。それは，2台，あるいはそれ以上のデバイスを組み合わせて単一のRAIDデバイスにする
59
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 60
というものです。RAIDデバイスを作成するには2つのアプローチがあります。1つは，特殊なRAIDハードウェアを使用する方法で
あり，もう1つは，RAID機能をソフトウェアで実装する方法です。
ハードウェアRAIDのサブシステムは，ハードウェア・レベルで冗長性とストライピングを実現します。HPのハードウェアRAIDソ
リューションには，Smart Array，Modular Smart Array（MSA）
，Enterprise Virtual Array（EVA）およびXPストレージ・ソリューション
が含まれています。
Linuxでは，ハードウェアRAIDに加えて，ソフトウェアRAIDもサポートされています。これはソフトウェアを用いて，RAIDデバイス
の作成を可能にするもので，ハードウェアRAIDのコントローラやエンクロージャは必要ありません。たとえば，ソフトウェアRAID
を利用して，hda3，hdb3および hdc3という3つの空パーティションを結合して，単一のRAIDデバイス /dev/md0を作成することがで
きます。作成したRAIDデバイスは他のLinuxデバイスとまったく同じように使用することが可能であり，ファイル・システムが利用
できるようにフォーマットすることも可能です。RAIDを使用すれば，ディスクの入出力パフォーマンスと信頼性を劇的に向上させ
ることができます。
どちらか，あるいは両方のソリューションを利用してパーティションまたはデバイスを結合することにより，耐障害性とパフォーマ
ンスの面で，1台のデバイスをはるかに越えたメリットを享受できます。
同様に，LVM2およびLVMは，冗長性なしで，2台以上のディスクを結合してひとつの仮想ディスクにすることを可能にします。さら
に，ボリュームのスナップショットの作成，ボリュームのサイズ変更，ファイル・システムをアンマウントすることなく他のボリュー
ムにデータを再配置する機能など，さまざまな追加機能を備えています。ソフトウェアの冗長性が必要な場合は，ソフトウェアRAID
上でLVMを使用することにより，RAID冗長性を持つボリュームを作成できます。
オープンソースの世界にEVMSが登場したのは最近のことです。EVMSは，Software RAIDやLVMといった他の管理テクノロジー
の管理を可能にするプラグイン・アーキテクチャの採用により，他のLinuxボリューム管理システムよりも柔軟な方法でストレー
ジを管理します。EVMSは，異なるボリューム形式やファイル・システムを認識し，読み込むことが可能なため，Linuxシステムへ
のディスクの移行や新たなディスクの追加といった，より実務的な作業がさらに処理しやすくなります。
EVMSは，安全でないコマンドの実行を許可しないという手段によって，安全管理を提供します。こうした管理は，システムに保存
されるデータの完全性を維持するのに役立ちます。EVMSを使用すれば，ボリュームのサイズ変更，ボリューム・スナップショット
の作成，システムのRAID機能のセットアップなどが行えます。さらに，クラスタ内のノードにより物理的に共有されているスト
レージ上のデータを管理することが可能になるという，きわめて有用な機能も備えています。この共有ストレージにより，クラス
タ内の異なるノードからのデータの可用性が高まります。
これらのオープンソースのソフトウェア以外にも，VERITASはLinux版のStorage Foundationというスイート製品をリリースしまし
た。VERITAS Storage FoundationはVERITAS Volume Manage（VxVM）
，VERITAS File System（VxFS）の組み合わせにより，オンライ
ン・ストレージ管理のための完全なソリューションを提供します。スナップショットの作成やボリュームのサイズ変更といった，数
多くのボリューム管理機能に加え，VERITAS Storage Foundationでは，異なるオペレーティング・システムやストレージ・アレイ間で，
データを柔軟に移動させたり，I/Oを複数のパスに均等化しパフォーマンスを向上させたりすることが可能です。また，データをリ
モートサイトへ複製することで可用性の向上を図ると共に，ユーザやアプリケーションによるファイルへのアクセス方法を変更す
ることなく，重要度の低いファイルや使用されなくなったファイルを安価なストレージへ移動できるようになります。
Sun Solaris Volume Manager CIM/WBEM APIのユーザは，基本的なLinuxディストリビューションで，WBEM/CIMへのサポートレベル
が低いと考えるかもしれません。HPでは，www.hp.com/go/wbemにおいて，Linux向けのWBEMソリューションを提供してい
ます。WBEM providers for Linuxには，ディスク・ドライブ，ディスク・パーティション，論理ディスク，ネットワーク・アダプタ，PCIデ
バイス，物理メディア，物理メモリ，電源，SCSIコントローラなどが含まれています。また，環境管理に必要なユーザ・インタフェー
スおよび機能を備えた，WBEM用の管理アプリケーションであるWBEM clientsも提供しています。他にも，Linux向けのWBEMサービ
スを提供するための作業を行っているプロジェクトとして，SBLIM（sblim.sourceforge.net/index.html）があります。
11.3 Sun Clusters - 背景概要
Sun Cluster 3.1は，Sunの提供するクラスタ・ソフトウェアの現行バージョンです。このソフトウェアは，Sunがサポートするx86お
よびSPARCベースのハードウェア・システムに高い可用性を提供します。Sun Cluster 3.1は，Solaris 8およびSolaris 9オペレーティ
ング・システム上で稼働します。このクラスタ・ソリューションは，Sun Clusterソフトウェア，Solarisオペレーティング・システム
（OS）
，サポートされたSunサーバ，パブリック・ネットワーク，クラスタ・インターコネクト，Sunまたはサードパーティのストレー
ジ・ソリューションで構成されます。Sunのクラスタ構成では，最大16ノードがサポートされています。サポートされているハード
ウェアおよびソフトウェア・コンポーネントについては，www.sun.com/software/cluster/ds/ds-cluster31/において一覧表
が入手可能です。
11.3.1 クラスタ構成オプション
このクラスタ・ソリューションは，シングルインスタンス・アプリケーション・フェールオーバ，または分散アプリケーション管理環
境を提供します。
60
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 61
• シングルインスタンス・アプリケーション・フェールオーバ
アプリケーションは1次ノードでシングルインスタンスとして稼働し，障害が発生した場合は2次ノードに引き継がれるように設
定可能です。このソリューションは，アプリケーションに高い可用性をもたらします。
• 分散アプリケーション管理環境
このオプションは，クラスタ環境においてマルチプルインスタンス・アプリケーションの構成を可能にします。ユーザ・アプリケー
ション・サービスをクラスタ内の複数のノードに分散させることで，アプリケーションの可用性とスケーラビリティを高めることが
できます。これらのアプリケーションへの負荷を均等化するために，グローバルIPアドレス・サービスを利用できます。
クラスタ・ツールおよびクラスタAPIは，クラスタ環境におけるアプリケーション構成，アプリケーション依存の作成，アプリケー
ションのオンライン／オフラインの切り替え，アプリケーションの状態の監視，クラスタ・リソースの管理などを支援します。
Sunでは，可用性が高く，スケーラブルなアプリケーションを作成するために，予め設定された “公認エージェント”の一覧表を
提供しています。新しいアプリケーションのためにカスタム・エージェントを作成する手法も紹介しています。Sunのクラスタ・オ
プションおよびアーキテクチャに関する詳細については，docs.sun.com/app/docs/doc/817-6536を参照ください。
11.3.2 管理性
Sun Clusterでは，管理の一元化を可能にする中央集権的なクラスタ管理が提供されています。クラスタ管理ツールには，GUIベー
スのSunPlex Manageと，Sun Cluster CLIと呼ばれるコマンドライン・インタフェースが含まれています。これらのツールは，クラス
タ構成を設定，管理，監視するためのものです。リソース・グループ，共有デバイス，ボリューム管理，ユーザ・アプリケーションな
ど，すべてがこれらのクラスタ管理ツールで管理できます。アプリケーション，ファイル・システム，ディスク・パス，ネットワーク
のための障害モニタも用意されており，リソースの状態を監視し，障害を検出することができます。
11.3.3 クラスタ・コミュニケーション
クラスタ・インタコネクトは，ノード間のクラスタ・コミュニケーションを可能にします。クラスタ内のすべてのノードは，最低2つの
インタコネクトを通じて，物理的に接続されています。Sunのクラスタ・インタコネクトには，標準のFast EthernetおよびGigabit
Ethernetを利用できます。高速な通信を必要とする特殊な構成については，Remote Shared Memory（RSM）テクノロジーが提供され
ています。RSM APIは，アプリケーションがTCP/IPスタックをバイパスすることを可能にし，ノード間の通信において，高速なアク
セスと，ハードウェア間のインターコネクトの低レイテンシ化を実現します。RSMには，Sunが独自に開発した Scalable Coherent
Interconnect（ SCI-PCI）が必要です。クラスタ・インタコネクトに関する詳細は，docs.sun.com/app/docs/doc/817-
6536/6mltstlhi?a=viewを参照ください。
11.3.4 リソース構成
Sun Clusterは抽象的なリソースを提供します。リソースとはグローバル・ネットワーク，デバイス，ファイル・サービス一式であ
り，これらのリソースに直接または間接的に接続されたすべてのノードで利用できます。Sunはローカル・デバイスおよびグロー
バル・デバイスの両方を提供しています。名前からも分かるように，ローカル・デバイスは，クラスタ内の各ノードのプライベート
なデバイスです。対照的に，グローバル・デバイスはクラスタ全体のすべてのクラスタ・ノードが利用できます。クラスタ・ソフト
ウェアは，デバイスIDドライバ（DID）を利用して，グローバル・デバイスを管理します。DIDは，クラスタ内の各デバイスが特定で
きるように，デバイスに固有のIDを割り当てるために使用されます。グローバル・デバイスには，ディスク，テープ，CD-ROMなど
が含まれます。現在，クラスタ環境において可用性が高いのは，マルチパス，マルチホストをサポートできるディスク・デバイスの
みです。テープおよびCD-ROMはクラスタにおいて全ノードからアクセスできますが，可用性は高くありません。
11.3.5 クラスタ・ファイル・システム
アプリケーションは，Sun Cluster環境のクラスタ・ファイル・システムにアクセスできます。クラスタ・ファイル・システムは，クラ
スタ内の各種ノードが利用可能な基幹のグローバル・デバイスを使用します。マルチホストおよびマルチパス機能を備えたディス
ク・デバイスを使用すれば，アプリケーションに対して可用性の高いクラスタ・ファイル・システムを作成できます。クラスタ・ファ
イル・システムは，fcntl（2）インタフェースを使用して，可用性の高いファイル・ロッキング機能を提供しています。この機能によ
り，異なるノードで稼働しているアプリケーションのデータ・アクセスの同期がとれます。しかし，Sunクラスタ・ファイル・システ
ムは，基幹となるオペレーティング・システムのファイル・システムからは独立しています。オペレーティング・システムのファイ
ル・システムは，クラスタ・ファイル・システムの一部ではありません。むしろ，クラスタ内の各ノード専用のものです。ユーザ・ア
カウントおよびプロフィールは，デフォルトでは，各種クラスタ・メンバー間で共有されません。しかし，共有されるように手動で
設定することでが可能です。
11.3.6 アプリケーション・プログラミング・インタフェース（API）
Sun Clusterは，クラスタ環境において，可用性が高く，スケーラブルなデータ・サービスまたは“エージェント”を作成，管理する
方法を提供しています。利用できるプログラミング・オプションは，以下のとおりです。
• 低級クラスタAPI
低級APIは，Resource Management API（RMAPI）と呼ばれています。このAPIの提供する関数一式により，さまざまなクラス
タ・リソースに関する情報を収集し，設定を行い，状態を変更することが可能となります。これらの関数はCの機能として，また，
コマンドラインのオペレーションとして利用できます。RMAPIルーチンはlibscha.oライブラリに含まれています。
61
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 62
• 高級クラスタ機能ライブラリ
プログラミング・インタフェースの次のレベルは，Data Service Development Library API（DSDL API）です。DSDL APIはRMAPI上
に構築され，データ・サービス作成するための機能を提供します。DSDL APIは，アプリケーション・データ・サービスのための
ビルディング・ブロックともいえるルーチンであり，libdsdev.oライブラリに含まれています。DSDL APIを使用すれば，カスタマイ
ズされたアプリケーション・データ・サービスを作成することができます。
• クラスタ環境のアプリケーションのために，さまざまなデータ・サービスを自動的に作成するツール
Sun Clusterの提供するもう1つのツールが SunPlex Agent Builderです。このツールは，前述のAPIを利用して，データ・サービスお
よびアプリケーション・パッケージを作成するプロセスを自動化します。SunPlex Agent Builderは，簡単なアプリケーションの
作成には役立ちます。しかし，複雑な必要条件や依存性の伴うアプリケーションを作成する場合は，DSDL APIを使用して手動
でコードを書くのが一般的です。Sun Cluster APIに関する追加情報については，
docs.sun.com/app/docs/doc/816-3385を参照ください。
11.4 HP Serviceguard Clusters - 比較
HP Serviceguardクラスタ製品は，Linuxで利用できるクラスタ・ソリューションを探し求めているISVに対して，包括的な選択肢を
提供します。HP Serviceguard for Linuxは，広範囲にわたるHPサーバとストレージ上で可用性および耐障害性の高いソリューション
を提供します。以降のセクションの説明は，HP Serviceguardの提供する高い可用性に重点を置いています。
HP Serviceguard A.11.16 for Linuxの最新バージョンは，Novell SUSE Enterprise Server 9とRed Hat Enterprise Linux 3の両方をサポー
トしています。HP Serviceguardがサポートしているサーバとしては，32ビットおよび64ビット拡張されたHP ProLiantサーバ，64ビットの
HP Integrityサーバなどが挙げられます。製品の機能に関する詳細な説明は，www.hp.com/go/serviceguardを参照ください。
11.4.1 クラスタ構成オプション
HP Serviceguardでは，シングルインスタンス・フェールオーバを使用する環境用，または，マルチプルインスタンスを使用する
環境用に，アプリケーションを設定することが可能です。シングルインスタンス・フェールオーバは，ハードウェア障害が発生し
た場合でも，アプリケーションに高い可用性を提供します。シングルインスタンスに設定されたアプリケーションは，1次ノード
で障害が発生した場合，生き残っているノードに処理を引き継ぎます。マルチプルインスタンスの設定にすると，複数のノード
でアプリケーションが同時に稼働し，アプリケーションのために分散環境が提供されます。マルチプルインスタンスの設定は，ア
プリケーションに高い可用性とスケーラビリティの両方を提供します。
HP Serviceguardは，クラスタ設定ツールおよび管理ツールを提供します。これらのツールを使用することにより，アプリケーショ
ン
“パッケージ”
を作成し，アプリケーションのオンライン／オフラインの切り替えのプロセスを自動化したり，アプリケーション・
パッケージのリソースの依存性を定義したりすることができます。機能面において，HP Serviceguardのパッケージは，Sun Cluster
のエージェントとよく似ています。
クラスタ管理ツールは，クラスタを全体的に，またアプリケーション・パッケージを含む各種コンポーネントを個別に監視します。
また，HP Serviceguard Manager，Network Manager，Package Manager，Storage Volume Managerなど，クラスタ・ソリューション
の各種コンポーネントを設定，管理するためのツールも数多くそろっています。Serviceguardも，使用頻度の高いアプリケーショ
ンのために，予め設定されたツールキットを提供しています。
11.4.2 管理性
Serviceguard Managerは，高可用性クラスタ・ソリューションの設定，管理，監視を簡素化するクラスタ管理ツールであり，複数
のクラスタを1ヶ所で管理することを可能にしてくれます。Serviceguard Managerはクラスタを全体的に管理するGUIツールで
すが，個別のノードやアプリケーション・パッケージのレベルまで掘り下げることもできます。パッケージ，ノード，クラスタを
起動，終了，変更することも可能です。さらに，Serviceguard Managerと，HP OpenViewアプリケーション・ポートフォリオやHP
Systems Insight Managerといった，他のHPの管理ソリューションとの統合することで，より包括的で，システムワイドな管理ソ
リューションを実現できます。HP OpenViewの詳細については，openview.hp.com/solutions/を参照ください。
HP Event Monitoring Services（EMS）を利用すれば，ディスクやネットワーク・インタフェースなどのシステム・リソースに対する
可用性の高い監視手段が提供されます。EMSは，ハードウェアおよびソフトウェア・ベンダに対して，既存のEMSフレームワーク
と統合できる監視手段を作成するために無料のAPI一式を提供します。クラスタの管理性に関するより詳細な情報は，
h71028.www7.hp.com/enterprise/cache/4175-0-0-0-121.htmlを参照ください。
11.4.3 クラスタ・コミュニケーション
HP Serviceguardは，各種のクラスタ・ノード間で，ハートビート・メッセージを通じた連続的なコミュニケーションを必要としま
す。ハートビート・メッセージは，ハートビート・デバイスとして設定されたあらゆるTCP/IPネットワーク上で伝達することができ
ます。ネットワークの混雑を避けるために，プライベート・ネットワークをハートビート・ネットワークとして設定することをお勧め
し ま す。ク ラ ス タ の ノ ード 間 の 通 信 に は 標 準 Ethernet，Fast Ethernet，Gigabit Ethernetを 使 用 す ること が で き ま す。HP
Serviceguardクラスタ・インターコネクトにおける業界標準，高帯域幅のInfiniBandのサポートは、将来の製品リリースで計画され
ています。
62
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 63
11.4.4 リソース構成
HP Serviceguardパッケージは，可用性の高い環境において動作するように構成されたアプリケーションです。パッケージは，アプ
リケーション・サービス，および，ディスク，ディスク・ボリューム，IPアドレスなどのシステム・リソースによって構成されていま
す。HP Serviceguardにはグローバル・デバイスはありませんが，共有ストレージ・デバイスがアプリケーション・パッケージによっ
てリソースとして使用されます。共有デバイスにはサーバへの直接のパスが必要で，これによって，パッケージがあるノードから
別のノードへと引き継がれるようになります。
ネットワーク・リソースを必要とするパッケージは，再配置可能なIPアドレスで設定することができます。これらのIPアドレスは，仮
想IPアドレスと同様，パッケージがフェールオーバした場合，2次ノードのネットワーク・インタフェースに再配置されます。チャンネ
ル・ボンディングも可能で，これによりLANインタフェースのグループ化が可能です。ボンディングされたグループ内のあるインタ
フェースが作動し，データを転送している間，別のネットワーク・インタフェースはバックアップとして働きます。
11.4.5 クラスタファイル・システム
現在，HP Serviceguardは，クラスタ・ファイル・システムを提供していません。クラスタ内の各ノードは，それぞれのオペレーティ
ング・システムおよびアプリケーションのために，自身のプライベートなファイル・システムを備えています。共有ストレージ上で
利用可能なロー・デバイスは，Oracle RACのようなアプリケーションで使用できますが，こうしたアプリケーションでは，クラス
タ内の多様なノード間でデータを共有することが必要です。将来，HP ServiceguardはRed Hat Global File System（GFS）をサポ
ートする予定です。Sun Clusterと同様，HP Serviceguardでは，ユーザ・アカウントおよびプロフィールをクラスタ全体で共有す
ることは許可されていません。しかし，同一の設定により，アカウント管理のプロセスを容易にすることが可能です。
11.4.6 アプリケーション・プログラミング・インタフェース
HP Serviceguardは，Apache，MySQL，Oracle，SAP，Samba，NFSをはじめ，数多くのアプリケーションのためにツールキット
を用意しています。これらのツールキットには，Serviceguard環境において，アプリケーションの可用性を高めるために予め設定
された命令が含まれています。ツールキットは，rpmパッケージからインストールされ，クラスタ環境内でアプリケーションを起
動，停止，監視するbashシェルスクリプト一式で構成されています。既存のテンプレートを利用してカスタム・パッケージを作成
することも可能です。リソース，フェールオーバ・ポリシー，スクリプトなどに対してさまざまなオプションを指定して，カスタマ
イ ズ さ れ た ア プリケ ー ション・パッケ ー ジ を 作 成 す ること が で き ま す。Linuxで 利 用 可 能 な ツ ー ル キット に つ い て は ，
www.hp.com/go/serviceguardに一覧表が用意されています。High availabilityセクションの下にあるLinuxのリンクをたどっ
てください。
11.5 VERITAS Clusters - 比較
VERITASは，Linuxソリューションのために高い可用性を実現する，大規模な製品群を提供しています。VERITASは，Sun Cluster製品
から移行するISVに対して，彼らの要求に対応する包括的なソリューションを提供しています。高可用性を実現するVERITAS製品
は，Solaris，HP-UXおよびLinuxをはじめとする数多くのプラットホームで利用可能です。VERITASは，複数のプラットホームに対
して，共通のテクノロジー，アーキテクチャ，管理手段によるソフトウェア・ソリューションを提供し，異なる環境でも実行可能な
ものとします。VERITAS Cluster Server製品は，Red Hat Linux 3.0とSUSE Linux 8の両方をサポートしています。製品の互換性に関
する詳細については，www.veritas.com/Products/www/html/High_Availability/vcs_compmatrix.htmlに一覧表が用
意されています。
11.5.1 クラスタ構成オプション
VERITASは可用性の高いソリューションを数多く提供しています。しかし，クラスタ製品の核となるのはVERITAS Cluster Server
（VCS）です。Sun Clusterの構成と同様，VCS環境下のアプリケーションは，シングルインスタンス，またはマルチプルインスタン
ス用の構成にすることができます。シングルインスタンス・アプリケーションのフェールオーバは，VCSのFailover Service Group
下で定義されます。また，マルチプルインスタンス・アプリケーションはParallel Service Groupを形成します。Hybrid Service
Groupと呼ばれるもうひとつのオプションを使用すれば，VERITASで定義したシステム・ゾーン間で，シングルインスタンスとマル
チプルインスタンスを組み合わせることが可能となります。
VERITAS Cluster Serverは，高い可用性とスケーラビリティを提供できるようにアプリケーションを設定，管理するためのフレー
ムワークを構築します。VCS環境は，リソース，リソースの依存性，サービス・グループ，エージェントを定義します。エージェ
ント・プロセスは，VERITASクラスタ環境内のすべてのアプリケーションとクラスタ・リソースを管理します。エージェントは，
オンライン／オフラインの切り替え，監視，情報収集，その他のカスタマイズされた動作など，アプリケーションに対する操作
を行います。VERITASは，さまざまなアプリケーションやデータベースを監視するために予め設定されたエージェントを数多く
提供します。また，VCSフレームワークも，クラスタ制御やメンバー間のコミュニケーション，多様なコンポーネントの同期，グ
ループ・メンバーシップ，リソースを監視するためのさまざまなバックグラウンド・プロセスなどを管理するツールを提供しま
す。VERITASの提供する他の可用性の高い製品として，負荷の均等化を図るCluster Server Traffic Director，分散クラスタを管理
す る Global Cluster Manager， デ ー タ 複 製 を 行 う Volume Replicatorな ど が 挙 げ ら れ ま す 。 詳 細 に つ い て は ，
www.veritas.com/Products/www?c=product&refId=20をご覧ください。
63
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 64
11.5.2 管理性
VERITAS Cluster Serverは，コマンドライン・インタフェース（CLI）またはグラフィカル・ユーザ・インタフェース（GUI）を使用し
て，管理できます。JavaおよびWebベースのGUI Cluster Managerが用意されています。Cluster Managerツールは，VERITAS
Cluster Serverの起動や停止，監視，管理特権の設定，クラスタ内の複数ノードの管理などに使用します。リソースやサービス・グ
ループ，エージェントを照会，変更，作成，削除するためのCLIユーティリティも多数用意されています。GUIベースのCluster Managerは
クラスタ全体の監視，照会，さまざまなクラスタ・サービスの変更などにも便利です。VERITASには，管理製品がもう2つあります。
Global Cluster ManagerとCommandCentral Availabilityです。これらの製品は，より包括的で，長距離にわたるマルチクラスタの管理
機能を提供します。
11.5.3 クラスタ・コミュニケーション
VERITAS Cluster Serverの構成では，クラスタ・コミュニケーションのための特殊なハードウェア・インタコネクトを必要としませ
んが，プライベート・ネットワーク・パスを使用します。通信にはLow Latency Transport（LLT）プロトコルが使用されています。
LLTは，IPスタックに代わる低レイテンシ，高性能のプロトコルであり，クラスタのハートビート・トラフィック，ノード間通信，そし
て多様なプライベート・ネットワークのネットワーク・トラフィックの分配にも利用されています。VERITASは，ボトルネックを低
減し，クラスタ・コミュニケーションに冗長性を持たせるために，すべてのクラスタ・ノード間に最低2つのプライベート・ネット
ワーク・パスを設けることを勧めています。
11.5.4 リソース構成
VERITAS Cluster Server（VCS）のリソースには，ネットワーク・インタフェース，IPアドレス，ディスク・デバイス，ファイル・シス
テム，アプリケーションが含まれます。これらのリソースはVCSによって設定，管理され、他のリソースに関して定義された依存性
を持つことができます。VCSはサービス・グループを作成し，共通の論理グループ・ユニットの下にリソース一式を集めます。アプ
リケーション・サービス・グループは，アプリケーションの要求する可用性の高さに応じて，フェールオーバ・グループとして，ある
いは，パラレル・グループとして稼働するように定義することができます。ディスク・デバイスは，サーバへのダイレクト・パスを持
つ必要があります。これは，サービス・グループをあるノードから別のノードに引き継ぐことを可能にするためです。ネットワー
ク・アクセスを必要とするサービスは，仮想IPアドレスを定義します。これは，サービスが引き継がれる際に，その仮想IPアドレス
が2次ノードに移動するようにするためです。
エージェントは多様な種類のリソースを監視，管理するプロセスであり，リソース管理に関してVCSとコミュニケーションを取り合
って い ます。VERITASは，膨 大 な 数 の 予 め 設 定 さ れ た エ ー ジェント を 多 様 な アプリケ ーション（ Apache，BEA WLS，IBM
WebSphere，Oracle Apps，SAP，Siebel）やデータベース（Oracle，DB2，Informix，MySQL，Sybase）のために用意しています。
VERITAS VCSのエージェントについては，www.veritas.com/Products/www?c=optionlisting&refId=20の一覧表を参照
ください。
11.5.5 クラスタ・ファイル・システム
VERITASが提供しているクラスタ・ファイル・システム製品は，クラスタ内の複数ノードが共通のファイル・システムにアクセスで
きるようにするStorage Foundation Cluster File System（SFCFS）です。一般に，この製品はVERITAS CFSとして知られています。
さまざまなノード・メンバーに対してダイレクト・パスを持つストレージ・デバイスは，クラスタ・ファイル・システムとして構成す
ることが可能です。VERITAS CFSは，主にデータおよび構成を共有しているアプリケーションのために利用されます。複数プロ
セスによる同時データ・アクセスを実現するには，アプリケーション・レベルのロッキング機能を実装する必要があります。オペレ
ーティング・システムのファイル・システムは，ノード・メンバーに対してはプライベートのままなので，共有できません。VERITAS
CFSは，ストレージのパフォーマンスと可用性を向上させるために，DMP（Dynamic Multi-Pathing）を利用してI/O要求を拡散しま
す。また，I/Oフェンシング機構により，データの破損を防ぎます。VERITAS Storage Foundation Cluster File Systemの詳細については
www.veritas.com/Products/www?c=product&refId=209を参照ください。
11.5.6アプリケーション・プログラミング・インタフェース
VERITASはクラスタ・サーバの管理やリソースの管理，さまざまなサービス・グループの管理などを行うためのコマンドライン・イ
ンタフェース（CLI）を数多く用意しています。適切なユーザ特権があれば，シェル・スクリプト内でこれらのCLIを使用して，VERITAS
のクラスタ・コンポーネントの設定や監視作業を自動化することができます。VERITASも，ユーザ定義のエージェントを作成する
ために，多数のAPIを提供しています。ユーザ定義のエージェントには，C++，Perlまたはシェル・スクリプトが使えます。さまざま
なAPIの詳しい解説と，カスタマイズされたエージェントを作成するためのAPIの使用法を収録したVERITAS Cluster Server Agent
Developer’s Guideが， www.veritas.com/van/documentation/clusterserver.htmlで入手できます。
11.6 追加情報
下記の商用およびオープンソース製品がLinuxに提供されています。
• Linux Clustering Information Center – www.lcic.org
• HP StorageWorks Scalable File System（HP SFS）– www.hp.com/go/technicalstorage
• Red Hat Global File System（formerly Sistina）– www.redhat.com/software/rha/gfs/
64
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 65
• OpenSSI – www.openssi.org
• Lustre – www.lustre.org
• OpenGFS – opengfs.sourceforge.net
• Oracle Cluster File System（OCFS）– oss.oracle.com/projects/ocfs
• HP Serviceguard for Linux – www.hp.com/go/serviceguard
• Steeleye Lifekeeper – www.steeleye.com
• Polyserve Matrix HA – www.polyserve.com
• The Beowulf Project – www.beowulf.org
• Sandia Computational Plant（cplant）– www.cs.sandia.gov/cplant
• PNNL，HP Integrity Linuxのクラスタ・ソリューションを利用して，11.8テラフロップのクラスタを作成
– www.hp.com/techservers/clusters
• HP High Availability technology – www.hp.com/go/ha
65
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 66
12 追加リソース
HPサイト内のLinuxソリューションに関する追加情報
• Linux @ HP: www.hp.com/go/linux
• Eclipse: www.hp.com/go/eclipse
Linuxへの移行のためのツールおよび追加情報
• HP Developer’s Resource: devresource.hp.com/linux
• HP DSPP Program: www.hp.com/dspp
• HP IT Resource Center: www.itrc.hp.com
• HP Caliper performance analyzer: www.hp.com/go/caliper
• The Red Hat Solaris to Linux porting guide: www.redhat.com/docs/wp/solaris_port/book1.html
• Linux Device Driver development: www.oreilly.com/catalog/linuxdrive2
• Linux Standard Base: www.linuxbase.org
• The Linux Documentation Project: www.tldp.org
• UNIX Rosetta Stone（UNIX/Linuxコマンド・マップ）: bhami.com/rosetta.html
• HP DSPP Linux resources: www.hp.com/go/linuxdev
• HP TOC calculator and other links: www.hp.com/go/linux-hp
• HP & Open Source: opensource.hp.com
• HP Linux Technologies Project: hpl.hp.com/research/linux
66
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 67
A Cコンパイラ・オプションの比較
以下の表は，Sun ONE Studio 8 C（Version 5.5）
コンパイラ・オプションに対応するGNU Compiler Collection（GCC）Cコンパイラ・オ
プションを示したものです
（該当するものがある場合）
。これらのコンパイラの詳細については，以下のWebサイトをご覧ください。
• GCC – gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/index.html
• Sun ONE Studio 8 C – docs.sun.com/app/docs/coll/771.4
Sun Cオプション
説明
GCCオプション
すべてのコンポーネントの呼び出しを表示する。GCCの場合，リンカの呼び出しを見
-#
-v
-###
-###
-#と同様だが，各段階は実際には実行されない。
-Aname[(token)]
-A name=token
プリプロセッサ命令#assertを実行するのと同様，nameを述語として，指定されたtoken
-Bdynamic
デフォルトの動作
リンク時に結合するライブラリを動的にすることを指定する
（共有）
。
-Bstatic
-static
リンク時に結合するライブラリを静的にすることを指定する
（非共有）
。
-C
-C
プリプロセッサがコメントを削除しないようにする。
-c
-c
コンパイラにコンパイルを実行させるが，リンクは行わない。
-Dname[=val]
-Dname[=val]
プリプロセッサ・マクロを定義する。
-d[y|n]
-static
動的，または静的なリンクを指定する。GCCのデフォルトの動作は-dynamic。
-dalign
-malign-double
最大8バイトの境界合わせを想定する。
-E
-E
ソースファイルに対しプリプロセッサのみを実行する。
-errfmt[=[no%]error]
対応なし
メッセージの先頭にプレフィックス文字列errorを追加する。
-erroff[=t]
-w
タグ番号に基づいて，特定の警告の出力を無効にする。GCCには直接的に対応するも
るには，-Wl,-vを追加する。
に対応付ける。
のはないが，-wですべての警告を完全に抑制できる。抑制できる警告の種類について
は，マンページgcc（1）を参照のこと。
-errshort
対応なし
エラーメッセージの詳細度を制御する。
[=short|full|tags]
-errtags[=yes|no]
対応なし
エラーメッセージのタグを表示する。
-errwarn
-Werror
すべての警告をエラーとして扱う。
-fast
対応なし
実行速度を最大にするオプションを有効にする。GCCには直接的に対応するものは
ない。部分的な対応については，-ffast-math, -fstrict-aliasing, および-marchを参照の
こと。
-fd
-Wstrict-prototypes
K&R形式の関数の宣言や定義に関する警告を行う。
-flags
--helpおよび-v
使用できるコンパイラオプションの要約を出力する。GCCでは，使用できるコンパ
-fnonstd
対応なし
イラの概要が表示される。
-fnsおよび-ftrap=commonのマクロ。 浮動小数点演算ハードウェアの非標準の初期化を
行う。また，浮動小数点のオーバーフロー，ゼロによる除算，不正演算例外に対する
ハードウェアによるトラップが可能になる。
-fns
対応なし
非標準の浮動小数点モードを有効にする。
-fround=mode
対応なし
丸めモードを選択する。デフォルトのIEEEモードはround-to-nearest。Linuxにおいても
同様であるが，別のモードを選択するオプションはない。適切な丸めモードを選択す
るには，ISO C99インタフェースのfesetroundを使用する。
-fsimple=[n]
-ffast-mathを参照のこと
オプティマイザが浮動小数点演算に関する前提事項を単純化できるようにする。
-fsingle
対応なし
コンパイラに，float式を倍精度ではなく単精度で評価させる。
-ftrap=mode
対応なし
指定した浮動小数点条件のトラップを有効にする。Linuxでは，移植性の高いISO C99
インタフェースを使用する。
-G
-shared
リンカに，実行可能ファイルではなく，共有オブジェクトを作成させる。
-g
-g
デバッグ情報を作成する。
-H
-H
コンパイルする各ヘッダファイルのパス名を出力する。
-h name
-Wl,--soname, name
共有オブジェクトにnameを割り当てる。
-I[dir]
-I[dir]
インクルード検索ディレクトリを追加する。
-I-
-I-
-I-オプションの前に-Iオプションで指定したすべてのディレクトリが検索される。検索
-i
対応なし
リンカに，LD_LIBRARY_PATHの設定を無視するオプションを渡す。
-keeptmp
-save-temps
一時ファイルを保持する。
-KPIC
-fPIC
位置独立コードを作成する。
-Kpic
対応なし
共有ライブラリで使用する位置独立コードを作成する。
-Ldir
-Ldir
ライブラリ検索ディレクトリにdirを追加する。
-lname
-lname
ライブラリlibname.a（または .so）
にリンクする。
-mc
対応なし
.commentセクションから重複している文字列を削除する。
-misalign
対応なし
最大1バイトの境界合わせを想定する。
-misalign2
対応なし
最大2バイトの境界合わせを想定する。
されるのは#include "file"のみで，#include <file>は検索されない。
67
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 68
Sun Cオプション
説明
GCCオプション
対応なし
.commentセクションからすべての文字列を削除する。オプションでstringを挿入する。
-mt
-pthread
プリプロセッサに-D_REENTRANTを渡し，リンク行にスレッドライブラリを追加する。
-native
-b machineおよび
現在のシステム・アーキテクチャのためのコードを生成するように，コンパイラに命令
-march=cputype
する。GCCには直接的に対応するものはないが，表示されるスイッチによって，特定
-mr[,string]
-O
を参照のこと
のシステム・アーキテクチャが指定可能になる。
-O
デフォルトの最適化レベルをオンにする
（Solarisでは -xO2，GCCでは -O1）
-o file
-o file
出力ファイルを指定する。
-P
対応なし
コンパイラに，対応するCファイルのみの前処理を実行させる。GCCには直接的に対
-p
-p
prof（1）でプロファイリングを実行するためのデータを収集するオブジェクトコードを
-Q[y|n]
対応なし
出力ファイルに識別情報を入れる
-qp
-p
prof（1）でプロファイリングを実行するためのデータを収集するオブジェクトコードを
-Rdirlist
-Wl,-rpath dirlist
-S
-S
コンパイラに，アセンブリ・ソースファイルを作成するよう命令する。
-s
-s
出力ファイルからシンボリック・デバッグの情報をすべて削除する。
-Uname
-Uname
プリプロセッサ・シンボルnameを未定義にする。
-V
-v
コンパイラの実行時に，各ツールのバージョンに関する情報を出力する。
-v
-Wall
コンパイラに，意味検査を実行させ，lintに似た検査を可能にする。GCCでは-Wall
-Wc,arg
-Wc,arg
コンパイラに，引数としてargを，cによって名前を付けられたツールに渡すよう伝える。
-w
-w
警告を抑制する。
-X[a|c|s|t]
コンパイラの章のモード・ ISO Cに対するさまざまな準拠の度合いを選択する。
応するものはない。代わりに，-Eを使用する。
準備する。
準備する。
実行時にライブラリ検索ディレクトリを指定するために使用するディレクトリのリスト
を渡す。
オプションおよび ﾐWall に含まれていない -Wオプションを使用して実行できる
オプションの表を参照
のこと
-x386
-mcpu=i386または
i386プロセッサ用に最適化する。
-march=i386
-x486
-mcpu=i486または
-x386と同様に，i486プロセッサ用に最適化する。
-march=i486
tcovを使用した基本的なブロック・カバレージ分析を行うコードを挿入する。GCCで
-xa
-fprofile-arcs
-xalias_level[=l]
-fstrict_aliasing
-xarch=name
-march=name
使用する特定の命令セットを選択する。
-xautopar
対応なし
自動並列化を有効にする。
-xbuiltin
デフォルトの動作
標準ライブラリ関数を呼び出すコードをさらに最適化する。
は，GNU gcov（1）検査ツールを使用して，出力を処理する。
型に基づいた別名解析による最適化を実行するために，どのような仮定ができるのか
を指定する。
-fno-builtinを参照のこと
-xCC
デフォルト
-xc99[=o]
-std={c99|c89}
C99標準の機能に対する認識を制御する
-xcache[=c]
対応なし
オプティマイザのキャッシュ特性を定義する。
-xcg[89|92]
対応なし
SPARC固有の最適化マクロ
-xchar[=o]
-f[no]unsigned_char
タイプcharをsignedにするかunsignedにするのかを指定する。
-xchar_byte_order[=o]
対応なし
複数文字の定数である文字を，指定されたバイト順で配置することにより，整数定数
-xcheck[=o]
-fstack-check
-xchip[=name]
-march=cputype
ターゲットとなるプロセッサを指定する。
-xcode[=v]
対応なし
コード・アドレス空間を指定する。
-xcrossfile
対応なし
ソースファイル間の最適化とインライン化を有効にする。
-xcsi
対応なし
ISO Cソース文字コードの必要条件に準拠していないソースコード・モジュールを受
-xdebugformat
対応なし
-xdepend
部分的に対応
内部反復データの依存性に関してループを分析する。GCCには直接的に対応するも
-floop-optimizeを参照
のはないが，-floop-optimizeを使用してループの最適化を行える。
C++形式のコメントを受け入れる。
を生成する。
スタック・オーバーフローの実行時チェックを有効にする。
け入れる。
stabs または dwarf 標準形式を使用してデバッグ情報を作成する。
のこと
-xe
-fsyntax-only
構文チェックのみを行う。
-xexplicitpar
対応なし
#pragma MP指示文の指定に基づいて並列化コードを生成する。
-xF
対応なし
リンカによる関数と変数の最適な並べ替えを有効にする。
-xhelp=flags
--help -v
コンパイラ・オプションの概要を表示する。
-xhwcprof
対応なし
コンパイラによる，ハードウェア・カウンタ・ベースのプロファイリングのサポートを有
-xild[on|off]
対応なし
効にする。
インクリメンタルリンカを有効/無効にする。
68
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 69
Sun Cオプション
説明
GCCオプション
-fno_inline
あらゆる関数に対して，インライン化を試みない。
-xinline=%auto
-finline_functions
あらゆる関数に対して，インライン化を試みる。
-xinline=fct, ...
対応なし
リストで指定した関数のみをインライン化する。
-xipo[=a]
対応なし
内部手続き解析コンポーネントを呼び出して，プログラム全体の最適化を実行する。
-xjobs=n
対応なし
コンパイラが処理を行うために作成するプロセスの数を設定する。
-xldscope={v}
対応なし
externシンボルの定義に対するデフォルトのリンカスコープを変更する。
-xlibmieee
対応なし
例外の場合，数学ルーチンがIEEE 745形式の値を返すようにする。
-xlibmil
対応なし
いくつかのライブラリルーチンを，高速に実行できるようにインライン化する。
-xinline
-xlic_lib=sunperf
対応なし
Sunの提供するパフォーマンス・ライブラリにリンクする。
-xlicinfo
--version
使用されているライセンス・ファイルに関する情報を返す。
-xloopinfo
対応なし
どのループが並列化されているのかを示す。
-xM
-M
makefileの依存関係を生成する。
-xM1
-MM
-Mとほぼ同じ。ただし，/usr/includeのファイルを除く。GCCはシステム・ヘッダ・ディ
-xMerge
対応なし
データ・セグメントをテキスト・セグメントとマージする。
-xmaxopt[=v]
対応なし
pragma optのレベルを指定したレベルに制限する。
-xmemalign=ab
対応なし
レクトリのファイルを除外する。
想定される最大のメモリ境界合わせと，誤って境界合わせされたデータの動作を指定
する。
-xnativeconnect
対応なし
共有ライブラリがJavaで書かれたコードとインタフェースすることを可能にする。
-xnolib
-nostdlib
あらゆるライブラリに対して，自動的にリンクを行わない。
-xnolibmil
デフォルトの動作
数学関数のインライン化を抑制する。GCCのデフォルトであり，-fno-fast-mathで実行
-xO[n]
-O[n]
-xopenmp[=i]
対応なし
OpenMP指令による明示的な並列化を有効にする。
-xP
-aux-info filenameまたは
K&R関数定義のプロトタイプを出力する。GCCはすべての関数のプロトタイプを出力
protoize -n
する。どのプロトタイプをプログラムに追加すべきかを確認するには，protoizeツール
できる。
最適化のレベルを選択する。
で-nオプションを使用する。
-xpagesize
ターゲット固有
スタックおよび／またはヒープのためのメモリのページサイズを設定する。
[_heap|stack]=n
-xparallel
対応なし
ループを自動的に並列化する。自分で指定することも可能。
-xpch=v
対応なし
プリコンパイル済みヘッダ機能を有効にする。プリコンパイル済みヘッダのサポート
-xpchstop=file
対応なし
-xpchによって作成されたプリコンパイル済みのヘッダファイルに対する最後のインク
-xpg
-pg
gprof（1）
によるプロファイリングのためのデータを収集するためのコードを準備する。
-xprefetch
対応なし
先読みをサポートするアーキテクチャ上で先読み命令を有効にする。
-xprefetch_level=l
対応なし
先読み命令の自動挿入の強さを制御する。
-xprofile=collect
-fprofile-generate
はGCC 3.4以降で利用可能。
ルードファイルを指定する。
コンパイラに対して，プロファイリング情報を収集するためのコードを生成するように
命令する。
-xprofile=use
-fprofile-use
-xprofile=tcov
-fprofile-arcs
xprofile=collectでコンパイルしたプログラムの実行によって得られた情報を使用する。
プログラムに，tcovツールを使用して，調べることのできる情報を作成させる。GCC
では，gcovを使用する。
-xprofile_ircache
対応なし
コンパイル時間を改善するために，-xprofile=useと共に使用する。
-xprofile_pathmap
対応なし
コンパイラによるプロファイル・データ検索を支援するために，-xprofile=useと共に使
-xreduction
対応なし
-xregs=r[,r...]
-ffixed-<reg>または
生成されたコードのためのレジスタの使用を指定する。GCCでは，-ffixed-<reg>,
-fcall-used-<reg>または
-fcall-used-<reg>および-fcall-saved-<reg>オプションを使用して，特定のレジスタの
-fcall-saved-<reg>
使用を指定する。
用する。
-xrestrict[=f]
プロファイル自動並列化のために縮約の認識を有効にする。
-fargument-noaliasまたは ポインタ値型関数パラメタを制限付きポインタとして扱う。GCCの-fargument-noalias
-fargument-noalias-global オプションは-xrestrict=%allと同じ。-fargument-noalias-globalを使用して，コンパイラに，
パラメタがグローバルデータの別名になっていないことを伝える。ISO C99 keyword
restrictを使用して，他の値の別名になっていない関数パラメタに印を付ける。
-xs
対応なし
デバッグ情報をすべて実行可能ファイルにコピーする。
-xsafe=mem
対応なし
コンパイラが投機的ロードを生成することを可能にする。
-xsb
対応なし
ソースコード・ブラウザ用の追加シンボルテーブル情報を生成する。
-xsbfast
対応なし
-xsbに似ているが，オブジェクトファイルは作成しない。
部分的に対応
サフィックスのない浮動小数点定数を，デフォルトの倍精度ではなく，floatとして扱う。
-xsfpconst
-fshort-doubleを
GCCは，floatと同じサイズを倍精度に対して使用する-fshort-doubleオプションを提供
参照のこと
する。まったく同じではないが，コンパイル・ユニットでdouble値が使用されていない
場合は問題ない。
-xspace
69
-Os
コードサイズが大きくならない最適化のみを行う。
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 70
Sun Cオプション
説明
GCCオプション
-xstrconst
デフォルトの動作
-xtarget=name
ターゲット固有（-mオ
読み出し専用データセクションに，文字列リテラルを挿入する。GCCではデフォルト。
Sunコンパイラのデフォルト動作を得るには，-fwritable-stringsオプションを使用する。
命令セットと最適化のターゲットとなるプラットホームを指定する。
プションを参照のこと）
-xtemp=dir
-xthreadvar[=o]
環境変数TMPDIR
一時ファイルのためのディレクトリを指定する。GCCでは，環境変数TMPDIRを使って，
を使用する。
使用したいディレクトリの名前を設定する。
-ftls-model=model
スレッドローカル変数の実装を制御する。
-xtime
-ftime-report
コンパイルに使用された時間とリソースを報告する。
-xtransition
対応なし
K&RとSun ANSI/ISO Cとの相違に関する警告を発する。一般的に，GCCは，ISO Cの規
則に対する違反に対して警告を発する。警告されないようにするには ，-traditionalオプ
ションを使用して，明示的にK&Rの動作を許可する必要がある。
-xtrigraphs
-trigraphs
-xunroll=n
--param
コンパイラに，ISO C標準によって定義されているとおり3文字表記シーケンスを認
識できるようにするか否かを決定する。
コンパイラに対して，ループをn回展開するように指示する。
max-unroll-times=n
-xustr
対応なし
文字リテラルをUTF-16文字列に変換する。
-xvector
対応なし
ベクトルライブラリ関数に対する呼び出しの自動生成を有効にする。
-xvis
対応なし
VIS命令セット
（SPARC V9の命令セット拡張）
と共に使用する。
-xvpara
対応なし
ループの並列化が正しく指定されていない場合に，#pragma MP指令が指定されて
-Yc, dir
-Bdir
-YA, dir
-Bdir
コンパイラ・コンポーネント検索時のデフォルトディレクトリを変更する。
-YI, dir
対応なし
インクルードファイル検索時のデフォルトディレクトリを変更する。
-YP, dir
対応なし
ライブラリファイル検索時のデフォルトディレクトリを変更する。
-YS, dir
対応なし
起動用のオブジェクトファイルのデフォルトディレクトリを変更する。
-Zll
対応なし
Solaris lock_lint ツール用のデータベースを作成する。
いるループに関する警告を発する
コンパイラのコンポーネントcがディレクトリdirで見つかるように指定する。GCCで
は，-Bオプションによって，コンポーネントではなくディレクトリを指定する。
70
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 71
B C++コンパイラ・オプションの比較
以下の表は，Sun ONE Studio 8 C++（Version 5.5）
コンパイラ・オプションに対応するGNU Compiler Collection（GCC）version 3.3.3
G++コンパイラ・オプションを示したものです（該当するものがある場合）
。 これらのコンパイラの詳細については，以下のウェブサイトを
ご覧ください。
• GCC – gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/index.html
• Sun ONE Studio 8 C++ – docs.sun.com/app/docs/coll/771.4
Sun Cオプション
説明
GCCオプション
-mcpu=i386
ターゲットとなるプロセッサをi386に設定する。
-486
-mcpu=i486
ターゲットとなるプロセッサをi486に設定する。
-a
-p
プロファイリング用のコードを生成する。
-Bbinding
-statcまたは
ライブラリのリンク形式が，シンボリックなのか，動的（共有）なのか，静的（非共有）な
-sharedまたは
のかを指定する。
-386
-symbolic
プロファイリング用コンパイラに，リンクなしのコンパイルの実行を指示する。
-c
-c
-cg{89|92}
対応なし
リンクターゲットとなる環境を設定する。Solarisでは，-xcg{89|92}を使用する。
-compat[={4|5}]
-fabi-version
コンパイラのメジャーリリース互換モードを設定する。
+d
-fno-inline
コンパイラがC++インライン関数を拡張するのを抑制する。
-Dname[=def]
-Dname[=def]
マクロシンボル名nameを定義する。
-d[y|n]
-static
動的，または静的なリンクを指定する。G++では，-dynamicがデフォルト動作。
-dalign
-malign-double
最大8バイトの境界合わせを想定する。G++のデフォルトの境界合わせとSPARCの境
-dryrun
対応なし
-E
-E
+e{0|1}
対応なし
Solaris互換モード4での仮想テーブルの生成を制御する。
-erroff[=t[,t...]
-w
タグ番号に基づいて，特定の警告の出力を無効にする。G++には直接的に対応するも
界合わせは等しくない。
コンパイルドライバに，コンパイラのサブコマンドを表示するように指示する。ただ
し，コマンドの実行は行わない。
コンパイルドライバに，C++のソースファイルの前処理のみを指示し，その結果を標準
出力（stdout）
に送信するように指示する。
のはない。-wですべての警告を完全に抑制できる。抑制できる警告の種類について
は，
ドキュメンテーション g++（1）を参照のこと。
-errtags[=yes|no]
対応なし
エラーメッセージのタグを表示する。
-errwarn
-Werror
すべての警告をエラーとして扱う。
-fast
-O3
コードがコンパイルされるシステム上での最適な実行速度が得られるように，コンパ
イルオプションの組み合わせを選択する。
-features=a
対応なし
さまざまなC++言語機能を有効／無効にする。詳細については，GCCマニュアルの
“Options Controlling C++ Dialect”セクションを参照のこと。
-filt
対応なし
-flags
コンパイラによってリンカーエラーメッセージに対して通常適用されるフィルタリング
を抑止する。
[=filter[,filter...]]
--helpおよび
各コンパイラフラグの簡単な説明を表示する。
-v
-fnonstd
対応なし
浮動小数点のオーバーフロー，ゼロによる除算，不正演算例外に対するハードウェア
-fns[={no|yes}]
対応なし
-fprecision=a
-frounding-math
-fround=mode
対応なし
IEEEの丸めモードが起動時に有効になるように設定する。
-fsimple[=n]
対応なし
浮動小数点の最適化設定を選択する。gcc（1）マンページの-ffast-mathオプションを
-fstore
-ffloat-store
-ftrap=a[,a...]
対応なし
IEEEのトラップモードが起動時に有効になるように設定する。
-G
-shared
リンカに，実行可能ファイルではなく，動的共有ライブラリを構築するよう指示する。
-g
-g
によるトラップを有効にする。
SPARC非標準浮動小数点モードを選択する。g++（1）マンページの-funsafe-mathoptimizationsオプションを参照のこと。
浮動小数点の丸め精度モードを設定する。
参照のこと。
浮動小数点の式の精度を強制する。
詳細については，ld（1）マンページおよびC++ User’s Guideを参照のこと。
コンパイラとリンカの両方に，デバッグ用のファイルまたはプログラムを作成するよ
うに指示する。
-g0
-glevel
-H
-H
-h[ ]name
対応なし
-help
-help
-Ipathname
-Ipathname
コンパイラに，デバッグ用のファイルまたはプログラムを作成するように指示する。た
だし，インライン化を無効にしない 。
標準エラー（stderr）出力に，現在のコンパイルに含まれている各#includeファイルのパ
ス名を1行に1つずつ出力する。
生成された動的共有ライブラリにnameを割り当てる。
（標準出力に）
コマンドライン・オプションの説明を出力する。
#includeファイルのために検索されるディレクトリのリストに，
（スラッシュ以外の文字
で始まる）相対ファイル名でpathnameを追加する。
71
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 72
Sun Cオプション
説明
GCCオプション
-I-オプションの前に-Iオプションで指定したすべてのディレクトリが検索される。検索
-I-
-I-
-i
対応なし
リンカ ld（1）
に，すべてのLD_LIBRARY_PATH設定を無視するように伝える。
-inline
対応なし
-xinlineと同じ。
-instances=a
対応なし
テンプレートインスタンスの位置とリンクを制御する。
-instlib=file
対応なし
このオプションを使用すると，共有ライブラリまたは静的ライブラリと現在のオブジェ
-keeptmp
-save-temps
コンパイル時に生成される一時ファイルを保持する。
-KPIC
-fPIC
ターゲットとなるマシンでサポートされていれば，位置独立コードを作成する。
-Kpic
対応なし
コードアドレス空間を指定する。-xcode=pic13と同じ。
-Lpath
-Lpath
ライブラリ検索パスにパスを追加する。
-llib
-llib
ライブラリliblibを追加する。
-libmieee
対応なし
例外の場合，libmが数学ルーチンに対して，IEEE 745値を返すようにする。
-libmil
対応なし
選択されたライブラリルーチンを最適化のためにインライン化する。
-library=lib[,lib...]
対応なし
CCが提供するライブラリをコンパイルおよびリンクに組み込む。
-mc
対応なし
.commentセクションから重複している文字列を削除する。
-migration
対応なし
以前のバージョンのコンパイラでビルドされた，移行するソースコードに関する情報
-misalign
対応なし
通常はエラーになる，メモリー内の境界合わせの誤ったデータを容認する。
-mr[,string]
対応なし
.commentセクションからすべての文字列を削除する。
-mt
-pthread
されるのは#include "file"のみで，#include <file>は検索されない。
クトで重複するテンプレートインスタンスの生成が抑制される。
を提供する。
マルチスレッド化されたコードのコンパイルとリンクを実行する。プリプロセッサに
_D_REENTRANTを渡す。
-native
-mtune=cpu-type
Solarisでは，xtarget=nativeを使用する。ターゲットとなるプロセッサに最適化された
コードを生成する。
-noex
対応なし
-nofstore
対応なし
C++例外を無効にする。詳細については，GCCマニュアルの“Options Controlling
C++ Dialect”セクションを参照のこと。
強制された式の精度を無効にする。 G++のデフォルの動作。gcc（1）マンページの
i386, x86-64およびIA-64オプションを参照のこと。
リンク時に標準システムライブラリを使用しない。
-nolib
-nodefaultlibs
-nolibmil
対応なし
デフォルトのシステムライブラリとのリンクを無効にする。
-noqueue
対応なし
ライセンスの待ち行列を無効にする。
-norunpath
対応なし
実行可能ファイル内に共有ライブラリへのパスを作成しない。
-O
-O2
デフォルトの最適化レベル。GCCのデフォルトは -O0であることに注意。
-O[level]
-O[level]
最適化levelを指定する。
-o file
-o file
出力fileを指定する。
+p
対応なし
非標準のプリプロセッサ表明を無視する。
-P
対応なし
コンパイラに，対応するCファイルの前処理のみを実行させる。G++には直接的に対
-p
-p
prof（1）でプロファイリングを行うためのデータを収集するためのオブジェクトコード
-pentium
-mcpu=pentium
ターゲットとなるCPUを指定する。
-pg
-pg
ターゲット解析プログラム gprof（1）
に適したプロファイル情報を書き込むための追
-PIC
-fPIC
ターゲットとなるマシンでサポートされていれば，位置独立コードを作成する。
-pic
-fPIC
ターゲットとなるマシンでサポートされていれば，位置独立コードを作成する。
-pta
対応なし
Solarisでは，-template=wholeclassと同じ。
-ptipath
対応なし
テンプレートソースのための検索ディレクトリを追加指定する。
-pto
対応なし
Solarisでは，-instances=staticと同じ。
-ptrpath
対応なし
このオプションは廃止されたため，コンパイラに無視される。
-ptv
対応なし
Solarisでは，verbose=templateと同じ。
-Qoption phase option
対応なし
optionを指定されたコンパイルphaseに渡す。
-qoption phase option
対応なし
optionを指定されたコンパイルphaseに渡す。-Qoptionを使用する。
-qp
-p
プロファイリングコードを生成する。
-Qproduce sourcetype
-save-temps
コンパイルドライバに，sourcetypeで指定されたタイプの出力を生成させる。
-qproduce sourcetype
-save-temps
コンパイルドライバに，sourcetypeで指定されたタイプの出力を生成させる。-Qproduce
-Rpath[:path...]
-Wl,-rpath dirlist
-readme
--help
-xhelp=readmeと同じ。
-S
-S
コンパイルを実行し，アセンブリコードのみを生成する。
-s
-s
実行可能ファイルからシンボルテーブルを削除する。
-sb
対応なし
ソースコード・ブラウザ用の情報を作成する。Solarisでは，-xsbを使用する。
-sbfast
対応なし
コンパイルは行わず，ソースブラウザ用の情報のみを作成する。Solarisでは，xsbfast
応するものはない。代わりに-Eを使用する。
を準備する。
加コードを生成する。
を使用する。
実行可能ファイル内に，ダイナミックライブラリの検索パスを作成する。
を使用する。
72
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 73
Sun Cオプション
説明
GCCオプション
-staticlib=l[,l...]
対応なし
-library，xlangおよび-xiaオプション
（デフォルトを含む）で指定されているライブラリの
-temp=path
対応なし
一時ファイルのディレクトリを指定する。関連情報については，g++（1）manページの-
-template=a[,a...]
対応なし
さまざまなテンプレートオプションを有効／無効にする。
-time
-ftime-report
コンパイルドライバに，さまざまなコンパイル作業にかかった実行時間を報告させる。
-Uname
-Uname
プリプロセッサのシンボル名nameの初期定義を削除する。
-unroll=n
-floop-optimize2または
ループの展開を有効にする。
うち，どのC++ライブラリが静的にリンクされるかを指定する。
pipeオプションを参照のこと。
Solarisでは，-xtimeを使用する。
-funroll-loopsまたは
-funroll-all-loops
-V
--version
コンパイラのバージョンを表示する。
-v
-v
コンパイラの詳細メッセージを表示する。
-vdelx
対応なし
このフラグは，Solarisの互換モードのみに利用できる。
-verbose=a[,a...]
-v
コンパイラのメッセージの詳細度を制御する。
+w
-Wall
意図しない結果が生じる可能性のあるコードを特定する。追加警告オプションの詳細
については，G++（1）マンページを参照のこと。
+w2
-Wall
+wと同じ警告に加えて，危険性はないが，プログラムの移植性を損ねる可能性のある
技術的な違反に関する警告を発する。追加警告オプションの詳細については，g++（1）
マンページを参照のこと。
-w
-w
警告メッセージを抑制する。
-xa
-pまたは
プロファイリング用のコードを生成する。
-fprofile-arcs
-xalias_level[=n]
-fstrict-aliasing
-xar
対応なし
型に基づいた別名解析による最適化を実行するために，どのような仮定ができるのか
を指定する。
（テンプレート用の）アーカイブライブラリを作成する。
-xarch=isa
対応なし
-xbuiltin[={%all|%none}]
-fno-nonansi-builtins
-xcache=c
対応なし
-xcg89
対応なし
ターゲットとなる環境を設定する。
-xcg92
対応なし
ターゲットとなる環境を設定する。
-xchar=o
-funsigned-charまたは
このオプションは，charタイプが符号なしと定義されているシステムからのコード移
-fsigned-char
行を容易にするためだけに提供されている。
-xcheck[=n]
-fstack-check
スタック・オーバーフローの実行時チェックを有効にする。
-xchip=c
-march=cputype
オプティマイザの使用ターゲットとなるプロセッサを指定する。
-xcode=a
対応なし
コード・アドレス空間を指定する。
-xcrossfile[=n]
対応なし
ソースファイル間の最適化とインライン化を有効にする。
-xdumpmacros
対応なし
プログラム内でマクロがどのように動作しているのかを確認したい場合に使用するオ
-fsyntax-only
構文エラーと意味エラーのチェックのみを行う。
標準ライブラリ呼び出しの最適化を有効／無効にする。
（SPARCプラットホーム）オプティマイザの使用するキャッシュ属性を定義する。
プション。
[=val[,val...]]
-xe
ターゲットとなるアーキテクチャの命令セットを指定する
（isa）
。
-xF
対応なし
-xFオプションは，リンカによる関数と変数の最適な並べ替えを有効にする。
-xhelp=flags
--help
各コンパイラフラグの簡単な説明を表示する。
-xhelp=readme
対応なし
オンラインのREADMEファイルの内容を表示する。
-xia
対応なし
適切な区間演算ライブラリにリンクし，適切な浮動小数点環境を設定する。
-xildoff
対応なし
インクリメンタルリンカを無効にする。
-xildon
対応なし
インクリメンタルリンカを有効にする。
-xinline[=func[,func...]]
対応なし
どのユーザ定義ルーチンが，オプティマイザ-xO3以上でインライン化できるのかを指
-xipo[={0|1|2}]
対応なし
内部手続きの最適化を実行する。
-xjobs=n
対応なし
複数のプロセッサでコンパイルする。
-xlang=lang[,lang]
対応なし
定する。
適切な実行時ライブラリをインクルードし，指定された言語に対して適切な実行時
環境を整える。
-xldscope={v}
対応なし
-xlibmieee
対応なし
例外の場合，libmが数学ルーチンに対して，IEEE 745値を返すようにする。
-xlibmil
対応なし
_____libmライブラリルーチンを，最適化のためにインライン化する。
-xlibmopt
対応なし
最適化された数学ルーチンのライブラリを使用する。
-xlic_lib=sunperf
対応なし
Sunの提供するパフォーマンス・ライブラリにリンクする。
-xlicinfo
--version
ライセンスサーバの情報を表示する。
-xlinkopt[=level]
対応なし
再配置可能なオブジェクトファイルに対して，リンク時の最適化を実行する。
-Xm
-fdollars-in-identifiers
識別子に，$（ドル記号）文字を受け入れる。
-xM
-M
externシンボルの定義に対するデフォルトのリンカスコープを変更する。
指定されたC++プログラムに対して，プリプロセッサのみを実行し，makefileの依存関
係を生成して，その結果を標準出力に出力することを要求する。
（makefileと依存関係
に関する詳細については，make（1）を参照のこと。
）
73
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 74
Sun Cオプション
説明
GCCオプション
このオプションは-xMとほぼ同じであるが，/usr/include ヘッダファイルの依存関係を
-xM1
-M
-xMerge
対応なし
データ・セグメントをテキスト・セグメントとマージする。
-xmemalign[=ab]
対応なし
このコマンドで，想定される最大のメモリ境界合わせと，誤って境界合わせされたデー
-xnativeconnect[=n]
対応なし
-xnolib
-nodefaultlibs
デフォルトのシステムライブラリへのリンクを無効にする。
-xnolibmil
対応なし
コマンドライン上の-xlibmilを取り消す。
-xnolibmopt
対応なし
数学ルーチンライブラリを使用しない。
-xOn
-O[level]
最適化レベル（n）を指定する。G++の最適化レベルは0..3およびsである。
-xopenmp[=i]
対応なし
報告せず，コンパイラの提供するヘッダファイルの依存関係は報告しない。
タの動作を指定する。
Native Connect Tool（NCT）のためのコンパイルを可能にする。
OpenMP指令による明示的な並列化を有効にするには，-xopenmpオプションを使用
する。
-xpagesize=n
ターゲット固有
スタックおよびヒープのためのページサイズを設定する。
-xpagesize_heap=n
ターゲット固有
ヒープのためのメモリのページサイズを設定する。
-xpagesize_stack=n
ターゲット固有
スタックのためのメモリのページサイズを設定する。
-xpch=v
対応なし
プリコンパイル済みヘッダ機能を有効にする。プリコンパイル済みヘッダのサポート
-xpchstop=file
対応なし
-xpg
-pg
gprof（1）
によるプロファイリングのためのコンパイルを実行する。
-xport64[=v]
対応なし
64ビット環境へのコードのポーティングを支援するためのオプション。
-xprefetch[=a[,a]]
対応なし
先読みをサポートするアーキテクチャ上で先読み命令を有効にして，制御する。
-xprefetch_level=l
対応なし
-xprefetch=autoで定義した先読み命令の自動挿入を制御する。
-xprofile=collect
-fprofile-generate
はGCC 3.4以降で利用可能。
-xpchによって作成されたプリコンパイル済みのヘッダファイルに対する最後のインク
ルードファイルを指定する。
コンパイラに対して，プロファイリング情報を収集するためのコードを生成するように
命令する。
-xprofile=use
-fprofile-use
-xprofile=tcov
-fprofile-arcs
-xprofile=collectでコンパイルしたプログラムの実行によって得られた情報を使用する。
プログラムに，tcovツールを使用して調べることのできる情報を作成させる。GCCで
は，gcovを使用する。
-xprofile_ircache[=path]
対応なし
収集の段階で保存されたコンパイルデータを再利用して使用の段階におけるコンパ
イル時間を改善するには，-xprofile=collect|useで-xprofile_ircache[=path]を使用する。
-xprofile_pathmap
対応なし
-xregs=r[,r...]
-ffixed-<reg>または
コンパイラによるプロファイル・データ検索を支援するために，-xprofile=useと共に使
用する。
生成されたコードのためのレジスタの使用を指定する。G++では，-ffixed-<reg>,
-fcall-used-<reg>または
-fcall-used-<reg>および-fcall-saved-<reg>オプションを使用して，特定のレジスタの
-fcall-saved-<reg>
使用を指定する。
-xs
対応なし
オブジェクトファイルなしで，dbx（1）
によるデバッグを可能にする。
-xsafe=mem
対応なし
コンパイラが，メモリ保護違反が発生しないことを前提とすることを可能にする。
-xsb
対応なし
ソースコード・ブラウザ用の情報を生成する。
-xsbfast
対応なし
コンパイルは行わず，ソースコード・ブラウザ用の情報のみを生成する。
-xspace
対応なし
コードサイズが大きくなるような最適化を許可しない。
-xtarget=name
ターゲット固有
命令セットと最適化のターゲットとなるプラットホームを指定する。g++（1）マン
-mオプションを参照
ページを参照のこと。
のこと
-xthreadvar[=o]
対応なし
コンパイラのスレッドローカルな記憶機能を利用するには，このオプションを__thread
宣言指定子と組み合わせて使用する。
-xtime
-ftime-report
コンパイラドライバに，さまざまなコンパイル作業の実行時間を報告させる。
-xtrigraphs[={yes|no}]
-trigraphs
ISO/ANSI C標準によって定義されているとおり3文字表記シーケンスを認識できる
-xunroll=n
-funroll-all-loopsまたは
ようにするか否かを決定する。GCCのデフォルトは無効になっている。
可能な限りのループの展開を有効にする。
-funroll-loops
-xustr=
対応なし
UTF-16文字列をサポートする。
{ascii_utf16_ushort|no}
-xvis
対応なし
VIS™命令セットソフトウェア開発キット
（VSDK）で定義されているアセンブリ言語テン
プレートを使用する際には，-xvis=[yes|no]コマンドを使用する。
ゼロ以外の終了状態を戻すことにより，すべての警告をエラーに変換する。
-xwe
-Werror
-z[ ]arg
-Wl,linker-argumentまたは リンクエディタのオプション
-Xlinker option
74
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 75
C リンカオプションの比較
以下の表は，SolarisおよびGNUのリンカスイッチを比較し，可能なかぎり対応するオプションを示したものです。必ずしも完全に一致
していないものについても，推奨するオプションを示します。すべてのオプションに関する詳細については，リンカのマニュアルまた
はmanページを参照ください。
Solaris オプション
説明
Linuxオプション
対応なし
強制的に64ビットイメージを作成する。
-a
-static
静的な実行可能ファイルを生成する。
-b
対応なし
動的な非位置独立コード（non-pic）の実行可能ファイルを生成する。
-B direct
対応なし
直接結合を実行する。
-B dynamic | static
-B dynamic | static
動的または静的なライブラリを使用する。
-B eliminate
対応なし
バージョン化されていないシンボルをすべて削除する。
-B group
-B group
共有オブジェクトのグループを作成する。
-B local
対応なし
バージョン化されていないグローバルシンボルをローカルに降格する。
-B reduce
対応なし
バージョン化されているシンボルデータの量を削減する。
-B symbolic
-Bsymbolic
リンク時のシンボル結合を実行する。
-c name
-c name
設定ファイルnameを使用する。
-C
対応なし
C++ demangle診断
-d [ y | n ]
-d [ y | n ]
動的リンクを実行する
（デフォルトはy）
。
-64
-D token
対応なし
専門的なデバッグ情報を表示する。
-e epsym
-e epsym
イメージのエントリポイントをepsymにする。
-f name
-f name
nameのフィルタとして使用される共有オブジェクト。
-F name
-F name
nameのフィルタとして使用される共有オブジェクト。
-G
-shared
共有オブジェクト
（ライブラリ）を作成する。
-h name
-h name
内部ライブラリの名をnameに設定する。
-i
デフォルトの動作
リンク時に，LD_LIBRARY_PATHを無視する。
-I name
-I name
nameを実行可能ファイルのインタプリタとして使用する。
-l libname
-l libname
ライブラリlibnameをリンク内にインクルードする。
-L path
-L path
pathをライブラリ検索パスに追加する。
-m
-M
セクションマップをstdout上に表示する。
-M map
対応なし
マップファイルmapを使用する。
-N string
--add-needed string
stringの明示的な依存関係を追加する。
-o outfile
-o outfile
オブジェクトファイルoutfileを作成する。
-p auditlib
対応なし
作成されたイメージを，
（継承される）auditlibを使って実行時に監査する。
-P auditlib
対応なし
作成されたイメージを，
（されていない）auditlibを使って実行時に監査する。
-Q [y | n]
対応なし
リンカのバージョン情報を .commentに追加する。
-r
-r
再配置可能なオブジェクトをマージする。
-R path
-rpath path
pathを使って，実行時に依存関係を捜し出す。
-s
-s
シンボル情報を削除する。
-S supportlib
対応なし
サポートライブラリを指定する。
-t
対応なし
異なるタイプの同一名称の複数のシンボルを許可する。
-z muldefsを参照のこと
未定義のシンボルsymnameを作成する。
-u symname
-u symname
-V
-V
ld のバージョンを出力する。
-Y P,dirlist
-Y dirlist
デフォルトの位置ではなく，dirlistを使って，ライブラリ検索を行う。
-z absexec
対応なし
リンク時に，絶対シンボルをライブラリから実行可能ファイルに昇格させる。
-z allextract
--whole-archive
アーカイブライブラリからすべての構成要素を抽出する。
-z combreloc
-z combreloc
再配置セクションをマージする。
-z defaultextract
--no-whole-archive
デフォルトのロジックを使用して，アーカイブから構成要素を抽出する。
-z defs
--error-unresolved-symbols
リンク時に，未解決のシンボルを致命的なエラーにする。
-z direct |
対応なし
直接結合を有効／無効にする。
nodirect
-z endfiltee
対応なし
ライブラリに，フィルタの終了点として印を付ける。
-z finiarray=func
-fini func
funcをfiniルーチンとして宣言する。
-z groupperm |
対応なし
グループに対するパーミッションを有効／無効にする。
nogroupperm
-z ignore | record
対応なし
リンク行上にない依存関係を記録，または無視する
（デフォルトは record）
。
-z initarray=func
-init
funcをinitルーチンとして宣言する。
-z initfirst
-z initfirst
オブジェクトのinitルーチンを，他のあらゆるルーチンよりも先に実行する。
-z interpose
-z interpose
オブジェクトに，直接結合のインタポーザとして印を付ける。
-z lazyload |
対応なし
依存関係の遅延ローディングを有効／無効にする。
nolazyload
75
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 76
Solaris オプション
説明
Linuxオプション
-z loadfltr
ロード時にフィルタを速やかに適用する。
-z muldefs
--allow-multiple-definition
複数の定義を許可する。
-z nodefs
--allow-shlib-undefined
未定義のシンボルを許可する。
-z nodefaultlib
-z nodefaultlib
依存関係を捜し出す際に，オブジェクトのrunpathのみを使用する。
-z nodelete
-z nodelete
実行時に，ライブラリがアンロードされることを防止する。
-z nodlopen
-z nodlopen
dlopen（3）で開くことができないライブラリ。
-z nodump
-z nodump
dldump（ ）で削除することができないライブラリ。dldump（ ）はLinuxでは使用
-z nopartial
対応なし
-z noversion
対応なし
バージョン化を無効にする。
-z now
-z now
実行時シンボルの遅延結合を無効にする。
-z origin
-z origin
実行時に速やかな$ORIGIN処理を要求する。
-z preinitarry=func
対応なし
funcをpre-init関数として宣言する。
-z redlocsym
-x
ローカルシンボルをすべて削除する。
-z rescan
-( archives -)
抽出するものがなくなるまで，アーカイブを再スキャンする。
-z text | textwarn
対応なし
書き込み不可のセクションのために再配置の取り扱い方法を変更する。
-z loadfltr
できない。
部分的に初期化されたシンボルを防ぐ。
| textoff
-z weakextract
対応なし
参照された弱いシンボルを，アーカイブから抽出する。
-z verbose
--verbose
リンカメッセージを出力する。
76
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 77
D Makeのサフィックス規則
サフィックス規則は，make（1）に組み込まれており，あるサフィックスのファイル，たとえばfoo.cを，他のサフィックス，たとえばfoo.oに
変換するためのテンプレートとして利用されます。この付録では，Solaris Make Version 1.0およびGNU Make Version 3.79.1のコマンドの
サフィックス規則を示します。
なお，SolarisとGNUのMakeの主な違いのひとつとして，Solarisの定義する規則では，SCCSのバックアップファイルのサフィックスとし
てチルダ（~）をサポートしている点が挙げられます。ご注意ください。
サフィックス
.c.a:
.C.a:
.c.ln:
.c.o:
.C.o:
.c:
.C:
.cc.a:
.cc.o:
.cc:
.cps.h:
.def.sym:
.f.a:
$(LINK.C) -o $@ $< $(LDLIBS)
$(COMPILE.cc) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.cc) $(OUTPUT_OPTION) $<
$(LINK.cc) -o $@ $< $(LDLIBS)
.f90.o:
.f90:
.f:
$(CPS) $(CPSFLAGS) $*.cps
$(COMPILE.def) -o $@ $<
$(COMPILE.f) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.F) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.f) $(OUTPUT_OPTION) $<
$(COMPILE.F) $(OUTPUT_OPTION) $<
$(COMPILE.f90) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.f90) $(OUTPUT_OPTION) $<
$(LINK.f90) -o $@ $< $(LDLIBS)
$(LINK.f) -o $@ $< $(LDLIBS)
.F:
$(LINK.F) -o $@ $< $(LDLIBS)
.ftn.a:
$(COMPILE.ftn) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.ftn) $(OUTPUT_OPTION) $<
$(LINK.ftn) -o $@ $< $(LDLIBS)
javac $<
$(RM) $@
$(LEX.l) $< > $@
$(RM) $*.c
$(LEX.l) $< > $*.c
$(LINT.c) -o $@ -i $*.c
$(RM) $*.c
$(RM) $*.c
$(LEX.l) $< > $*.c
$(COMPILE.c) -o $@ $*.c
$(RM) $*.c
.F.a:
.f.o:
.F.o:
.f90.a:
.ftn.o:
.ftn:
.java.class:
.l.c:
.l.ln:
.l.o:
77
Solarisの規則
$(COMPILE.c) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.C) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(LINT.c) $(OUTPUT_OPTION) -c $<
$(COMPILE.c) $(OUTPUT_OPTION) $<
$(COMPILE.C) $(OUTPUT_OPTION) $<
$(LINK.c) -o $@ $< $(LDLIBS)
GNUの規則
なし
なし
$(LINT.c) -C$* $<
$(COMPILE.c) $(OUTPUT_OPTION) $<
$(COMPILE.C) $(OUTPUT_OPTION) $<
$(LINK.c) $^ $(LOADLIBES) $(LDLIBS)
-o $@
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS)
-o $@
なし
$(COMPILE.cc) $(OUTPUT_OPTION) $<
$(LINK.cc) $^ $(LOADLIBES) $(LDLIBS)
-o $@
なし
$(COMPILE.def) -o $@ $<
なし
なし
$(COMPILE.f) $(OUTPUT_OPTION) $<
$(COMPILE.F) $(OUTPUT_OPTION) $<
なし
なし
なし
$(LINK.f) $^ $(LOADLIBES) $(LDLIBS)
-o $@
$(LINK.F) $^ $(LOADLIBES) $(LDLIBS)
-o $@
なし
なし
なし
なし
@$(RM) $@
$(LEX.l) $< > $@
@$(RM) $*.c
$(LEX.l) $< > $*.c
$(LINT.c) -i $*.c -o $@
$(RM) $*.c
なし
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 78
サフィックス
.l:
.mod.a:
.mod.o:
.mod:
.p.a:
.p.o:
.p:
.r.a:
.r.o:
.r:
.s.a:
.S.a:
.s.o:
.S.o:
.sh:
.y.c:
.y.ln:
.y.o:
.y:
.cc~.a:
.cc~.o:
.cc~:
.cps~.h:
.c~.a:
.C~.a:
.c~.ln:
Solarisの規則
$(RM) $*.c
$(LEX.l) $< > $*.c
$(LINK.c) -o $@ $*.c -ll $(LDLIBS)
$(RM) $*.c
$(COMPILE.mod) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.mod) -o $@ $<
$(COMPILE.mod) -o $@ -e $@ $<
$(COMPILE.p) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.p) $(OUTPUT_OPTION) $<
$(LINK.p) -o $@ $< $(LDLIBS)
$(COMPILE.r) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.r) $(OUTPUT_OPTION) $<
$(LINK.r) -o $@ $< $(LDLIBS)
$(COMPILE.s) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.S) -o $% $<
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(COMPILE.s) -o $@ $<
$(COMPILE.S) -o $@ $<
$(RM) $@
cat $< > $@
chmod +x $@
$(YACC.y) $<
mv y.tab.c $@
$(YACC.y) $<
$(LINT.c) -o $@ -i y.tab.c
$(RM) y.tab.c
$(YACC.y) $<
$(COMPILE.c) -o $@ y.tab.c
$(RM) y.tab.c
$(YACC.y) $<
$(LINK.c) -o $@ y.tab.c $(LDLIBS)
$(RM) y.tab.c
$(GET) $(GFLAGS) -p $< > $*.cc
$(COMPILE.cc) -o $% $*.cc
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.cc
$(COMPILE.cc) $(OUTPUT_OPTION)
$*.cc
$(GET) $(GFLAGS) -p $< > $*.cc
$(LINK.cc) -o $@ $*.cc $(LDLIBS)
$(GET) $(GFLAGS) -p $< > $*.cps
$(CPS) $(CPSFLAGS) $*.cps
$(GET) $(GFLAGS) -p $< > $*.c
$(COMPILE.c) -o $% $*.c
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.C
$(COMPILE.C) -o $% $*.C
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.c
$(LINT.c) $(OUTPUT_OPTION) -c $*.c
GNUの規則
なし
なし
$(COMPILE.mod) -o $@ $<
$(COMPILE.mod) -o $@ -e $@ $^
なし
$(COMPILE.p) $(OUTPUT_OPTION) $<
$(LINK.p) $^ $(LOADLIBES) $(LDLIBS)
-o $@
なし
$(COMPILE.r) $(OUTPUT_OPTION) $<
$(LINK.r) $^ $(LOADLIBES) $(LDLIBS)
-o $@
なし
なし
$(COMPILE.s) -o $@ $<
$(COMPILE.S) -o $@ $<
cat $< >$@
chmod a+x $@
$(YACC.y) $<
mv -f y.tab.c $@
$(YACC.y) $<
$(LINT.c) -C$* y.tab.c
$(RM) y.tab.c
なし
なし
なし
なし
なし
なし
なし
なし
なし
78
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 79
サフィックス
.c~.o:
.C~.o:
.c~:
.C~:
.def~.sym:
.f90~.a:
.f90~.o:
.f90~:
.ftn~.a:
.ftn~.o:
.ftn~:
.f~.a:
.F~.a:
.f~.o:
.F~.o:
.f~:
.F~:
.java~.class:
.l~.c:
.l~.ln:
.l~.o:
79
Solarisの規則
$(GET) $(GFLAGS) -p $< > $*.c
$(CC) $(CFLAGS) -c $*.c
$(GET) $(GFLAGS) -p $< > $*.C
$(COMPILE.C) $(OUTPUT_OPTION) $*.C
$(GET) $(GFLAGS) -p $< > $*.c
$(CC) $(CFLAGS) $(LDFLAGS) -o $@
$*.c
$(GET) $(GFLAGS) -p $< > $*.C
$(LINK.C) -o $@ $*.C $(LDLIBS)
$(GET) $(GFLAGS) -p $< > $*.def
$(COMPILE.def) -o $@ $*.def
$(GET) $(GFLAGS) -p $< > $*.f90
$(COMPILE.f90) -o $% $*.f90
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.f90
$(COMPILE.f90) $(OUTPUT_OPTION)
$*.f90
$(GET) $(GFLAGS) -p $< > $*.f90
$(LINK.f90) -o $@ $*.f90 $(LDLIBS)
$(GET) $(GFLAGS) -p $< > $*.ftn
$(COMPILE.ftn) -o $% $*.ftn
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.ftn
$(COMPILE.ftn) $(OUTPUT_OPTION)
$*.ftn
$(GET) $(GFLAGS) -p $< > $*.ftn
$(LINK.ftn) -o $@ $*.ftn $(LDLIBS)
$(GET) $(GFLAGS) -p $< > $*.f
$(COMPILE.f) -o $% $*.f
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.F
$(COMPILE.F) -o $% $*.F
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.f
$(FC) $(FFLAGS) -c $*.f
$(GET) $(GFLAGS) -p $< > $*.F
$(FC) $(FFLAGS) -c $*.F
$(GET) $(GFLAGS) -p $< > $*.f
$(FC) $(FFLAGS) $(LDFLAGS) -o $@
$*.f
$(GET) $(GFLAGS) -p $< > $*.F
$(FC) $(FFLAGS) $(LDFLAGS) -o $@
$*.F
$(GET) $(GFLAGS) -p $< > $*.java
javac $<
$(GET) $(GFLAGS) -p $< > $*.l
$(LEX) $(LFLAGS) $*.l
mv lex.yy.c $@
$(GET) $(GFLAGS) -p $< > $*.l
$(RM) $*.c
$(LEX.l) $*.l > $*.c
$(LINT.c) -o $@ -i $*.c
$(RM) $*.c
$(GET) $(GFLAGS) -p $< > $*.l
$(LEX) $(LFLAGS) $*.l
$(CC) $(CFLAGS) -c lex.yy.c
rm -f lex.yy.c
mv lex.yy.c $@
GNUの規則
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 80
サフィックス
.l~:
.mod~.a:
.mod~.o:
.mod~:
.p~.a:
.p~.o:
.p~:
.r~.a:
.r~.o:
.r~:
.sh~:
.s~.a:
.S~.a:
.s~.o:
.S~.o:
.y~.c:
.y~.ln:
.y~.o:
.y~:
Solarisの規則
$(GET) $(GFLAGS) -p $< > $*.l
$(LEX) $(LFLAGS) $*.l
$(CC) $(CFLAGS) -c lex.yy.c
rm -f lex.yy.c
mv lex.yy.c $@
$(GET) $(GFLAGS) -p $< > $*.mod
$(COMPILE.mod) -o $% $*.mod
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.mod
$(COMPILE.mod) -o $@ $*.mod
$(GET) $(GFLAGS) -p $< > $*.mod
$(COMPILE.mod) -o $@ -e $@ $*.mod
$(GET) $(GFLAGS) -p $< > $*.p
$(COMPILE.p) -o $% $*.p
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.p
$(COMPILE.p) $(OUTPUT_OPTION) $*.p
$(GET) $(GFLAGS) -p $< > $*.p
$(LINK.p) -o $@ $*.p $(LDLIBS)
$(GET) $(GFLAGS) -p $< > $*.r
$(COMPILE.r) -o $% $*.r
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.r
$(COMPILE.r) $(OUTPUT_OPTION) $*.r
$(GET) $(GFLAGS) -p $< > $*.r
$(LINK.r) -o $@ $*.r $(LDLIBS)
$(GET) $(GFLAGS) -p $< > $*.sh
cp $*.sh $@
chmod a+x $@
$(GET) $(GFLAGS) -p $< > $*.s
$(COMPILE.s) -o $% $*.s
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.S
$(COMPILE.S) -o $% $*.S
$(AR) $(ARFLAGS) $@ $%
$(RM) $%
$(GET) $(GFLAGS) -p $< > $*.s
$(COMPILE.s) -o $@ $*.s
$(GET) $(GFLAGS) -p $< > $*.S
$(COMPILE.S) -o $@ $*.S
$(GET) $(GFLAGS) -p $< > $*.y
$(YACC) $(YFLAGS) $*.y
mv y.tab.c $@
$(GET) $(GFLAGS) -p $< > $*.y
$(YACC.y) $*.y
$(LINT.c) -o $@ -i y.tab.c
$(RM) y.tab.c
$(GET) $(GFLAGS) -p $< > $*.y
$(YACC) $(YFLAGS) $*.y
$(CC) $(CFLAGS) -c y.tab.c
rm -f y.tab.c
mv y.tab.o $@
$(GET) $(GFLAGS) -p $< > $*.y
$(YACC) $(YFLAGS) $*.y
$(COMPILE.c) -o $@ y.tab.c
$(RM) y.tab.c
GNUの規則
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
80
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 81
E ポーティング・チェックリスト
このチェックリストに記入することにより，ポーティング作業に関連する疑問に対する回答をまとめることができます。
• ポーティングするアプリケーションの名前は何ですか。
• アプリケーションをポーティングする主な理由は何ですか。
• アプリケーションが何をするものなのかを，一文で説明してください。
• 現行のアプリケーションはどのオペレーティング・システムで稼働していますか。できれば，ソフトウェアでレポートされるバージョ
ンも記入してください（たとえば，Solaris 8，Solaris 9，HP-UX 11i v2など）
。
• アプリケーションのポーティング先のオペレーティング・システムは何ですか。
• ポーティングは，他に大幅な機能変更を伴いますか（たとえば，32ビットから64ビットへの移行など）
。もしそうなら，簡単に説明して
ください。
• アプリケーションを作成するために使用しているすべてのプログラミング言語とそのバージョンを，以下に記入してください（たと
えば，SUN C Version 5.5，HP ANSI C Version A.05.50，Perl 5.8，Java 1.4.1など）
。
言語
バージョン
コメント
• アプリケーションの実行に必要なすべてのレイヤード・プロダクト，独自開発のソフトウェア，または他社製製品を以下に記入してく
ださい（たとえば，Oracle9iデータベース，OpenGL，Apacheなど）
。
言語
バージョン
コメント
• アプリケーションの作成に必要なすべてのソースコードファイルがありますか。
はい □
いいえ □
• ソースコードの量はどれくらいですか。 コードの行数，または圧縮されていないソースファイルのメガバイト数を記入してください。
• このアプリケーションに関連づけられたデータの量はどれくらいですか。データの構造を説明できますか（たとえば，フォーマットさ
れたデータベース，フォーマットされていないバイナリ）
。
• 最後にアプリケーション環境をソースから完全に再コンパイル，再ビルドしたのはいつですか。
• アプリケーションを定期的に再ビルドしていますか。その頻度はどれくらいですか。
• アプリケーションのメンテナンスはそのアプリケーションを熟知している開発者によって積極的に行われていますか。
• 新しくビルドしたアプリケーションが正常に稼働しているか否かのテストまたは検証はどのようにして行っていますか。
• 最適化のための性能分析ツールを持っていますか。 記入してください。
• これらのテスト，検証スイート，性能ツールはポーティングする必要がありますか。記入してください。
• ソースコードと構成の管理には，どのようなツールを使用していますか（たとえば，make，SCCS，RCSなど）
。
• 実際に運用しているシステムとは別に，開発およびテスト用の環境を持っていますか。
はい □
いいえ □
• 新しいバージョンのアプリケーションを実際に運用するまでに，どのような手順をとりますか。
81
H+I_マイグレ2C_PDF 06.2.14 6:59 PM ページ 82
82
H+I_マイグレ4C_PDF 06.2.14 7:25 PM ページ 5
インテル® Itanium® 2 プロセッサに関する情報は
http://www.intel.co.jp/jp/go/itanium2/
インテル® ソフトウェア開発製品に関する情報は
お問い合わせは日本ヒューレット・パッカード（株）
カスタマー・インフォメーションセンターへ
月∼金 9:00∼19:00
土 10:00∼18:00
03-6414-6512 （日、祝祭日、年末年始および5/1を除く）
http://www.intel.co.jp/jp/developer/software/products/
機器のお見積もりについては、代理店、または弊社営業にご相談ください。
インテルのオープンソースへの取り組み（英語）
HP Integrityサーバ製品に関する情報は
http://www.intel.com/opensource/
http://www.hp.com/jp/integrity
インテル株式会社
日本ヒューレット・パッカード株式会社
〒300-2635 茨城県つくば市東光台5-6
〒140-8641 東京都品川区東品川2-2-24 天王洲セントラルタワー
インテル、Intel ロゴ、Intel Inside、Intel Inside ロゴ、インテル Xeon、Itanium、およびPentiumは
アメリカ合衆国および他の国におけるインテル コーポレーションまたはその子会社の商標または登録商標です。
Red HatならびにShadow Manロゴは米国およびその他の国でRed Hat,Inc.の登録商標若しくは商標です。
LinuxはLinus Torvaldsの商標です。
記載されている会社名および商品名は、各社の商標または登録商標です。
記載事項は2006年1月現在のものです。
本書に記載された内容は、予告なく変更されることがあります。
本書中の技術的あるいは構成上の誤り、省略に対して、いかなる責任も追いかねますのでご了承ください。
© Copyright 2005, 2006 Hewlett-Packard Development Company,L.P.
JHS05644-02

アメージュZ シャワートイレ

ヴァージン航空会長女装し機内サービス 5 月 13 日 7 時 0 分

添付PDF書類／ 春のブライダルフェアチラシ

大学ブランディングにおけるロゴマークが 与える印象についての研究

①肩甲骨の可動性トレーニング（菱形筋） ②－1肩のインナーマッスル

#1｜おさがりファッションコーディネート

ウェブサイト掲載手順（PDF）

第9回 - 琉球大学附属図書館

HTPCを作ろう！

開催趣意書ダウンロード - JSOMS 日本口腔医療安全学会 トップページ