Table of Contents
Section 4.1, “バイナリーパッケージを使う”をご覧ください。
ブートストラップキットは、以下のようにして簡単にソースからインストールすることができます。
#
env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc
#
cd pkgsrc/bootstrap
#
./bootstrap
bootstrap を実行する前に、上で例示した方法以外で
pkgsrc を取得する方法については、Chapter 2, どこからpkgsrcを得て、どうやって最新に保つかを参照してください。
上で例示した bootstrap コマンドでは、
prefix (プログラムのインストール先) をデフォルトの
/usr/pkg
とし、
パッケージデータベースのディレクトリー (pkgsrc 内部の記録用) を
/var/db/pkg
とします。
これらをコマンドライン引数で設定することもできます。
bootstrap は bmake ツールをインストールします。 pkgsrc で構築をおこなう際には、この bmake を使ってください。 たとえばこの手引きにおいて “make” は bmake に読み替えてください。
いくつかのプラットフォームについては、以下のことを知っておくとよいでしょう。
対応は、 Darwin 5.x 以上に対しておこなわれています。 始める前に、Apple Developer Connection から Mac OS X Developer Tools をダウンロードしてインストールする必要があります。詳細は http://developer.apple.com/macosx/ をご覧ください。また、X11 Window System を使うパッケージを構築したい場合は、 X11 (Developer Tools に附属するオプションパッケージ) をインストールしておくことも必要です。
確認および対応は、 FreeBSD 4.7 および 5.0 に対しておこなわれています。 これら以外のバージョンでも動くかもしれません。
ブートストラップキットのインストールに際しては、 FreeBSD のユーザーランドのツールと衝突することがないように注意を払ってください。以下のような複数の事項があります。
FreeBSD の ports は、 /var/db/pkg
以下にパッケージデータベースを置きます。このため、
ブートストラップスクリプトの --pkgdbdir オプションで、
別の場所 (たとえば /usr/pkgdb
)
を指定することをおすすめします。
FreeBSD ports のツールを使う予定がない場合は、混同を避けるために、 それらを移動してしまってもいいかもしれません。たとえば以下のようにします。
#
cd /usr/sbin
#
mv pkg_add pkg_add.orig
#
mv pkg_create pkg_create.orig
#
mv pkg_delete pkg_delete.orig
#
mv pkg_info pkg_info.orig
ブートストラップスクリプトを使った際、
mk.conf
ファイルの例は
/etc/mk.conf.example
ファイルに置かれます。
Interix は Windows NT カーネルの POSIX 準拠のサブシステムで、 Cygwin よりも密接にカーネルと統合された Unix 風の環境を提供します。 Interix は Windows Services for Unix パッケージの一部であり、 ライセンスされた Windows 2000, XP (XP Home は含まず), 2003 のコピー用として、 無料で使うことができます。SFU は、http://www.microsoft.com/windows/sfu/ からダウンロードできます。
確認は、Services for Unix 3.5 に対しておこなわれています。 3.0 や 3.1 でも動作するかもしれませんが、公式には対応していません。 (3.0/3.1 の主な違いは、 pthreads がないことですが、このほかにも libc に欠けているものがあるかもしれません。)
Services for Unix Applications (別名 SUA) は、Windows Server 2003 R2 (5.2), Windows Vista および Windows Server 2008 (6.0), Windows 7 および Windows Server 2008 R2 (6.1) に統合されている構成要素です。本稿執筆時点において、 SUA の Interix 6.0 (32 ビット) および 6.1 (64 ビット) サブシステムで確認がおこなわれています。 これら以外のバージョンでも動作するかもしれません。 Interix 5.x サブシステムで、pkgsrc を使った確認はまだおこなわれていません。
pkgsrc を使うためには、Windows Services for Unix 3.5 の配布物のうち、 最低限、以下のパッケージをインストールする必要があります。
Utilities -> Base Utilities
Interix GNU Components -> (all)
Remote Connectivity
Interix SDK
Interix 上で pkgsrc を使う場合、Utilities 以下の "UNIX Perl" はインストールしないでください。これは共有モジュールに対応していない Perl 5.6 で、 /usr/local にインストールされますが、混乱を起こすだけです。これのかわりに、 pkgsrc (またはバイナリーパッケージ) の Perl 5.8 をインストールします。
Remote Connectivity 以下の "Windows Remote Shell Service" のインストールは必須ではありませんが、inetd を動作させるために Remote Connectivity そのものはインストールすることをおすすめします。
インストール中に、Interix のプログラムに対して setuid を有効にするかどうか、 また、パス名の大文字と小文字を標準で区別するかどうかを尋ねられるかもしれません。 setuid は有効にするようにし、また大文字と小文字はかならず区別するようにします。 (大文字と小文字を区別しないと、 perl をはじめ多くのプログラムが構築できなくなります。)
註: 最近の Windows サービスパックでは、 バイナリーを実行する方法を (データ実行防止機能を使ったものに) 変更します。 pkgsrc その他の gcc でコンパイルされたバイナリーを信頼して使うためには、 POSIX.EXE, PSXDLL.DLL, PSXRUN.EXE, PSXSS.EXE (899522 またはこれより新しいもの) を含んだホットフィックスをインストールする必要があります。 ホットフィックスは Microsoft からサポート窓口を通じて提供されていますが、 Debian Interix Port が、ほとんどの Interix ホットフィックスを個人的に使えるように http://www.debian-interix.net/hotfixes/ に用意しています。
Interix を使えるようにするためには、上述のホットフィックスのほか、 Data Execution Prevention を完全に無効化する必要があるかもしれません。 これが必要となるのは、ある種の CPU を使っている場合だけです。 上述のホットフィックスのいずれかひとつをインストールした後にも gcc その他のアプリケーションが依然として繰り返し segfault する場合には、 Windows ブートドライブ上の適切な "boot.ini" 行に、 以下のオプションを追加することができます: /NoExecute=AlwaysOff (警告: これは DEP を完全に無効化するものであり、 Administrators グループのユーザーとしてアプリケーションをよく実行する場合には、 セキュリティー上の危険となる可能性があります。)
SFU がすでにインストールされており、その設定を変更して pkgsrc が動作するようにしたい場合は、以下のことに気をつけてください。
UNIX Perl をアンインストールするため、Add/Remove Programs を使い、Microsoft Windows Services for UNIX を選んで Change をクリックします。インストーラーで Add or Remove を選んでから Utilities->UNIX Perl のチェックを外します。
ファイルシステムの大文字と小文字の区別を有効にするため、REGEDIT.EXE を実行して 以下のレジストリーキーを変更します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
DWORD 値 "obcaseinsensitive" を 0 に設定した後、リブートします。
setuid バイナリーを有効にするため (これは必須ではありません)、REGEDIT.EXE を実行して 以下のレジストリーキーを変更します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX
DWORD 値 "EnableSetuidBinaries" を 1 に設定した後、リブートします。
パッケージの管理者 (pkgsrc の "su" ユーザーと "pkg_add" を実行するユーザーのいずれかまたは両方) は、ローカルの Administrators グループに所属している必要があります。bootstrap を実行するユーザーも同様です。これは、通常の pkgsrc が "root" を要求するのにくらべ、若干緩い条件です。
パッケージの管理者は umask を 002 に設定するようにします。そうしておかないと、 自動的に "make install" が文句をいうようになります。こう設定することで、 /var/db/pkg 以下に書かれるディレクトリーに Administrators グループが確実に書き込み可能とできます。
http://www.interopsystems.com/ にある人気のある Interix バイナリーパッケージは、 古いバージョンの pkgsrc の pkg_* ツールを使います。 理想的には、これらは pkgsrc と混用しないほうがよいものです。 これらを pkgsrc のパッケージと同時に使う場合は、かならず、 それぞれのバイナリーパッケージに応じて適切な pkg_* ツールを使うようにしてください。
DOS 型のコンソールウィンドウ (csh および ksh のスタートアップショートカットから起動されるものを含む) 用の TERM の設定は "interix" です。 たいていのシステムには、そのような termcap/terminfo エントリーがありませんが、 ほとんどの場合、以下のような .termcap エントリーを用意すれば十分です。
interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi:
Interix は、完全な Unix 風のプラットフォームの とっつきやすく柔軟な代替品としては十分なものですが、Interix を最大限に活用したい場合は、若干の制約があることを知っておくとよいでしょう。
X11:
Interix には標準的な X11R6 クライアントライブラリー一式が附属しており、 X11 にもとづくアプリケーションを実行することができますが、 X サーバーは附属しません。X サーバーの選択肢としては、 StarNet X-Win32, Hummingbird Exceed (Interix 用に調整された Interop X Server というものを、Interop Systems が提供しています) や、 Cygwin に含まれるフリーの X11 サーバーがあります。
X11 アクセラレーション:
Interix は、Win32 アプリケーションとは完全に別の NT サブシステム内で動いているため、現在のところ、アクセラレーションのための X11 プロトコルの各種拡張 (MIT-SHM や DGA など) には対応していません。 ローカルの X サーバーを使った対話的なアプリケーションのほとんどは、 そこそこ速く動きますが、フルモーションビデオなど画像に特化したアプリケーションを動かすには、 思ったよりも速い CPU が必要になるかもしれません。
オーディオ:
Interix は、オーディオ出力にネイティブで対応していません。
オーディオに対応するため、pkgsrc では Interix 上で esound
クライアントサーバー型オーディオシステムを使っています。
他のほとんどのプラットフォームとは異なり、
audio/esound
パッケージには、
esd サーバーが含まれません。
Interix ホストを経由してオーディオを出力するには、
emulators/cygwin_esound
パッケージもあわせてインストールする必要があります。
CD/DVD, USB, SCSI:
現在のところ、Interix はデバイスへの直接のアクセスに対応していませんので、 CD/DVD ドライブ、USB デバイス、SCSI デバイスを、 ファイルシステム経由以外の方法で使うことはできません。このため、 Interix を使って、直接 CD/DVD を焼くことなどはできません。
テープドライブ:
CD-ROM や SCSI デバイスと同様の制約があるため、 Interix ではテープドライブに直接アクセスすることもできません。ただし、 Cygwin を介して使うことで (Cygwin の esound サーバーを介してオーディオを使えるように) テープドライブにアクセスできるようにするための作業がおこなわれています。
一般的に、Windows システム上に "root" ユーザーを用意することは必須ではありません。 ユーザーがローカルの Administrators グループに属してさえいれば、それで十分です。 ただし、現在のところ、パッケージのなかには "root" という名前のユーザーが特権ユーザーであることを前提にしているものがあります。 そのようなパッケージのために、"root" という名前のユーザーを作ってもかまいませんが、 ローカルの Administrators グループ (または、お使いの言語でこれに対応するもの) に属させるようにしてください。
pkg_add は、$PKG_DBDIR
内のディレクトリーを、モード 0775 ではなく
0755 で作成します。この問題を回避するため、当面は、ローカルの
Administrator (または、お使いの言語でこれに対応するもの)
としてパッケージをインストールするか、
各パッケージのインストール後に以下のコマンドを実行してください。
#
chmod -R g+w $PKG_DBDIR
機能する C コンパイラー、つまり、 gcc または SGI の MIPS
および MIPSpro コンパイラー (cc/c89) が必要です。 CC
環境変数を、
使用するコンパイラーに応じて設定してください。
MIPSpro コンパイラースイートのライセンスがない場合は、http://freeware.sgi.com/
から gcc の tar 配布ファイルをダウンロードすることができます。
IRIX 6.5.17 以上が必要です。 このバージョンの IRIX で if_indextoname(3), if_nametoindex(3) などへの対応がおこなわれたからです。
現在のところ、pkgsrc は同時には一つの ABI にしか対応しません。つまり、 古い 32 ビット ABI、新しい 32 ビット ABI、64 ビット ABI を切り替えることはできません。 最初に "abi=n32" を使って始めた場合は、 すべてのパッケージがこれを使って構築されることになります。
このため、環境変数または mk.conf
の
CFLAGS
が衝突しないようにしてください。
特に、 n32 オブジェクトファイルに lib64 を、また、その逆の組合せを、
リンクしないようにしてください。
/etc/compiler.defaults
を確認してください。
pkgsrc ツリーの実体を別ホストから NFS を使ってマウントしている場合は、必ず
WRKOBJDIR
をローカルのディレクトリーに設定しておいてください。
IRIX のリンカーは、ネットワーク経由でマウントされたファイルシステム越しにリンクするときに
問題を起こすことが時々あるからです。
事前準備の過程では、imake(1) などのプログラムにすべて正しいオプションが設定されるはずですが、
ローカルの設定に依存するオプションを設定したい場合があるかもしれません。
詳細は、pkgsrc/mk/defaults/mk.conf
をご覧ください。
そしてもちろん、お使いのコンパイラーのマニュアルページもご覧ください。
SGI の MIPSPro コンパイラーを使っている場合は、
mk.conf
で
PKGSRC_COMPILER= mipspro
を設定してください。これを設定しないと、
pkgsrc は gcc を使っていることを仮定するので、コンパイラーに不適切なフラグを渡すことがあります。
なお、標準状態では、bootstrap は適切な mk.conf.example
を作成するはずです。
gcc と MIPSPro コンパイラーチェインの両方をインストールしているが、
必ず MIPSPro を使うようにしたい場合は、PATH
に gcc の場所 (ありがちなのは
/usr/freeware/bin
) を含めないでください。さらに (重要)、
'--preserve-path' フラグを bootstrap に渡してください。
Linux のなかには、libtermcap と libcurses (libncurses) のいずれかを必要とするものがあります (たとえば Debian GNU/Linux など)。そのようなディストリビューションでは libncurses-dev パッケージ (または相当品) をインストールすれば問題なくなるはずです。
pkgsrc は gcc (GNU Compiler Collection) と icc (Intel C++ Compiler) のどちらにも対応しています。gcc が標準で使われます。 icc は i386 上の icc 8.0 と 8.1 で確認がおこなわれています。
icc を使って bootstrap をおこなうには、以下のようにします (icc は標準のディレクトリーにインストールされているものとします)。
env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ ac_cv___attribute__=yes ./bootstrap
icc 8.1 では、引数の -static-libcxa を `-i-static' にする必要があります。
icc は __attribute__ に対応していますが、GNU configure のテストではネストした関数を使っており、 icc はネストした関数に対応していません。__attribute__ を #undef してしまうと、 Linux の多くのヘッダーファイルが __attribute__ なしでは正しくコンパイルできず、 壊れてしまうという副作用があります。このため、テストは、コンパイラーが __attribute__ に対応しているとしたもので上書きする必要があります。
bootstrap した後に、mk.conf
で
PKGSRC_COMPILER
を設定します。
PKGSRC_COMPILER= icc
icc がインストールされるディレクトリーは標準では
/opt/intel_cc_80
であり、pkgsrc
でもこのディレクトリーを標準としています。これ以外のディレクトリーに
icc をインストールしている場合は、mk.conf
で
ICCBASE
を設定してください。
ICCBASE= /opt/icc
pkgsrc は、icc が提供する実行時ライブラリーを静的リンクするので、 作られたバイナリーはその共有ライブラリーがインストールされていないシステムでも 動かすことができます。
ただし、libtool は、C++ の共有ライブラリーをリンクして記録する時に実行された (ライブラリーごとに -Bstatic や -Bdynamic オプションの指定がまちまちな) ld(1) コマンドをもとにライブラリーの一覧を展開します このことから、libtool でリンクされた C++ の共有ライブラリーは、libtool が修正されない限り、 icc のライブラリーに対して実行時依存性を持った状態になります。
確認および対応は、 OpenBSD 3.0 および 3.2 に対しておこなわれています。
ブートストラップキットのインストールに際しては、 OpenBSD のユーザーランドのツールと衝突することがないように注意を払ってください。以下のような複数の事項があります。
OpenBSD の ports は、 /var/db/pkg
以下にパッケージデータベースを置きます。このため、
ブートストラップスクリプトの --pkgdbdir オプションで、
別の場所 (たとえば /usr/pkgdb
)
を指定することをおすすめします。
OpenBSD ports のツールを使う予定がない場合は、混同を避けるために、 それらを移動してしまってもいいかもしれません。たとえば以下のようにします。
#
cd /usr/sbin
#
mv pkg_add pkg_add.orig
#
mv pkg_create pkg_create.orig
#
mv pkg_delete pkg_delete.orig
#
mv pkg_info pkg_info.orig
ブートストラップスクリプトを使った際、
mk.conf
ファイルの例は
/etc/mk.conf.example
ファイルに置かれます。
OpenBSD の make プログラムは
mk.conf
も使います。
このファイル中の pkgsrc 特有の記述を以下のように括ることで、
回避することができます。
.ifdef BSD_PKG_MK # pkgsrc の記述。たとえば defaults/mk.conf の挿入など .else # OpenBSD の記述 .endif
対応は x86 と sparc それぞれの Solaris 2.6 から 9 までに対しておこなわれています。 機能する C コンパイラーが必要です。 gcc 2.95.3 および Sun WorkShop 5 の両者で確認がおこなわれています。
Solaris 8 でのブートストラップ過程およびパッケージの構築では、 以下の各パッケージが必要になります。
SUNWsprot
SUNWarc
SUNWbtool
SUNWtoo
SUNWlibm
なお、2006 年 6 月現在、Solaris 上では GNU binutils はサポートされていません。
どのコンパイラーを使うにせよ、コンパイラーツールと
$prefix を、必ず PATH
に含めてください。
これは、/usr/ccs/{bin,lib}
や、たとえば /usr/pkg/{bin,sbin}
などです。
どのパッケージの構築にも同じ gcc だけを使うようにすると、 話が簡単になります。
外部から導入した gcc を使うのはブートストラップの時だけにして、
その後は gcc を
lang/gcc
から構築するかバイナリーパッケージをインストールして、
ブートストラップで使った gcc は削除することをおすすめします。
gcc のバイナリーパッケージは、http://www.sunfreeware.com/ から辿れます。
少なくとも、以下の各パッケージを (WorkShop 5.0 から) インストールしておく必要があります。
SPROcc - Sun WorkShop Compiler C 5.0
SPROcpl - Sun WorkShop Compiler C++ 5.0
SPROild - Sun WorkShop Incremental Linker
SPROlang - Sun WorkShop Compilers common components
mk.conf
で、以下の変数を設定します。
CC= cc CXX= CC CPP= cc -E CXXCPP= CC -E
C プリプロセッサーを使って
C のソースコード以外のものを処理するパッケージのなかには、
この CPP
の設定では問題が起きるものがあるかもしれません。
64 ビットパッケージを構築する場合に必要なことは、
mk.conf
ファイルに以下の行を追加するだけです。
PKGSRC_COMPILER= sunpro ABI= 64
この設定は、SPARC アーキテクチャーについてのみ確認がおこなわれています。 Intel および AMD マシンでは、 必要な作業がまだ残っています。
libtool を使っていると、時々、/bin/ksh
がセグメンテーションフォールトを起こしてクラッシュすることがあります。
回避策は、たとえば shells/bash
をインストールして、
以下の各行を mk.conf
に追加するなどして、
別のシェルを configure スクリプト用に使うことです。
CONFIG_SHELL= ${LOCALBASE}/bin/bash WRAPPER_SHELL= ${LOCALBASE}/bin/bash
こうしてから、devel/libtool-base
パッケージを構築しなおします。