Cygwin ツールは、広く普及している GNU の開発ツールを、Windows NT, 95, 98 用に移植したものです。これらのプログラムは、それらが 必要としている UNIX システムコールや環境を提供する Cygwin ライブ ラリによって動作します。
これらのツールをインストールすることによって、標準 Microsoft Win32 APIおよび Cygwin API を使っての Win32 コンソールアプリケー ション、または GUI アプリケーションの作成が可能になりました。こ の結果、たくさんの重要な UNIX プログラムを、大規模なソースコード の修正をすることなく容易に移植することが可能になります。これはほ とんどの GNU ソフトウエアの configure とビルドも含みます(cygwin 開発ツール自身に入っているパッケージも含まれます)。開発ツールが あなたにとってあまり役に立たなくても、このパッケージで提供される たくさんのUNIX 標準ユーティリティに興味を持たれるかも知れません。 これらは(同時に提供される)bash シェル、 Windows 標準のコマンドシェ ルのどちらからでも使用できます。
はい。いくつかは GNU のソフトウェア(gcc、gas、ld、など)で、いく つかは標準 Berkeley license などのライセンスに含まれます。パブリッ クドメインなものもあれば、Cygnus が書いて GPL に置かれたものもあ ります。シェアウェアはありません。あなたはこれを使用するために、 誰かにお金を支払う必要はありませんが、しかし、あなたがこれらのツー ルを使用する上で GNU General Public License がどのように影響を与 えるかについての詳細な情報を、この FAQ の copyright の項を読んで 確認しなければなりません。
特に、もし Cygwinを使って商用(GPL でない)アプリケーションを移植 しようとしているのであれば、Cygwinの商用ライセンスが必要になるか もしれません。これにはサポート付きのネイティブ Win32 GNUPro 製品 が付属します。この値段は 5 ユーザで $7495 で、GNUPro ツールキッ ト、一年のミッションクリティカルサポート、および Cygwin ライブラ リの商用ライセンスが含まれます。商用使用ライセンスについての詳細 な情報については、info@cygnus.com にお問い合わせください。その 他の質問は全て、このプロジェクトのメーリングリスト gnu-win32@cygnus.com に送ってください。
最初は開発ツール(gcc、gdb、gas など)の強化が行われました。これで Win32 ネイティブオブジェクトファイルの生成、解釈ができるようになりました。
次の仕事はツールを Win NT/95 に移植することでした。これはソース の大部分を Win32 API の文脈で動作するように書き換えることでもで きたでしょう。しかしこれでは、それぞれのツール全てに対して膨大な 時間を費やすことになってしまいます。その代りに私たちは、共有ライ ブラリ(cygwin.dll)を書くという全く異なったアプローチを取ることに しました。これは必要な unix 風の機能で Win32 API に不足している もの(fork、spawn、シグナル、select、ソケットなど) を追加する、と いうライブラリです。私たちはこの新しいインタフェースを Cygwin API と呼んでいます。一旦これが書かれたあとは、unix 上でクロスコ ンパイラを使って、このライブラリをリンクして、動作する Win32 ツー ルをビルドすることが可能になりました。
この時点で私たちは、 Windows 95/NT 上で自分自身を再構築すること ができるネイティブツールの作成、という目標を達成しました(これは よくセルフホスティングと呼ばれます)。どちらの OS にも UNIX の標 準ユーザツール(fileutils, textutils, bash などなど)は付属してい ないので、私たちは Cygwin API で動作する同等の GNU ツールを手に しなければなりませんでした。これらのツールのほとんどは以前はそれ 専用にビルドされていたので、configure スクリプトをクロスコンパイ ルできるように修正しなければなりませんでした。configuration の変 更以外にも、ごく僅かのソースレベルの変更も必要でした。bash が開 発ツールやユーザツールと一緒に正しく動いていると、Windows 95も NT も、GNU configure 機構を通して見ると UNIX の一種のように見え ます。セルフホスティングは beta 17.1 リリース以降で達成されまし た。
1998 中頃に Windows 98 サポートを追加した後、コンパイラに Microsoft ネイティブライブラリのサポートを追加しました。これで Cygwin を使用しない実行形式をコンパイルすることができるようにな ります。これは UNIX エミュレーション層を必要としない Win32 アプ リケーションを開発するためにツールを使いたい方々にとっては重要で す。
一次 FTP サイトは `ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/' です。ミラーサイトがいくつかあります。
Cygwin プロジェクトのメインの WWW ページは `http://sourceware.cygnus.com/cygwin/' です。
ツール固有の情報が含まれているページは `http://www.cygnus.com/pubs/gnupro/' です。
さらなるドキュメントへのリンクはメインの web ページからアクセスできます。
以下のパッケージがフルリリースの中に含まれています。
開発ツール: binutils, bison, byacc, dejagnu, diff, expect, flex, gas, gcc, gdb, itcl, ld, libstdc++, make, patch, tcl, tix, tk
ユーザツール: ash, bash, bzip2, diff, fileutils, findutils, gawk, grep, gzip, m4, sed, shellutils, tar, textutils, time
user tools のリリースは、ユーザのツールのみが含まれます。
これらのツールに対してソースコードが全て利用可能です。これは上記の二つ の部分に別れています。
重要! 古いバージョンの Cygwin ツールを間違って実行してしまわない ように、$PATH 環境変数上から全て削除するのを忘れないでください。
上記の ftp サーバの中のどれかに接続し、最新のリリースが置いてあ るディレクトリに cd します。一次サーバ上では以下の場所になります:
`ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/latest/'
もしあなたが開発ツールと GNU configure 機構を実行するのに必要な プログラムが欲しければ、全バイナリリリース `full.exe' ダウンロードしなければなりません。もしユーザツール(上記のリスト に挙げられているもの)だけに関心があるのであれば、その代わりに `user.exe'をダウンロードしてください。
ネットワークコネクションの信頼性が低いときは、代りに小さな塊に分 割されたバイナリをダウンロードしてください。分割 cdk インストー ラは、`full-split'サブディレクトリからファイルを取得し てください。ダウンロードが終わったら、コマンドプロンプトから以下 のようにして分割ファイルを結合してください。
copy /b xaa + xab + xac + ... + xai + xaj full.exe del xa*.*
ユーザツールに対しても同様の手順で行えます。
インストール実行プログラムがあなたのシステムに入ってしまえば、実 行するだけです。まず最初に、インストーラはこのリリースのインストー ルに必要な一時ファイルを展開する場所を訊いてきます。ほとんどの人 はデフォルトで良いでしょう。
次にインストール場所を選ぶように聞いてきます。デフォルトでは `<system-drive>:\cygnus\cygwin-b20' です。もし 希望があれば、ご自由に他の場所を選んでください。
最後に、ショートカットを追加する Program Files フォルダの名前を 聞いてきます。デフォルトでは、インストーラは `Cygnus Solutions' というフォルダの中に `Cygwin B20' とい うエントリを作成します。このステップが完了すると、ツールのインス トールを行って終了します。
この時点で、スタートメニューの中に "Cygwin B20" があって、それを
選択することができるでしょう。これは全ての特別な環境変数を設定し
て bash シェルを立ち上げてくれます。もしあなたが Windows 95 か
98 を使っていて、"Out of environment space"というエラーメッセー
ジに直面してしまったら、config.sys の中の環境変数領域の量を増や
す必要があります。そしてもう一度試してください。C:
がシステムドライブであれば、shell=C:\command.com /e:4096
/p という行を追加することでこの細工を行ってくれるはずです。
この後にはあと2つやるべきことが残っています。第一に、mkdir
-p /tmp とタイプして、この場所に一時ファイル用のディレク
トリを必要とするプログラムのために、その存在を保証しておく必要が
あります。
第二に、もしあなたが全ディストリビューション (`full.exe')をインストールしたのならば、さまざまなプロ グラムが`/bin/sh' を見つけられるようになっている必要が あります。`mkdir -p /bin' を行って、 `sh.exe' のコピーをそこに置いてください。古いバージョンのものがあったら削 除してください。`mount' ユーティリティを使って、どのド ライブが`/' としてマウントされるかを選ぶことができます。 `mount' についてのより詳しい情報は Frequently Asked Questions (FAQ) を参照してください。
もしこのツールをアンインストールしたいと思ったときには、コントロールパ ネルの「アプリケーションの追加と削除」("Add/Remove Programs")によって できるでしょう。
このリリースに対応するソースコードをダウンロードする前に、上記の 最新リリースのツール(全リリースかまたはユーザツールのみのどちら か)をインストールしなければなりません。
ソースコードの住処となるディレクトリを作成し、そこに `cd' し ます。
上記の ftp サーバの中のどれかに接続し、最新のリリースが置いてあ るディレクトリに cd します。一次サーバ上では以下になります:
`ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/latest/'.
ユーザツールのソースコードが必要ならば、 `user-src-split' サブディレクトリに`cd' し、そ こにあるファイルをダウンロードしてください。開発ツールのソースが 必要なら、`dev-src-split' サブディレクトリに `cd' して、そこにあるファイルをダウンロードしてください。
Windows のコマンドシェルに戻ります。ユーザツールのソースの場合:
copy /b xba + xbb + xbc + xbd + xbe + xbf + xbg user-src.tar.bz2 del xb*.* bunzip2 user-src.tar.bz2 tar xvf user-src.tar
開発ツールのソースの場合:
copy /b xca + xcb + xcc + xcd + ... + xck + xcl dev-src.tar.bz2 del xc*.* bunzip2 dev-src.tar.bz2 tar xvf dev-src.tar
どちらも `src' というディレクトリの中に展開します。
これで終わりでしょう…。
ここから Cygwin ライブラリでサポートされている関数をリストするド キュメントの始まりです。
全ての POSIX.1/1996 と ANSI C 関数はこのファイルでリストされてい ます。POSIX.1/1990 関数はほとんど全部 Cygwin に含まれていますが、 POSIX.1/1996 関数の多くは含まれていない(少なくとも「まだ」ね!)と いうことに注意してください。付加的な UNIX 互換関数や拡張 libc/libm 関数は Cygwin で提供されていますが、リストされているも のとまだリストされてないものがあります。
ここにリストされていない関数が実装されているかどうかは、ソースの winsup/cygwin.din ファイルにその関数があるかどうかをチェックして ください。さらに、その関数がスタブでないことを確認するために、対 応するソースコードを読んでおいた方が良いでしょう。最後に、 libc/libm の関数は(ここにリストされていない拡張関数も含めて) newlib の texinfo ドキュメントに記述されています。
特に断り書きがなければ、Windows 95 と NT のどちらでも実装されて います。関連する標準への参照も(もしあれば)含まれています。 "cygwin_" で始まる関数は Cygwin 特有の関数です。
Cygwin プロジェクトのメインの WWW ページには、非常にたくさんのリ ンクがあります: `http://sourceware.cygnus.com/cygwin/' 最低限 Release Notes とメインの WWW ページは目を通しておきましょ う。何か書いてあるかも知れません。
ツール特有のドキュメントはここにあります: `http://www.cygnus.com/pubs/gnupro/'
以下にメールを送ってください。
gnu-win32-request@cygnus.com
メッセージの本文は以下のように書いてください。
subscribe gnu-win32 <your-email-address-here>
ここで <your-email-address-here> はあなたのメールアドレスです。
メーリングリストを脱会するには以下にメールを送ります。
gnu-win32-request@cygnus.com
脱会する時はメッセージの本文は以下のように書いてください。
unsubscribe gnu-win32 <your-email-address-here>
mail はメーリングリストに配送されるまでに時折一、二日かかるとき があるので、脱会の要求が行われてからあなたへのメールの受信が止ま るまで、一、二日のタイムラグが生じることがよくあるのを心に留めて おいてください。
メーリングリストの過去のアーカイブは以下にあります。
`http://www.cygnus.com/ml/gnu-win32/'
それはおそらく、あなたの質問はすでに FAQ の中にあるからです。また、お そらく誰もあなたの質問に答える時間がないのでしょう。あるいは、誰も答え を知らないのかも…。
もし "The decompression of %s failed. There may not be enough free disk space in the TEMP directory." というエラーメッセージが 出ている場合は以下を読み進んでください。
InstallShield には、TEMP ディレクトリにある数以上のファイルが存 在すると失敗する、というバグがあります。もし TEMP ディレクトリに、 InstallShield が作ろうとしているファイルと同じ名前のファイル(お そらく過去の別の InstallShield インストール作業でのファイル)が存 在して、何らかの理由で上書きできなかった場合にもこのエラーが出ま す。これは InstallShield の将来のリリースでは修正されるかも知れ ません。
それまでは、TEMP ディレクトリを全部空にしてしまうのが良いです。 これでファイル名の衝突がなくなりますし、"too many files" の問題 も同様に解決します。
多くの Unix のツール(bash、byacc など)は /tmp が常に存在するもの と思っています。これは Win32 の国では保証されていません。この問 題を避けるには、/tmp を作るか、適当なディレクトリを選んで、/tmp にマウントしてください。
ちゃんと /tmp を作りました? bash は /tmp ディレクトリが見つから ないときは警告を表示します。
/etc を正しく設定するには(そうすると例えば "ls -l" がユーザ情報 を正しく表示するようになる)、もしあなたが NT を使っているのなら (NTFS ファイルシステムの方が良い)、単に / としてマウントされてい るファイルシステムに/etc ディレクトリを作り、そして mkpasswd と mkgroup を使って、/etc/passwd と /etc/group をそれぞれ作成してく ださい。Windows 95/98 の Win32 API は不完全なので、もしあなたが Windows 95/98 を使っているのなら残念でした。
ほとんどの場合、これは自分自身がパスに含まれていないからです。bashを実 行する前に、bash が置いてあるディレクトリがあなたのパスに含まれている かどうか確認してください。
また、/bin/sh.exe が正しく存在することも確認してく
ださい。シェルスクリプトを実行しようとして、それが間違いなく存在
しているにも関わらず `no such file or directory' のようなエラー
が出た場合には、おそらくbash が /bin/sh を見つけら
ないのが問題なのです。
.bashrc は HOME 環境変数で指定されるホームディレクトリから読み込 まれます。HOME が設定されていなければ c:\ が使われます。ですから、 HOME を正しく設定するか、.bashrc を c:\ に移動してください。
Cygwin はファイル名やパス名の中のスペースはサポートしません。こ れは、このライブラリを使ったユーティリティは動かないかもしれない、 ということです。それは UNIX では普通はファイルにはスペースは含ま れないからです。もしあなたがこの問題に引っかかってしまったら、そ のユーティリティを修正するか、 Cygwin ツールでスペースのあるファ イル名を使うのをやめるかするしかありません。
Cygwin は MS Explorer ショートカット (*.lnk ファイル) はまだたど りません。ショートカットを通常のファイルとみなすので、その中に "cd" できないのです。
中には今のシンボリックリンク機構をショートカットで置き換えること を提案する人もいます。こうすることの一番の問題は、Cygwin パスの シンボリックリンクを使った .LNK ファイルは、Explorer などのよう な非 Cygwin の Win32 ネイティブアプリケーションにとっては、正し いかもしれないし、正しくないかもしれないということです。
find が Cygwin ツールに付属しているものを使っていること、つまり 間違って Win32 の find コマンドを拾ってしまっていないことを確認 してください。正しいものを使っていることの確認は、bash から"type find" することで確かめられます。
明らかな理由として、私たちは全てのツールを Cygwin ツールとして動 作するように移植し、バイナリ配布を提供し保守を行うことは実行不可 能です。その代りに Cygnus はその労力を、Cygwin ライブラリと、核 となる開発ツールに集中するべきであると考えています。man コマンド は、満足できる程度に動くものができれば、それも含めるようになるで しょう。
他の移植されたツールは、正式なリリースに追加修正されているはずなので、 そのツール用のソースから素直にコンパイルできます。もしそれが不可能な場 合は、他の誰か(理由によってはもしかしたら Cygnus)が diff を保守し、ftp できるところに置くでしょう。おそらくそのようなツールは Cygwin の Web サイト上でリストを作ることができるでしょう…。
less ページャのバイナリは、20.1 リリースではじめて利用できるよう になりました。アップグレードすれば手にはいるでしょう。また、ネッ トワーク上のさまざまな場所から ftp することができます。詳しくは メイリングリストのアーカイブを検索してください。
more ページャを探しているのであれば、その代わりに less ページャ を使いましょう。詳しくはこの一つ前の質問と答えを見てください。
which コマンドは含まれていないのですが、ほとんど同様のことを行う bash のビルトインコマンド "type" を使うことができます。
最もよい方法は、"mount" コマンドを使ってドライブ文字をマウントし、 そのドライブを一つのスラッシュで参照することです。
bash$ mkdir /c bash$ mount c:/ /c bash$ ls /c ....
これはファイルを開く時に、逐語的な置き換えによって行われます。つ
まり、上記のようなマウントにおいて ls /c/bar を行お
うとすると、内部的な仕掛けがそれを ls c:/bar に変え
るのです。
mount は一度しか必要としないということは憶えておいてください。こ の置き換えはレジストリの中に保持されるので、マウントはほぼ無限に 有効になります。umount (あるいはレジストリエディタ) によってのみ、 これを削除することができます。
mount の '-b' オプションは、そのマウントポイントを、テキストファ イルとバイナリファイルを等価に扱うバイナイモードでマウントします。 これは、open 時にバイナリフラグをつけていないような、正しく移植 されていない UNIX プログラムに対してのみ必要となるはずです。
beta 16 リリース以降より、mount コマンドを使わずに
他のドライブにアクセスする特別な方法もサポートしています。このサ
ポートは将来の Cygwin リリースでは消えるかもしれません。それはこ
の機構は UNC パス名のサポートと衝突してしまうからです(一文字のマ
シン名が正しく動作しない)。
f: ドライブ上で "ls" を行うには、以下を実行してください。
bash$ ls //f/
UNC パスにも標準の方法でアクセスできるということに気をつけてくだ さい。上で述べた文字ドライブへのショートカットのおかげで、UNC パ スのマシン名は一文字よりも長くなくてはなりません。
これは普通、すでにマウントされている場所にさらにマウントしようと しているという意味です。例えば、c: が '/' にマウントされていると して、d: を同じようにマウントしようとするとこのエラーメッセージ が出ます。まず古いものを "umount" して、それから新しいものを "mount" すればシアワセになれるでしょう。
もし '/' を umount しようとしてこのメッセージが出たのなら、
regedit.exe を実行して、
HKEY_CURRENT_USER/Software/Cygnus Solutions/CYGWIN.DLL
setup/<version> の下に保持されているマウントポイントの中
から、 '/' マウントのための "native" キーを変更する必要があるか
もしれません。ここで <version> は、Cygwin ライブラリに関
連付けされているレジストリバージョンの最新のものです。
私たちは、開発中は Samba の動いている Unix マシンと NT/Windows 95/98 マシンの両方を使っています。また、 Unix 上のクロスコンパイ ラを使ってビルドして、バイナリとソースを Windows システムにコピー したり、あるいは単に Samba でマウントされたパーティション上で直 接いじくりまわしたりしています。NT/Windows 9x のデュアルブートマ シン上では、Windows 9x 上からもアクセスできるように通常 FAT ファ イルシステムを使用しています。
いくつかの Unix プログラムでは、同じ綴りのファイル名を大文字、小文字を
違えて使い分けられることができると期待しています。重大な例として perl
のコンフィグレーションスクリプトがあり、これは Makefile
と makefile を必要とします。WIN32 はただ大文字、小文字だ
けが違うこれらのファイルを区別できず、コンフィグレーションは失敗します。
beta 16 以前のリリースでは、mount にはファイル名を変更して大文字、 小文字ファイル名を使い分けられる、特別な mixed case オプションが ありました。私たちはこのサポートを、beta16 のパス操作コードを書 き直すときに、削除することに決めました。
ファイル名に com1、lpt1、aux は、ファイル名の基幹部分としても、拡張子
部分としても使えません。もし使ってしまうと面倒が起きるでしょう。Unixプ
ログラムはこれらの名前を避けるような楽しいことはしてくれません。例えば、
perl のディストリビューションの中には aux.sh というファイ
ルがあります。perl のコンフィグレーションでは aux.sh ファ
イルが存在することを確認しようとしますが、`aux' という魔法の文字が含ま
れているファイルを操作しようとしてハングしてしまうでしょう。
もし何かがおかしくなって、何らかの理由でツールが帰ってこなくなっ てしまったら(aux.sh というファイルを読んでみると簡単に止められま す)、まず ^C を叩いてみて、bash あるいは cmd プロンプトに戻って みてください。
もし別のシェルを起動してもアプリケーションが動かなかったのなら、 暴走したプロセスがまだどこかで動いてると思った方がいいです。タス クマネージャー、pview、あるいは同様のユーティリティを使ってその プロセスを殺してください。
そして、もし全てが失敗してしまっても、リセットボタン・電源スイッ チはいつでもあります。これは Windows NT では必要になることはない はずですが。
どうして cpp.exe、cc1.exe などは bin ディレクトリにはないの?
どうして lib や include ディレクトリが一つじゃないの?
H-i586-cygwin32\lib\gcc-lib\...\egcs-2.91.57\include x86-cygwin32\include x86-cygwin32\H-i586-cygwin32\i586-cygwin32\include
この方法では、違ったホスト、ターゲット間での複数のリリースが、同じツリー の中で共存できます。 H-i586-cygwin32 は、i586-cygwin32 によってホスト されるという意味で、全てのホストで共有される共通ファイルはトップレベル のディレクトリにあり、ターゲット毎のファイルは H-i586-cygwin32/i586-cygwin32 以下にある、といった具合です。
もし ppc NT マシンと x86 NT マシンとでファイルを共有するサーバが あったとすれば、H-i586-cygwin32 と H-powerpcle-cygwin32 の両方の ディレクトリを持ち、トップレベルにある共通のファイルはそれぞれの マシン毎に重複して持つことはありません。もし i586-cygwin32 と mips-elf 間のクロスコンパイラでビルド、インストールした場合には、 H-i586-cygwin32/mips-elf というターゲット依存ファイルの入ったディ レクトリができて、mips-elf- のプレフィックスがついたバイナリがい くつか H-i586-cygwin32/bin にできるでしょう。
通常、リリースを識別するためにさらに上のレベルのディレクトリを作ります。 もし 複数の Cygwin リリースが別々の DLL バージョンとして共存する場合 には、以下のようなディレクトリができるでしょう。
cygnus/b19/H-i586-cygwin32 cygnus/cygwin-b20/H-i586-cygwin32 ...
どちらにしろ、これはディレクトリ構造をさらに複雑にさせますが、さらに複 雑なインストールを行う人々のためには価値があることです。
ある方の報告では、 NT 用(他のも?)の McAfee VirusScan は Cygwin とは相容れない、とのことです。これは cygwin.dll の中で新しくロー ドされた共有メモリをスキャンしようとするためで、そのおかげで fork() が失敗し、多くのツールをめちゃくちゃにしてしまいます。
以下のコードを初期化ファイルに書いて試してみてください:
(load "comint")
(fset 'original-comint-exec-1 (symbol-function 'comint-exec-1))
(defun comint-exec-1 (name buffer command switches)
(let ((binary-process-input t)
(binary-process-output nil))
(original-comint-exec-1 name buffer command switches)))
[訳注]: Mule for W32 では上記の代りに、以下の行を .emacs に書い てみてください(Meadow では特に設定はなくても大丈夫だと思います)。
(define-program-coding-system nil ".*bash.*" '(*sjis*unix . *sjis*unix))
ディスクスペースとダウンロード時間を節約するために、man/info ファ イルをバイナリインストールと一緒に提供するのは止めました。これは まだ man ページ、info リーダを提供していないからです。どちらのド キュメントもプロジェクトの ftp サイトから tar ファイルで利用可能 です。あるいは WWW でオンラインドキュメントを見てください。
これは混乱を招く警告文で、将来のバージョンでは言い回しを変えるで しょう。実際には、cygcheck は通常 cpp を *見つけてはいけません*。 もし見つけたとしたら、それが問題になるかもしれません(たとえば Borland の cpp を見つけるかも知れません。これは問題を引き起こし ます)。
"Out of queue slots!" は通常、削除する権限のないファイル(パーミッ ションがない、排他的に使用中である、など)をたくさん消そうとした ときに出ます。何が起こるかというと、Cygwin はこれらのファイルを 後で削除できるようになるだろうという仮定のもとに待ち行列に入れて しまうのです。そのファイルのパーミッションが後で変更されたとする と、そのファイルは要求通りに削除されるでしょう。しかし、アクセス できないファイルを削除する要求があまりにたくさん来るとキューが溢 れてしまって、ご質問のメッセージが出てしまうのです。普通はすぐに chmod する、ファイルを閉じる、などによって対処することができます。 (Larry Hall 氏に説明をいただきました。ありがとうございます)
シンボリックリンクは "system" ファイル属性として印をつけられます。 samba はこの属性をサポートしていません。
Win32 API 関数の GetFreeDiskSpace にはバグがあって、2 GB 以上の 大きさのディスクに対して間違った値を返してきます。たぶんこれが問 題なんじゃないかな?
screen は UNIX ドメインソケットか fifo のどちらかを必要とします。 どちらも Cygwin ではまだ実装されていません。
Unix スタイルの API を提供する C のライブラリがあります。アプリケーショ ンはそれとリンクされて…、ほら、Windows 上で動きました。
目標は、あなたのアプリケーションを Windows で動かすために必要な全ての 行儀の悪いやつを、C ライブラリに追加することです。そうすればあなたのア プリケーションは、ソースレベルでの変更無しに、Unix と Windows で動くで しょう。
この C ライブラリは DLL 内にあり、基本的なアプリケーションはとて も小さくなります。またこれにより、DLL の変更時にバックワードコン パチビリティを残すことで、Win32/Unix 翻訳層のアップグレートを比 較的容易にアップグレードできます。
Cygwin の良き概要として、1998 年 8 月 の第 2 回 Usenix NT シンポ ジウムに関連して Usenix Association から発行された Cygnus の論文 を読んでみるとよいかもしれません。これは Cygwin プロジェクトの WWW サイトから html 形式で入手可能です。
はい。Cygwin ライブラリの内部的に何か関心を惹くことが起った時に 作られます(どれだけ進んだかにもよりますが、通常、おおまかには週 間ベースで)。これは主にこのプロジェクトにコードを寄附しようとす る方々のためのものです。あなたがバグバグなスナップショットの問題 をデバッグするのが嬉しくなかったら、これは避けて本当のリリースを 待ってください。このスナップショットは ftp.cygnus.com の /pub/noer/winsup-snapshot/ から取得できます。
まずその背景からはじめましょう。
UNIX においては、ファイルはファイルであり、そのファイルの内容は、 プログラム/プログラマ/ユーザが「入れろ」といったものを何でも入れ ます。Windows においては、やはりファイルはファイルですが、そのファ イルの内容はプログラム/プログラマ/ユーザだけでなく、ファイルの処 理モードにも依存します。
テキストモードで処理を行われている時は、ある種のデータは特別な扱 いをうけます。\n (改行) がファイルに書かれると、その前に \r (復 改)がぶらさげられて、例えば printf("Hello\n") としたとすると、実 際に得られるのは "Hello\r\n" となります。この組み合わせを読み込 んだときは、\r は削除されて、read によって返されるバイト数は実際 に読み込まれた数より 1 小さくなります。この結果として ftell() や fseek() に依存しているブログラムに混乱を引き起こすことがあります。 ファイルの読み込み中に Ctrl-Z に出会うと、たとえそれが本当のファ イルの終端でなくても、End Of File のフラグを設定します。
Cygwin の目的の一つは、Cygwin で移植された UNIX プログラムと一般 の Windows プログラムとを簡単に混在できるようにすることです。こ の結果として Cygwin は、普通の Windows のように、ファイルをテキ ストモードでオープンします。附属のツールでは、バイナリを扱うツー ル(objdump など)は、unix 風のバイナリモードで操作し、テキストファ イルを扱うツール(bash など)はテキストモードで操作します。
マウントのオプションや CYGWIN 環境変数の設定によって、デフォルト の処理モードをグローバルにバイナリモードに設定しよう、という考え を押し進める人もいます。しかしこれは別の問題を生み出します。バイ ナリモードでは、プログラムはファイルの中のデータを、\r も含めて 全て受け取ります。プログラムはこれらの属性を特別扱いすることはな くなるので、特にスクリプトや起動時のリソースファイルといったテキ ストファイルから \r を自分で取り除く必要があるでしょう。これは移 植者の「責任逃れ」であり、移植者の代わりにユーザが \r の面倒をみ なければならなくなってしまいます。
移植者が、open/fopen 関数に適切なファイル処理モードを与えるよう
にソースコードを修正する方がずっと簡単です。テキストファイルはテ
キストとして扱い、バイナリファイルはバイナリとして扱うのです。さ
らにはっきり言えば、open 呼び出しの二番目の引数に
O_BINARY を追加するか、fopen 呼び出し
の二番目の引数に "b" を追加することによってバイナリ
モードを選ぶことができます。あるいは setmode (fd,
O_BINARY) を呼び出すことでもできます。
この open/fopen へのスイッチは ANSI で定義されているので、これら はほとんどの種類の UNIX において存在する、ということも憶えておい てください。 UNIX ではこれらのスイッチは無意味であるので、 open/fopen はそれを単に無視するだけです。
また、lseek はバイナリモードでのみ動作する、という
ことにも注意してください。
(メーリングリストでの Earnie Boyd 氏 <earnie_boyd@yahoo.com> のメールを基に説明しました)
まだですが、もうすぐそうなります。
Cygwin がマルチスレッドセーフでない理由は:
1) 新 lib (libc/libm) が再入可(reentrant)ではない(ほとんどそうで はあるけども)。これを修正するか、あるいは再入可な libc/libm に切 り替えなければならないでしょう。
2) Cygwin は共有メモリ領域をロックする(これは複数プロセスによっ て共有されている)が、プロセス毎のデータはロックされない。従って、 マルチスレッドアプリケーションの異なったスレッドがそれにアクセス して、厄介な競合状態を引き起こすでしょう。
Mingw パッケージ(gcc に -mno-cygwin を付けて起動したときにできる ものです) はマルチスレッドセーフです。それは Cygwin や 新 lib を 使わない構成になっているからです。代わりにほとんどの部分がマルチ スレッドセーフである Microsoft のライブラリを使います。ですから、 プログラマがマルチスレッドセーフでないMicrosoft API さえ避ければ (ほとんどは大丈夫です)大丈夫のはずです。
Windows 9x: n. 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.
(訳注: 参考までに拙訳を以下に載せますが、やっぱり原文の方が面白 いですよね)
Windows 9x: 名詞。 1ビットたりとも競争力のない2ビット程度の会社が作った、4ビットマ イクロプロセッサ用コードがもとになっている8ビットオペレーティン グシステムに対する16ビットパッチのための32ビット拡張グラフィック シェル。
でも真面目に、Windows 9x にはほとんどのセキュリティ関連の関数は 無く、他にもいくつか Win32 API の一バージョンとして足りないもの があります。Win 9x において何がサポートされてないかについての情 報は、calls.texinfo を参照してください。
Cygwin の fork() は、本質的には `non-copy on write' 方式(古い Unix のバージョンで取られていた方式)の fork() のように動作します。 このため、多少遅いです。多くの場合においては、できる限り spawn の類の呼び出しは使わない方が良いです。
fork は beta 18 ではこのように動作します。
親は、子のための Cygwin プロセステーブルの領域を初期化します。親 は Win32 の CreateProcess に自分が起動されたときと同じパスを与え て、中断した子を生成します。親は setjmp を呼び出してコンテキスト を保存し、このポインタを Cygwin の共有メモリ領域にセットします (この領域は全ての Cygwin タスク間で共有されてます)。親は、子の .data と .bss サブセクションを、自分のアドレス空間から中断した子 のアドレス空間へとコピーして埋めます。そして親はその子を開始させ ます。親は mutex によって、子が安全な地点に来るまで待ちます。子 は開始して fork されたのがわかったら、保存されたジャンプバッファ を使って longjump します。子は親の待っている mutexをセットし、そ して親がスタックとヒープを埋めてくれるまで、別の mutex 上でブロッ クします。親は子が安全な領域に入ったことを知って、スタックとヒー プを自分のものから子の中へコピーし、子が待っている mutex を解放 して、fork 呼び出しからリターンします。子はブロックしている mutex から起きて、共有領域を通して渡された mmap 領域を再作成し、 fork 自身からリターンします。
CYGWIN.DLL を使うアプリケーションが起動して、その時 PID
環境変数が見つからない場合は、これは DOS スタイルのコマンドプロンプト
から起動されたものとみなします。これはまず間違いはありません。というのも、
他のツール(bash も含めて)は起動時に新しいプロセスの PID がいくつである
かを知るために PID を設定するからです。
DLL が、これは DOS スタイルのプロンプトから来たと思ったときは、与えら
れたコマンドラインに対してファイル名の展開を実行します。これはつまり、
DOS から LS *.EXE とタイプした場合、あなたが期待している
であろう動作を行う、ということです。
注意: ファイル名展開はmallocを使用します。もしあなたのア
プリケーションが malloc を定義しているのなら、それが使用
されます。これはあなたにとってとんでもないことかもしれません(訳
注: ユーザ定義 malloc の項参照のこと)。
CYGWIN.DLL はマジックヘッダを持つリンクファイルを生成します。ど こかにリンクされているファイルまたはディレクトリをオープンすると、 そのマジックヘッダに書かれてあるファイルまたはディレクトリをオー プンします。ファイルを参照するたびに毎回、シンボリックリンクの状 態をチェックするためにファイルをオープンしたくはないので、Cygwin はシステム属性でシンボリックリンクの印をつけます。システム属性の ついていないファイルはチェックされません。リモートの samba ファ イルシステムはシステム属性をサポートしていないので、ネットワーク ドライブではシンボリックリンクは動作しません。
ファイルに対して unix スタイルの属性ビットを操作するときは、ライブラリ は WIN32 API で提供されていないいくつかの情報を埋めなくてはなりません。
これはファイル名が .exe か .bat であれば実行可能と判断しますし、 またファイルの先頭に "#!" の文字を持つものも同様です。
Cygwin はマルチユーザ環境では安全ではありません。例えば普通のユー ザがログインするような環境で、"inetd" のようなデーモンを管理者権 限でずっと走らせたり、あるいは誰かがコンソールからログインしてい る間他のユーザがリモートでログインしたりすると、ある cygwinクラ イアントは他のクライアントをだましてコードを実行させることができ ます。この方法であるユーザは、そのマシンで動作している他の cygwin プログラムの権限を得ることができてしまいます。これは cygwin は全てのプロセスからアクセス可能な共有状態を持つからです。
Tim Newsham (newsham@lava.net) 氏から説明をいただきました。あり がとうございます)
Cygwin におけるネットワークサポートは Unix API の提供を想定して おり、Winsock API ではありません。
API 上では同じ名前の関数でも、意味の違う関数が存在します。
例えば、Unix の select システムコールは標準ファイルハンドルとソケット のハンドルに対して待つことができますが、winsock の select コールはソケッ トのみです。このため、cygwin.dll はさまざまな winsock/win32 関数に、無 理矢理 Unix select と同じようなことをさせるために、裏でかなり汚いこと をやっています。
もしすでに Winsock を使っているアプリケーションを移植しようとし ているのであれば、 Cygwin のネットワークサポートを使用するには間 違っています。
しかしそれでもネイティブの Winsock も Cygwin も使うことはできま す。cygwin.dll が export している関数は 'cygwin_<name>' という名前です。 たくさんのマクロ定義が、標準の Unix 名から DLL で export されている名前への関連付けを行っているのです。 include/netdb.h を覗いてみてください。
..etc.. void cygwin_setprotoent (int); void cygwin_setservent (int); void cygwin_setrpcent (int); ..etc.. #ifndef __INSIDE_CYGWIN_NET__ #define endprotoent cygwin_endprotoent #define endservent cygwin_endservent #define endrpcent cygwin_endrpcent ..etc..
これは標準 Unix ヘッダファイルを include すると Unix->cygwin のマッピングが行われる、というアイデアです。これを使った場合、 libwinsock.a をリンクする必要はありません。ネットワークに必要な 全てのものは DLL 内にあります。
mywinsock.h ファイルは、標準 winsock.h をハックしたもので、標準 Unix API と衝突するビット値や他のヘッダで定義されていたりするものを削除した ものです。 例えば、mywinsock.h においては struct hostent の定義は削除 されています。これは Unix マシンでは netdb の中にあるものだからです。 これをあなたのアプリケーションで使うのは良いことではありません。
b19 リリースでは、この情報はちょっと古くなっています。
そのままの Win32 の winsock を使うには、ソースファイルの先頭で #define Win32_Winsock と #include "windows.h" とするのが必要なだ けです。あと libwsock32.a とリンクするために、コンパイラのコマン ドラインに -lwsock32 を付け加える必要があるでしょう。
cygwin.dll には新しい Cygwin のリリースが作成される度に大きくな るメジャーバージョン番号があります。これはリリースの名前に対応し ています(例えば、beta 19 のメジャー番号は "19" です)。また、 cygwin.dll にはマイナーバージョン番号もあります。もしすでに出さ れているリリースに対して、ライブラリが更新されてリリースされた場 合、マイナー番号が増えます。
Cygwin API のメジャー・マイナー番号というものもあります。このメ ジャー番号は、API の互換性が無くなる重大な変更が行なわれるにつれ て変化します。以前のメジャー番号の DLL とリンクされた実行ファイ ルは、最新の DLL とは互換性が無くなるでしょう。マイナー番号は、 意味のある API の追加や変更に対して変化します。これは古い実行ファ イルを壊すことはしませんが、再コンパイルしたものが必要になること があります。
そして、共有メモリ領域互換バージョン番号があります。これは共有メ モリ領域やその他の名前付き共有 mutex、セマフォ、などに対して互換 性のない変更が行われたときに変化します。
最後に、Cygwin32 がレジストリの使い方に互換性のない変更が行われ たときのみに変更されるレジストリバージョン番号があります。最後に、 マウントテーブル配置のレジストリに対して互換性のない変更が行われ たときに変化する、マウントポイントレジストリバージョン番号があり ます。これはbeta 16 以降 "B15.0" です。
_timezone の値を参照する前に、tzset() を明示的に呼び出しています か? していないのであれば、これを呼び出しておかなくてはなりません。
"gcc: installation problem, cannot exec `cpp': No such file or directory" というエラーが出た場合は、GCC_EXEC_PREFIX という環境 変数が正しく設定されていません。現在のリリースでは GCC_EXEC_PREFIX を設定する必要はありません。インストール場所に関 わらず cpp を見つけることができるようになっているはずです。しか しこれに間違った値を設定してしまうと、やはりそのメッセージが出て しまうでしょう。
もしそういう意味の警告メッセージが出てしまったら、BISONLIB 環境
変数を設定する必要があります。この値は bison.simple と
bison.hairy がインストールされているディレクトリです。これはバイ
ナリディストリビューションのトップレベルの share ディレク
トリまでを含んだパスになるはずです。たとえば、あるシステムでは
C:/cygnus/cygwin-b20/share に設定することになるでしょう。
beta 19 以降では、 make は win32 モードがデフォルトになっていま す。これはファイル名中にバックスラッシュが使えて、 cmd.exe/command.com をサブシェルとして使います。このモードではい ろいろ制限があり、特にエスケープ文字が許されません。こういう理由 で、普通の UNIX のMakefile で make を行うには、 MAKE_MODE 環境変 数を UNIX に設定しなければなりません。以下がその詳細情報です。
MAKE_MODE は、Win32 ネイティブの make モード(デフォルト)か、UNIX make のように振る舞う UNIX モードかを切り替えます。UNIX モードで はWin32 形式のパス指定が許されますが、パス区切り文字としては前向 きスラッシュのみしか含むことはできません。パスリストの区切り文字 は UNIX モードではコロンになります。
Win32 モードではパス区切り文字は / と \ のどちらでも受付けます。 つまり UNIX 風の \ によるエスケープを行なうことはできません。ま た、Win32 モードは cmd.exe/command.com をサブシェルとして使いま す。つまり "copy" や "del" (とその他のシェル組み込みコマンド)が 動作します。Win32 モードではパスリスト区切り文字はセミコロンです。 nmake 風の make を使いたい方々はこのモードを使うとよいかもしれま せんが、しかしこのモードでは、UNIX の Makefile でコンパイルでき ると期待してはいけません。そういうわけで b19 インストールのデフォ ルトでは MAKE_MODE を UNIX に設定しています。
ソースの中に空の main() 関数を追加して試してみてください。
実はとっても簡単です。Cygwin ツールが必要とするのは、あなたが使 おうとしている Win32 API 関数のインポートライブラリを明示的にリ ンクすることだけです。例外は kernel32 で、これは自動的にリンクさ れます(これはスタートアップやビルトインのコードがそれを使うから です)。
例えば、グラフィック関数(GDI)を使うには gdi32 をこのようにリンク しなければなりません:
gcc -o foo.exe foo.o bar.o -lgdi32
あるいは(コンパイルとリンクを同時に行う):
gcc -o foo.exe foo.c bar.c -lgdi32
以下のライブラリがこの方法で利用可能です。
advapi32 largeint ole32 scrnsave vfw32 cap lz32 oleaut32 shell32 win32spl comctl32 mapi32 oledlg snmp winmm comdlg32 mfcuia32 olepro32 svrapi winserve ctl3d32 mgmtapi opengl32 tapi32 winspool dlcapi mpr penwin32 th32 winstrm gdi32 msacm32 pkpd32 thunk32 wow32 glaux nddeapi rasapi32 url wsock32 glu32 netapi32 rpcdce4 user32 wst icmp odbc32 rpcndr uuid imm32 odbccp32 rpcns4 vdmdbg kernel32 oldnames rpcrt4 version
通常のセットアップでは、 -mwindows オプションをコマンドラインに 使うことで、user32、gdi32、IIRC、comdlg32 などを含む基本的なライ ブラリ群を含めることができます(そしてプログラムを console プログ ラムではなく、GUI プログラムにする)。
ただし、ld を直接起動しているのでない限り、-lkernel32 をリンク行 に含めてはいけないことに注意してください。リンク行に同じインポー トライブラリを2度含めてはいけません。最後に、インポートライブラ リをリンク行の最後か、少なくともそれを参照する全てのオブジェクト ファイル、スタティックライブラリの後ろに置くのが良い方法です。
最初の2つは、インポートライブラリが2回参照されるときのリンカが持 つ問題に関連しています(少なくとも b18 以降)。テーブルがぐちゃぐ ちゃになって、プログラムが無作為にクラッシュしてしまいます。最後 の点は、gcc がコマンドライン上のファイルのリストを順番に処理し、 ライブラリを参照しているファイルの後ろにあるライブラリに対しての み参照の解決を行うという事実に関係があります。
gcc の -mno-cygwin フラグによって、gcc は Cygwin の代わりに標準 Microsoft DLL をリンクするようになります。これは UNIX エミュレー ション層を必要としないネイティブ Windows プログラムのためのもの です。
コンパイル時のデフォルトは、コンソールアプリケーションを生成する ようになっています。GUI プログラムを書いているのであれば、上記で 説明したように -mwindows オプションをつけてコンパイルするか、 "-Wl,--subsystem,windows" を GCC のコマンドラインに追加するかし てください。
この問題は通常、誰かがテキストエディタで Makefile のタブをスペー スで置き換えた結果として発生します。コマンド行はタブで始まらなく てはなりません。
`Microsoft Open Tools License agreement' のサブセクション 2.d.f には、「エンドユーザに対して再配布可能の形でさらに再配布すること は認められない」、とあるようです。私たちはこれを、私たちがあなた にあげることはできるけれども、それをあなたが他の誰かにあげること はできない、という意味だと取りました。これは Cygnus としては賛成 できないことです。ですが幸運にも、私たちはほぼ完璧な、独自の Win32 ヘッダを持っています。
あるいは
この方法で、MSVC(とその他多くのランタイムライブラリ)を Cygwin 開 発ツールで使うことができます。
これは大変な作業(丸半日とか)ですが、それでも問題のランタイムライ ブラリを仕様から書き直すよりはまだましでしょう…。
(Jacob Navia (root@jacob.remcomp.fr) 氏から説明をいただきました。 ありがとうございます)
ソースが /src にあり、/obj ディレクトリでビルドし、/install にツールを インストールしたい、仮定します。
bash cd /obj /src/configure --prefix=/install -v > configure.log 2>&1 make > make.log 2>&1 make install > install.log 2>&1
残念ながら、これは難しいです。Microsoft が PowerPC 版 NT の開発 を止めてしまって以来(1996 後半)ずっとビルドされていません。例外 処理やシグナルサポートのセマンティックス、引数が x86 版では修正 されていて、PPC 用には更新されていません。したがって PPC 特有の サポートを書き直す必要があるでしょう。他にどんな非互換性があるか わかっていません。もしこれを修正してくださるなら、ぜひ私たちにパッ チを送ってください!
Alpha 版 NT 用には移植されておらず、現時点では移植する予定もあり ません。どなたか Alpha 版 NT をサポートする修正を寄附していただ けると嬉しいです。
gcc にヒープ・スタックサイズのリンクオプションを渡してください。 foo.exe をヒープサイズ 1024、スタックサイズ 4096 で作成するには、 gcc をこのように起動してください:
gcc -Wl,--heap,1024,--stack,4096 -o foo foo.c
objdump -p がこの情報を提供してくれます。
Cygwin プロジェクトの web ページ (http://sourceware.cygnus.com/cygwin/)上に、この手順を説明した文 書があります。
gdb で *0x401000 にブレークポイントを設定して、当該プログラムを 実行してください。
以下に示す 5つのコマンドをこの順序で実行しなければなりません:
$(LD) -s --base-file BASEFILE --dll -o DLLNAME OBJS LIBS -e ENTRY
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \
--base-file BASEFILE --output-exp EXPFILE
$(LD) -s --base-file BASEFILE EXPFILE -dll -o DLLNAME OBJS LIBS -e ENTRY
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \
--base-file BASEFILE --output-exp EXPFILE
$(LD) EXPFILE --dll -o DLLNAME OBJS LIBS -e ENTRY
この例では $(LD) がリンカ ld です。
$(DLLTOOL) は dlltool です。
$(AS) はアセンブラ as です。
DLLNAME はあなたが作ろうとしている DLL の名前、例えばtcl80.dll など。
OBJS は DLL に入れようとしているオブジェクトファイルのリストです。
LIBS はその DLL にリンクしたいライブラリのリストです。例えば -lcygwin は要るかもしれないし要らないかもしれません。-lkernel32 は要るでしょう。Tcl は -lcygwin -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lkernel32 をリンクします。
DEFFILE はあなたの定義ファイルです。単純な DEFFILE は"EXPORTS" とそれに続いて DLL から公開する全てのシンボル名のリストからなり ます。各シンボルは一つで一行でなくてはなりません。他のプログラム は、ここでリストされたシンボルにのみアクセスできるようになります。
BASEFILE はこの5段階の処理中に使われる一時ファイルです。例えば tcl.bash など。
EXPFILE はまた別の一時ファイルです。例えば tcl.exp など。
ENTRY はエントリポイントとして使用する関数の名前です。この関数は WINAPI 属性付きで 3つの引数を取らなくてはなりません: int WINAPI startup (HINSTANCE, DWORD, LPVOID)
実際のシンボル名は @12 が付加されるので、本当のエントリポイント の名前が `startup' であれば、ENTRY に指定する文字列 はこの例では `startup@12' ということになります。
もしあなたの DLL が Cygwin API の関数を呼び出すのであれば、エン トリ関数は Cygwin「不純」ポインタを初期化する必要があります。こ れはグローバル変数 `_impure_ptr' を宣言して、エント リ関数の中で初期化することによって行います。このグローバル変数 `_impure_ptr' は DLL から公開しないように注意してく ださい。つまり DELFILE には入れないでください。
/* This is a global variable. */
struct _reent *_impure_ptr;
extern struct _reent *__imp_reent_data;
int entry (HINSTANT hinst, DWORD reason, LPVOID reserved)
{
_impure_ptr = __imp_reent_data;
/* Whatever else you want to do. */
}
$(LD) 行に `--subsystem windows' オプションを付け加えてもよいで す。Tcl のビルドではそうしていますが、私はこれが重要だったかどう かはもはや覚えていない、というのを白状しておきます。ld に --subsytem <x> フラグを指定する場合は、-e エントリは sybsystem フラグの後に来なければならないということに注意してくだ さい。というのは、subsystem フラグは異なったデフォルトエントリポ イントを設定するからです。
$(LD) 行に `--image-base BASEADDR' オプションを付けてもよいです。 これはデフォルトのイメージベースを設定します。この DLL を使用す るプログラムは、それぞれの DLL がアドレス空間の別々の場所を占有 すると、起動がちょっとだけ早くなります。それぞれの DLL はこのイ メージベースから始まって必要なサイズだけ連続して占有します。
さて、これであなたの DLL ができたので、他のプログラムからリンク できるようにライブラリを作りたくなるでしょう。これは必須ではあり ません: LoadLibrary によって常にその DLL を使うことができるから です。ですが、DLLを直接リンクできるようにしたければ、ライブラリ を作成する必要があります。このようにしてください:
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE --output-lib LIBFILE
$(DLLTOOL)、 $(AS)、 DLLNAME、DEFFILE は上記と同じです。DLLNAME と DEFFILE は必ず同じ物を使ってください。さもないとちゃんと動き ません。
LIBFILE は作ろうとするライブラリの名前です。例えば libtcl80.a な ど。これでリンカコマンドに -ltcl80 などのように使うことによって このライブラリをリンクできます。
gdbを使ってあなたのアプリケーションをデバッグするこ
とができます。 -g フラグをつけてコンパイルするのを忘れないでね!
そのアプリケーションが MS の dll にある関数を呼び出しているので
あれば、gdb はプログラムを実行したときに、それらのデバッグ情報を
ロードできないと文句を言ってくるでしょう。これは正常です。という
のはこれらの DLL はデバッグ情報を持っていないからです(たとえ持っ
ていたとしても、そのデバッグ情報は gdb 互換性が無いでしょう)。
はい。最も基本的なレベルでは、STRACE環境変数を
1 に設定すると、Cygwin アプリケーションを実行すると
いつでも、デバッグ情報が全部画面に表示されるでしょう。これはバグ
を Cygwin ライブラリの中まで追っかけていくときには特に有効に使え
るツールです。STRACE は他の値に設定して、詳細の度合
いを変えることもできます。2つほど挙げると、0x10 に
設定するとシステムコールに関する情報、また 0x800 と
するとシグナル、プロセス制御関連情報が得られます。strace メカニ
ズムは Cygwin ライブラリのソースの中の
winsup/include/sys/strace.h ファイルでよく説明され
ています。
ありがちなエラーとして、コマンドライン上のライブラリを、それが必要とさ れるものより前に置いてしまうというものがあります。
これは間違い。 gcc -lstdc++ hello.cc
これは正しい。 gcc hello.cc -lstdc++
その関数は恐らくヘッダファイルで宣言されていないか、UNICODE 用の ものが入っていないかでしょう。
はい。
malloc.h の代わりに stdlib.h をインクルードしてください。
もしあなたのプログラム中で malloc という名前の関数
を定義していて、DLL(cygwin32.dll) とリンクした場合、 DLL はあな
たのmalloc を呼び出します。言うまでもないことですが、
もしあなたの malloc がバグバグだったら深刻な問題に陥るはめになる
でしょう。
プログラムを bash からではなく DOS コマンドプロンプトから実行した場合、
DLL はコマンドラインのワイルドカードを展開しようとします。この処理はあ
なたの main 関数の処理を開始する 前に malloc を
呼び出します。もしあなたのmalloc が、main が
呼び出された後に起こる初期化を必要とするようにかかれている場合、間違い
なくおかしくなるでしょう。
はい、C のオブジェクトファイルを扱っている限りは動作するはずです。 MSVC C++ は GNU C++ とは違った方法で名前の変形を行なうので、C++ オブジェクトを混在させるのは困難でしょう。
いいえ、完全な(ソースコードでのハイレベルな)デバッグはできません。 Microsoft のコンパイラは、gdb が理解できない違ったタイプのデバッ グ用シンボル情報を生成します。
しかし、ローレベル(アセンブラ型)のシンボルは Microsoft コンパイ ラが生成するのは coff であり、これは gdb は理解「できます」。し たがって、少なくとも全てのグローバルシンボルは見ることができるは ずです。データ型、行番号、ローカル変数などの情報は得られません。
Intel の現在のチップの CPU リファレンスマニュアルは、Intel のウェ ブサイトから PDF 形式でダウンロードできます。
`http://developer.intel.com/design/pro/manuals/'
$PATH の中に . (ドット)が必要です。Makefile から起動される全てのシェル スクリプトの前にいちいち /bin/sh を付け加える必要はありません。
Win32 API へアクセスすることを示すには _WIN32 、DLL によって提供 される cygwin 環境にアクセスすることを示すには __CYGWIN__ を使い ます。
_WIN32 を選んだのは、これが Microsoft が VC++ の中で定義しているもので あり、VC++ のサンプルに従えるようコンパチビリティを持つのは良いことだ と考えたからです。私たちは _MFC_VER を使って VC++ でコンパイルされるべ きコードを指示しています。
B20 で動作する f77 と objc コンポーネントは `http://www.xraylith.wisc.edu/~khan/software/gnu-win32/' か ら入手できます。
UNIX 上の GUI を Windows に移植するには、基本的に二つの戦略があ ります。
一つ目の方法は、tcl/tk、X11、V(その他?)などといった移植性のある グラフィクスライブラリを使用することです。普通は、何らかのランタ イムサポートを必要とする Windows 上の GUI ができるでしょう。 tcl/tk の場合、それに必要なライブラリファイルと tcl/tk DLL を含 めることになるでしょう。X11 の場合は、そのプログラムを使う人全員 に、X11 サーバをインストールしてもらう必要があるでしょう。
二つ目の方法は、その GUI を Win32 API 呼び出し(あるいは VC++ の MFC)で書き直してしまう方法です。プログラムが非常にモジュール化さ れて書かれていて、共通部分の(GUI に関連しない)コードが多く含まれ ているのであれば、Cygwin を使い続けることができます。この方法で は、Cygwin の利用に由来する移植上の優位性を保つことができます。
DJGPP は同じようなアイデアですが、これは Win32 ではなく DOS 用の ものです。DJGPP はアプリケーションに対して道理の通った操作インタ フェースを提供するために、"DOS extender" を使っています。Cygwin ツールセットでは全てのアプリケーションはネイティブ WIN32 なので、 その必要はないのです。Cygwin ツールでコンパイルされたアプリケー ションは全ての Win32 API 関数にアクセスできるので、Windowsの GUI を使ったプログラムを書くこともできるのです。
DJGPP に関する詳しい情報は以下で取得できます。
`http://www.delorie.com/'.
この問題は b19 ではさらにひどかったかもしれませんが、Win 95 上の bash で Control-C すると、Win 95 のカーネルをロックさせ、あなた のマシンをフリーズさせてしまうことがあります。この問題は、もしあ なたが Win 95 の OSR2 を使っているのであれば、OSR2 CD か MSDN 購 読 CD に含まれる USB パッチをインストールすると直ることがありま す。OSR2 とそのUSB パッチに関するさらなる情報は `http://www.compuclinic.com/osr2faq/index.html' にあり ます。
gcc や他のツールは、現在のパス名の形式に完全には適合していません。 UNIX パッケージを configure/ビルドしようするときに絶対必要となる -I//d/foo という引数は通用しません。このときは、一つだけのスラッ シュによる通常のパスのみが使われます。
これは Beta 20 リリースに対するバグ修正のアップデートです。
主な変更は Cygwin ライブラリの改善版ですが、ツール類に対する小さ な変更もいくつか行われています。
gcc の "-mno-cygwin" フラグが正しいヘッダをインクルードするよう になりました。20.0 では、Cygwin ヘッダを間違ってインクルードして いました。
gcc の "-pipe" フラグが正常に動作するようになりました。
cygcheck プログラムが、cpp を見つけられないのは正しい振る舞いで ある、ということをユーザに保証するようにしました。
md5sum の "-b" フラグが、バイナリファイルに対して正しいチェック サムを生成するために使われるようになりました。
bash シェルがテキストを読み込んだ後にファイルサイズを調整するよ うになりました。
コンパイラツールのソースに libtermcap ライブラリが追加されました。 これは termcap ライブラリと /etc/termcap ファイルの新しいソース です。
less ページャ(libtermcap を使用したもの)がバイナリ配布ファイルに 含まれるようになりました。
このバージョンの Cygwin は、beta 20、19 リリースと後方互換性があ ります。Windows 9x 上での動作はより安定したものとなり、9x 上での configure に関するバグ(NT でも多少の影響があった)も修正されまし た
CYGWIN 環境変数の値の最初に、二つのスペースを入れておく必要があっ たバグは修正されました。
select 呼び出しにおけるシリアルサポートが修正されました。
非 cygwin アプリケーションからロードされる DLL の扱いが改善され ました。dlopen のバグが修正されました。
sysconf 関数に _SC_CHILD_MAX を渡して得られる値は、 _POSIX_CHILD_MAX (3) ではなく CHILD_MAX (63) になりました。
パスに関する小さなバグがいくつか修正されました。"mkdir a/" が失 敗する原因も修正されています。
インクルードファイル sys/sysmacros.h が追加されました。不足して いた wcslen と wcscmp のプロトタイプが wchar.h に追加されました。
__P が include/sys/cdefs.h の中で定義されるようになりました。こ の最後の修正をサポートするために、トップレベルの Makefile.in は CC_FOR_TARGET と CXX_FOR_TARGET を別々に設定するようになりました。
Cygwin は、次の newlib のベッセル関数をエクスポートするようにし ました: j1、jn、y1、yn
tty の ioctl オプションがいくつか追加されました: TCGETA、TCSETA、 TCSETAW、TCSETAF
いくつかの関数で、NULL ポインタ参照の対処がよりきれいになりました。
#! を通したときの相対パスによる実行の問題を修正しました。
これは Beta 19 リリースからの大きなアップデートです。EGCS ベース のコンパイラや最新版ツールに加えて、このリリースには、前回からの たくさんの改良とバグ修正を含む新しいバージョンの Cygwin ライブラ リが含まれます。
このリリースより、"GNU-Win32" の名前を引退させることになりました。 また Cygwin32 から "32" を外すことにしました。つまり、ツール類の ことを "Cygwin ツールセット"、ライブラリを "Cygwin ライブラリ" あるいは "Cygwin DLL"、ライブラリのインタフェースを "Cygwin API" と呼ぶことになります。
この名前の変更のおかげで、"Cygwin32" という名前に関係するライブ ラリの外観は全て変更されます。例えば、CYGWIN32 環境変数は CYGWIN 環境変数になりました。cygwin32_ で始まる API 関数は、バックワー ドコンパチビリティのために、この形でもまだ利用できますし、同時に 新しい cygwin_ 接頭辞付きの名前でも利用できます。同じことがプリ プロセッサ定義が __CYGWIN32__ から __CYGWIN__ に変わったことにつ いても言えます。将来のリリースではこの古い名前は削除されますので、 ほんのちょっとだけ時間を割いて頂いて、この "32" を削除してくださ るようお願いします。これによって引き起こされる混乱をみなさんにお 詫びいたします。この名前を "Bob" にしても良かったんですが、その 名前はすでに Microsoft に取られていたので… :-)
なぜ変更したか、ですか? 一つには、この配布物に含まれるソフトウェ アは、Cygwin ライブラリ自身も含めて、 GNU のソフトウェアではない ものがあるからです。従って、このプロジェクトを "GNU-Win32" と呼 ぶことは、常にちょっとだけ間違っています。それに加えて、"Cygwin ライブラリ" を使うこれらのツールを "Cygwin ツール" と呼んだ方が、 より混乱が少ないだろうと考えたからです。
また、sourceware.cygnus.com という新しい立派な web/ftp サイト上 に移った、ということもお知らせしてしておきます。古いアドレスはし ばらくの期間(不定)は有効です(できれば、少なくとも全てのミラーが 修正されるまで)。
最新の正式な EGCS リリースが、Cygwin 配布で使用される基本のコン パイラになりました。つまり、x86/Cygwin 関連のパッチがいくつか入っ た EGCS 1.1 が、このリリースに入っているコンパイラです。
UNIX プログラムの移植よりも Windows ネイティブな開発に興味がある 人にとっては、新しい gcc のフラグ "-mno-cygwin" によって最新の Mingw32ライブラリがリンクされ、Cygwin を使用しない実行形式を生成 する、ということは朗報でしょう。
その他の開発ツールは、全て最新のバージョンにアップデートされまし た。リンカ(ld)にはたくさんの重大なバグ修正が入っています。DLL か ら .reloc セクションを安全に strip することが可能になりました。 windres リソースコンパイラは大きく改善されました。
Beta 20 には、ash-0.3.2-4、bash 2.02.1、 grep-2.2、 ncurses 4.2、 less 332 といったたくさんのパッケージのアップグレードも含まれて います。bzip2 0.9.0 を配布に含めました。また、df ユーティリティ が、fileutils パッケージからの仲間に加わったことにも気がつくでし ょう。
sh の実行バイナリは従来通り、Debian Linux ディストリビューション からの ash ですが、Beta 19 リリースで問題のあったクォーティング のバグはもう無くなりました。bash で Control-C を行っても、バック グラウンドの処理を止めてしまうことが無くなりました。
Tcl/tk はバージョン 8.1a2(と追加パッチ)にアップグレードされまし た。tix と itcl の互換性のあるバージョンが含まれています。これら には全て Cygwin 版の configure ファイルも含まれているので、Win32 版 tcl/tk の UNIX 風の構築を行うことができます。expect はCygwin 用追加パッチの入った 5.26 にアップグレードされています。
お客様のご意見とご要望にお応えして、Cygwin は、GDBtk や WinGDBよ りもより良い GDB のグラフィカルなフロントエンドを開発しました。 この tcl ベースの GUI は、GNUPro ツールキットのお客様に現在出荷 されています。この GDB に対する変更の仕掛と GDB に組み込まれた tcl インタープリタは、GPL ベースのソースの一部です。ですが、tcl のスクリプトは現時点ではネットワーク上では利用できません。このた め、この Cygwin リリースでは、コマンド行バージョンの gdb のみし か入っていません。
DJ Delorie は、"cygcheck" という新しいプログラムを書いてくれまし た。このプログラムは、ある実行バイナリがどの DLL をどこからロー ドするか、などといった、Cygwin 環境がどのように設定されているか に関する有用な情報を表示してくれます。これによって、よくある設定 上の問題の診断が簡単になると願っています。
ps ユーティリティがアップグレードされています。出力フォーマット を長くしたり短くしたりするなど、いくつかのオプションがつきました。
このバージョンの Cygwin は、beta 19 リリースと後方互換性がありま す。古い "cygwinb19.dll" を消してしまい、"cygwin1.dll" を "cygwinb19.dll" にコピーすれば、B19 でコンパイルされた古い実行ファ イルを新しい "cygwin1.dll" で使用することができます。
Cygwin の内部では、かなりの部分が、さまざまな問題を解決するため に書き直されたり、修正されたりしています。もし何か特定の問題につ いて疑問がある場合は、開発ツールソースの中の winsup/ChangeLog ファ イルに、過去 3 年間に渡って DLL に施されてきた修正が全て記載され ています。以下に要点をいくつか示します。
Cygwin のバージョン番号付けに新しい体系を使うようになりました。 DLL、API、共有メモリ領域インターフェース、レジストリインタフェー スのそれぞれに個別のバージョン番号がつくようになっています。これ で、一つのユーザ環境に複数の Cygwin ツール群を共存させることがよ り簡単になるだろうと思います。
Windows 98 がサポートされています(Cygwin の視点から見れば、 Windows 95 と同じようなものです)。それでも Windows NT にアップグ レードすることをお薦めしますが。
Cygwin の実行速度については、まだ改善すべきことがたくさん残って いますが、B20 のリリースに先立っていくらか改善の努力を施しました。 恐らく最新バージョンの Cygwin は、今までの中で最速であると思いま す。それに加えて、ファイルのオープン・クローズや tty の使用に関 連する、厄介なハンドルリークをいくつか塞ぎました。
lseek 呼出しは WriteFile を使うようになり、EOF を越えた書き込み が行われたときのギャップは、Win32 の仕様にあるように「未定義」の データが残されるのではなく、0 で埋められるようになりました。
Cygwin ヘッダファイルの大きく改善する作業が行われました。
UNIX 風のシリアル I/O のための Cygwin サポートが、より改善されま した。
パスの扱いは、再度修正、書き直しが行われています。デフォルトでは、 UNIX のパーミッション・実行状態を格納するのに、NT の拡張属性を使 うことは無くなりました。これは、FAT パーティション上に NT が作成 するファイルは、数千のファイルの規模に耐えられないからです(全て がのろのろと遅くなってしまう)。
シグナルの扱いについても、かなり注目するものがあります。しかし残 念ながら、タイマーと Windows 9x の組み合わせではまだいくつか問題 が残っています。
tty の数は 16 から 128 に上げられました。
DLL に含まれた新しい API: sethostent、endhostend
上で述べたように、cygwin32_ の接頭辞のついた関数は全て、cygwin_ の接頭辞付きでエクスポートされるようになっています。あなたのプロ グラムを、この新しい名前の関数を呼び出すように調整してくださるよ うお願いします。
`遅い'デバイスの read において、signal が正しく制御されるように なりました。すなわち、read は EINTR を返します。
これは重要なリリースです。これにはさらに新しいバージョンの Cygwin32 ライブラリが含まれています。Cygwin API は互換性のなくな る変更がなされたので、dll の名前は cygwinb19.dll に変更されまし た。これは以前に作成された実行プログラムを無効にしないようにする ためです。
B19 でコンパイルされたアプリケーションが B18 でコンパイルされた アプリケーションを exec() するときは、B18 でコンパイルされた実行 プログラムは普通の Win32 実行プログラムとして扱われることに注意 してください。これはつまり、オープンしたファイルディスクリプタや その他の内部データは exec() 呼び出しにおいて継承されないというこ とです。この理由は、cygwin ライブラリのバージョンの違いによって 違った共有メモリ領域が使用されるからです。これはあなたのやろうと していることによっては重大かも知れませんし、そうでないかも知れま せん。
Cygwin32 ライブラリの Beta 19 リリースは、引き続き GNU General Public License (GPL) に従ってライセンスされます。
コンパイラツール で使用される PE 形式の定義は、Microsoft のもの により近くなりました。これによって 他のベンダの開発ツールとの間 でより共同利用できるようになるでしょうが、しかしおそらくこの領域 についてはまだまだやるべきことが多く残っているでしょう。この変更 によって、以前作成されたオブジェクトファイル(.o)やスタティックラ イブラリファイル(.a)が使えなくなりますので、必要なものは忘れずに 古い .o と.a ファイルを消して作成し直してくださいね!
最後に、古いシンボリックリンクはこのリリースで無効になります。 "system" 属性がシンボリックリンクの印として使われるようになり、 これで fstat と他のファイル関連の呼び出しが非常にスピードアップ されました。古いシンボリックリンクを作り直すか、あるいはそれらの "system" 属性フラグをセットすることで、正しく認識されるようにな るでしょう。
新しいインストーラは、 program files のショートカットをインストー ルすることで全ての環境変数の設定を自動的に行います。このショート カットは全ての環境変数を正しく設定して bash プロンプトを立ち上げ ます。この結果、セットアップ処理は前回のリリースよりもよりきれい になりました。
ツールを最終的には移動させる人のために、デフォルトの環境変数を設 定するバッチファイルが、 cygnus.bat という名前でインストールディ レクトリのルートにインストールされます。ツールは/cygwin/b19 にイ ンストールするようにコンパイルされているので、この場所にインストー ルしたときは、 bin ディレクトリがパスに入っていれば各ツールは 「それだけで動く」はずです(特別な環境変数は何も必要ありません)。 唯一の例外は、MAKE_MODE で、これは通常の UNIX風の make の振る舞 いをさせたい場合に設定する必要があります - さらに詳しくは以下の make のノートを参照してください。
Ian Lance Taylor 氏によって、 "windres" というリソースコンパイラ が書かれました。これはウインドウリソースを、テキストの rc ファイ ルから COFF ファイルにコンパイルするのに使用されます。ソースは binutils サブディレクトリの中にあります。
たくさんのユーティリティがバージョンアップされました。 Beta 19に は bash 2.01.1、 fileutils 3.16、gawk 3.0.3、 patch 2.5、 shellutils 1.16、 tar 1.12、textutils 1.22、texinfo 3.11 が含ま れます。Cygwin32 上の bash は、数ある改良の中での特筆点として、 ジョブコントロールが動作するようになりました。
sh の実行プログラムは、 Linux の Debian ディストリビューションの ash 0.2 になりました。このより小さくなったシェルを/bin/sh.exe と して使うことで、 configure が大きくスピードアップします。
Bison 1.25 が追加されました。
Tcl/Tk はバージョン 8.0 にバージョンアップしました。互換性のある バージョンの tix と itcl が追加されました。これらは全て Cygwin32 コンパチブルな configure ファイルが含まれていて、Win32 版の Tcl/Tk を UNIX 流の方法でビルドできます。
Expect 5.21.3 が含まれ、基本的には動作しています。
バイナリは Pentium ベースのシステムで速度が向上するように i686 最適化をオンにしてコンパイルされていますが、i386 以降のチップで も動作するはずです。
リンカ(ld)が強化されました。 -- dll をリンクするときに、idata3 ター ミネータが自動的に追加されるようになりました。
kill はシグナルの名前の引数をサポートするようになりました。ps は プロセスの開始時間情報を表示するようになりました。
デフォルトのツールのインストールでは詳細は隠されますが、makeユー ティリティのデフォルトは Win32 モードになりました。これはサブシェ ルとして cmd.exe/command.com を使うというモードです。このモード ではファイル名にバックスラッシュが使えます。UNIX プログラムをビ ルドするには MAKE_MODE 環境変数を "UNIX" に設定する必要がありま す。こうすることでサブシェルに sh.exe を使用する従来の振る舞いに なるでしょう。
インタフェースはより明確になりました。libc、libm と UNIX 互換関 数が含まれています。libgcc.a の外部名は含まれません。これによっ てより安定したインタフェースになるはずです。インタフェースのドキュ メントは calls.texinfo を参照してください。
dll 全体の振る舞いを制御する環境変数は、 CYGWIN32 という変数一つ だけになりました:
set CYGWIN32=[no]title [no]strip_title [no]binmode [no]glob strace=mask:cache,file [no]tty
"set CYGWIN32=title tty" と設定すれば、tty のサポート(以下参照) を行い、現在の実行プロセスをタイトルバーに表示します。
B19 では以下のサポートが追加されています:
以下の関数が追加されました:
以下の関数は削除されました:
Winsock dll (wsock32.dll) はもはや Cygwin32 dll に暗黙のうちにリ ンクされることはなくなりました。代りに、プロセスが Cygwin32 のネッ トワーク関数を最初に呼び出したときに、LoadLibrary によって明示的 にロードされます。これによって多くのプロセスはかなりスピードアッ プします(configure で約 20%)。
シグナル関連のコードは一から書き直されました。パスを扱うコードの ほとんども同様です。
ファイル名展開(globbing)と getopt のコードは BSD 派生のコードに 置き換えられました。正規表現のコードは Henry Spencer 氏の Public Domain な実装に置き換えられました。
Doug Lea 氏の malloc が cygwin から公開されるデフォルトの malloc として使用されるようになりました。この malloc はスピードとコンパ クトさのバランスを非常にうまくとっていますが、しかしすでに free されているメモリを free しようとするのを許してくれません。すなわ ち、セグメンテーション違反を引き起こします。
bsearch 関数は書き直されました。
Alt Gr キーの振る舞いはこのリリースで変更されました。左 alt キー は今までどおり ESC キーシーケンスを生成します。右 alt(Alt Gr) キー は国ごとのキーボードレイアウトに従った文字が生成されるようになり ました。
プロセスは、 CYGWIN32 環境変数に "title" を含めない限りタイトル バーに名前を表示しなくなりました(上記参照)。
複数の cygwin.dll は、それらが同一(同時にビルドされたもの)でない 限り、同じメモリ空間を使わなくなりました。これによって互換性のな い共有メモリの使い方をする複数の dll を同時に走らせることができ ます。これは buggy な cygwin.dll をデバッグする機能でもあります。 最新の cygwin.dll をシステム上に一つだけ残すようにすれば、全ての cygwin プロセスが同じ共有メモリ空間に存在するということが保障さ れるでしょう。
/ のマウントのデフォルトはもはや C: ではありません。システムドラ イブ(OS がインストールされているところ)がデフォルトになりました。
標準のダイナミックライブラリローダ関数 dl* が利用できるようにな りました。 Cygwin32 B19 は fork の後に正しくデータをコピーし、親 プロセスにロードされていた DLL を自動的に再ロードするようになり ました。さらに、DLL はロードされるときに正しく初期化され、グロー バルコンストラクタが呼ばれるようになりました。グローバルデストラ クタは DLL が detach されるときに呼び出されます。親プロセス中で dlopen や dlsym によって得られたハンドルは、fork された子プロセ スの中でもアクセス可能です。LD_LIBRARY_PATH 環境変数が dlopen 検 索に使用されます。
cygwin32 で作成された .dll 内では <cygwin32/cygwin_dll.h> ファイルをインクルードして、これ らの関数を使用する .dll を作成するには DECLARE_CYGWIN_DLL(dll-entry-point) 行を使用してください。
これは重要なリリースです。新しい cygwin.dll は以前リンクされたアプリケー ションとのバックワードコンパチビリティがありますが、内容は大きく変わっ ています。
インストール処理が完全に変更され、 InstallShield5 ベースのインストーラ を使うようになっています。これにより過去に経験した数々のインストール時 の問題を減らしてくれます。しかしながら、配布ファイルに付属している README.txt で説明されているように、環境変数は未だに手で設定する必要が あります(将来のgnu-win32 インストーラには、これを自動的に行う機能を持 たせるかもしれません)。
GCC のコンパイル時間が fork() の代りに spawn() を使うことによって、 20-30% 向上しました。
GCC は、環境変数(COMPILER_PATH、 LIBRARY_PATH、 C_INCLUDE_PATH、 CPLUS_INCLUDE_PATH、 OBJC_INCLUDE_PATH)の値に、 Win32 と POSIX 形式 のパス名(あるいはパス名リスト)のどちらでも受け付けます。
GDB には tcl/tk ベースの GUI(gdbtk) が付属します。"gdb -nw" として起動 することによって、コマンドライン gdb を起動することもできます。
bash は起動時に、 /tmp が存在しており、かつそれがディレクトリであるこ とを確認します。そうでない場合には文句を言います。
gcc と ld に -s をつけて実行すると不正な実行ファイルが作成されていまし た。これに関する bfd のバグが修正されました。
String.h と string.h(と同様なヘッダファイルの組)が衝突して、インクルー ドしたものと違う方が読まれてしまうことを修正しました。
トップレベルの install-sh スクリプトは、foo をインストールしようとして foo が存在しない時は、foo.exe をインストールしようとします。これで多く の Unix ソフトウェアのインストールの問題が解決します。
dlltool に -I オプションをつけて起動することにより、.def ファイルの IMPORT 宣言が試験的にサポートされます。ぜひ気軽にこれを経験してみてく ださい。ただしこの機能がより広くテストされるようになったら、このフラグ はなくなるでしょう。
time はバージョン 1.7 に上がりました。
make はバージョン 3.75 に上がりました。
make は VPATH 変数で、Win32 と POSIX のパス名リストをどちらでも受け付 けます。
The following is now supported:
以下がサポートされています:
以下の関数が追加されました:
かなり改善されたシグナル、例外ハンドラがサポートが追加されています。 kill シグナルはかなり良く働くようになりました(bash で コントロールC が 働きます)。
シェルスクリプトが、常にデフォルトの /bin/sh ではなく、#! の後ろに指定 されたシェルで動くようになっています。
浮動小数点レジスタが crt0.o の中で正しく初期化されるようになっています。
com ポートのようなディスク以外のファイルのオープン時には、シンボリック リンクであるか、実行可能であるかというチェックはもはや行いません。
コンソールタイトルは、実行中のプロセスの名前がセットされるようになって います。
winsock はアプリケーションの起動時に初期化されるようになっています。
reent_data がプライベートアドレス空間から cygwin.dll に移動しました。
system() 呼び出しは、fork()/exec() ではなく spawnvp() を呼び出すように なっています。
NT 拡張属性に対するサポートが追加されましたが、あまりにも遅くなってし まうので今のところ無効にしてあります。これをシンボリックリンクや実行可 能属性のファイル状態を記憶するのに使用したいのです。
NT 上でのみ、 mkpasswd と mkgroup ユーティリティが、正しい /etc/passwd と /etc/group を生成します。
以前のリリースではマウントポイントはレジストリの "Cygnus Support" 以下 に格納されていました。これは beta 18 より "Cygnus Solutions" に変更さ れました。レジストリエディタ(NTでは regedit)を使って古いエントリの名前 を変更するか、あるいは単にもう一度マウントを行ってください。そうすれば cygwin.dll が自動的に新しいものを作ります。
マウントポイントは、30 文字ではなく、最大 MAX_PATH までの長さを取るこ とができます。
Win 95 で configure が動くように、再びパッチが適用されました。
ld はデフォルトの実行ファイル名として "a.exe" を作成するように変更され ました。
Cygnus Developers' Kit (CDK) と User Tools の両方を全て正しくインストー ルすれば、x86 NT 上のツールをネイティブにリビルドすることが可能になり ました。
cygwin.dll に大掛かりな変更が行われたにも関わらず、以前にビルドされた アプリケーションを使うことを妨げるものは何もありません。新しい DLL は 私たちの知る限り、beta 16 と互換性を持っています。beta 14 でビルドされ たプログラムはやはり beta 17 の DLL でも動かないので、それらを動かすた めには再リンクする必要があるでしょう。
Cygwin32 API を形作る winsup ファイルは GNU General Public License の もとに置かれるようになりました。詳細は添付のプレスリリースを参照してく ださい。
gcc はデフォルトで -lkernel32 をリンクし、また mwindows がセットされた ときは -luser32 -lgdi32 -lcomdlg32 がリンクされるようになっています。 その他の重要な変更として、実行プログラムを作るとき、-o の引数に foo を 与えると foo.exe を作成するようになりました。
dlltool には、オプションの中でコンソールか GUI かの選択を行う --subsystem の扱いを良くするパッチが入っています。 ld はスタックの予約サイズを大きく取るように変更されました。これは NT 上でのネイティブなツール群をビルドするのに必要となります。
C++ のヘッダは正しく設定された GCC_EXEC_PREFIX 環境変数によって与えら れます。
fileutils と make の新バージョンが含まれています。findutils が追加され ました。
Scott Christley の、標準 Win32 dll 用のヘッダ、def ファイルが統合され ました。以前の Cygnus ヘッダでのみ提供されていたものはすべて適切な場所 に追加されました。 私たちのヘッダから抜き出して作った標準 Win32 ヘッダ 名の管理ファイルがあるので、ある特定のヘッダファイルをインクルードしよ うとしているプログラムも動作します。より完全なヘッダを持つことで、 Win32 のネイティブプログラミングが簡単になりました。
select は一から書き直しました。新しいものは全てのソケットと全てのハン ドルを扱うことができます。タイムアウト付きのハンドルどソケットはまだ実 装されていません。select はブロッキングを行うようになり、CPU を働かせ ません。
ファイルハンドル処理は大きく書き換えられました。 fhandler 配列は共有メ モリの中ではなく、ローカルメモリの中に移動しました。これはいくつかの振 る舞いを改善します。このサポートのために大きな変更がありました。 ansi/vt100のコンソールサポートがかなり完全なものとなっています。いくつ かの新しいファイルロッキングがサポートされました。矢印キーがサポートさ れました。
プロセス制御がさらに改善されました。
fork() の重大なバグが修正されました。
system() 呼び出しが動作するようになっています。
unlink() はファイルを削除しようとする前に、読み出し専用のファイルを書 き込み可にモードを変更します。これにより、rm が読み出し専用ファイルに 対して何度も "out of queue slots" というメッセージを出して削除できなかっ た、という未解決の問題が修正されます。
テキストモード読み出しが書き直されました。
新しい syslog によって、NT 上ではイベントログへ、Win 95 ではファイルヘ ログを取ることができます。
シンボリックリンクが有効です。
readv() と writev() が実装され、公開されました。
MS との互換性のために、dll からの関数の export を、 funcname に加えて _funcname として export します。私はこの事実を利用しないように提案し ます。ただし、すでにこの方法で C ライブラリをアクセスするようになって いるコードをビルドする場合はこの限りではありません。
ほとんど全てのソースコードは C++ のファイルになっています。
パス名の扱いは完全に書き直されました。bash で Q: ドライブを参照するに は、//q/ で参照できるようになりました。もしくは、"mount Q: /q" とタイ プすることで、Q: ドライブが /q として見えるようになります。
Windows 95 と NT 4.0b2 上で、i386 の Plum Hall positive C 適合試験に パスしました。
fork は以前は dll 内からのアクセスはできませんでした。もはやそんなこと はなくなり、既に動いているシステムや popen コールを追加することができ ます。
getdomainname は、レジストリからの情報を取得して動作します(以前は単に "cygnus.com" を返していた)。
readdir で errno が正しくセットされないバグが修正されました。これで ディ レクトリをまたがった diff が動かない問題が修正されました。
シグナル関数内でのエラーチェックが改善されました。winsock の初期化は cygwin32_socket 内で checkinit を呼ぶことで行われます(これは、最初にこ の処理を行う関数を呼ぶ必要があったというバグを修正します。)。
新規関数: sigaddset, sigismember, sigfillset, sigemptyset
sysdef ファイルにあった余分なアンダースコアを取り除きました。
cygwin.dll に関連付けられるメジャーおよびマイナーバージョン番号ができ ました。 メジャー番号は互換性のなくなる変更が行われたときのみ変わり、 マイナー番号は、古いアプリケーションの再リンクを必要としない程度の、何 らかの変更が DLLに対して行われたときに変わります。
include/sys/param.h の中の HZ の値を、正しい値 1000 に変更しました ("time sleep 5" が 50 を返す、と言われていたバグが修正されます)。
i386 と ppc プロセッサの両方で、例外の扱いがいろいろと修正されました。
Cygnus Kerberos を動作させるために必要な time 関連が、いろいろと修正さ れました。 time 用新規関数: gmtime, corelocaltime
spawn と fork にさまざまな修正が行われました。
仮想 Unix プロセス処理が追加されました。新しく ps と kill コマンドが追 加されました。
Control-Z は、テキストモードでオープンされたファイル中では、正当な EOF 文字として扱われるようになりました。lseek はバイナリモード中でのみ動作 します。
select が改訂されました。
その他さまざまな変更がありました。さらに詳細な情報は、ソースコードの winsup/ChangeLog ファイルをあたってください。
プリプロセッサのマクロ定義の構成が変更されました。アプリケーションは、 Win32 API へのアクセスのチェックを行うためには __WIN32__ ではなく _WIN32を、また Cygwin32 環境の存在のチェックには__CYGWIN32__ を使わな くてはなりません。
GNU findutils、GNU dbm、GNU bison、GNU less、ncurses、ftp、finger、rcl、 cvtres、V はもはや含まれません。これは将来変更されるかもわかりませんが。
以前のリリースでビルドされた古いアプリケーションは、新しい cygwin.dll と再リンクしなければなりません。
いくつかのバグが修正されています。GDBM と m4 がリリースに入っています。 GCC は cc1 などのために標準インストールディレクトリを使用するようにな ります。
gnu-win32 版 V が含まれました。これで Unix と Windows で変更せずに動作 するグラフィックアプリケーションを書くことができます。V の一部は PPC でも動作します。
標準の DOS シェルからプログラムを実行した場合、DLL はコマンドライン引 数にある全てのワイルドカードを展開します。従って ls *.exe は、bash か らでなくとも、あなたの思った通りに動きます。
ncurses と less が含まれました。DLL の vt100 エミュレーションは完全で はなく、ncurses は全て正しくは動作しません。そのため、less は多少役に 立ちません(訳注:原文は "Hence less is more or less useless.")。これは 新しい DLL で修正されるかもしれません(もし何か curses を利用するものを 使いたい場合には、TERM と HOME 環境変数を設定するのを忘れないでくださ い)。
main を省略すると、ライブラリは WinMain を通常の方法で呼び出そうとしま す。
^C は Windows 95 上での動作がだいぶ良くなりました。これはまだ完全に正 しくはないけれども、少なくともほとんどの場合は今の作業を中断し、ほとん どの場合はマシンをクラッシュさせません。
bash のセッションを2つ以上平行して開始することができます。
いくつかのネットワークのサポートが追加されました。telnet.exe が提供さ れているにも関わらず、それが動作しないのは分かっていますので、バグ報告 は送らないでください。
新しい DLL で動かすにはアプリケーションを再リンクする必要があるでしょ う。
DLL はそれ自身の .zip ファイルでもリリースされていますので、その他のも のが必要ない場合には、全てのものをダウンロードする必要はありません。
デフォルトのファイルモードをレジストリで変更できます。 2つのリソースツールが含まれています。 同じ綴りで大文字、小文字だけが違うファイル名を使えます。 厄介な bash がハングするバグが修正されました。 raw フロッピーディスクにアクセスできます。
bash から 非 gnu-win32 アプリケーションを実行できます。
mount コマンドを使って、別のディレクトリをマウントできま
す。
最低限の ANSI 端末エミュレーションが含まれました。
パッケージがより小さく、論理的なまとまりに分割されました。
/d<name> 機構はなくなりました。
PowerPC の最初のサポートが追加されました。
ftp サイトへの途中で何かが壊れちゃいました。
bash 内で環境変数を渡すことができます。
たくさんのものがあらかじめコンパイルされて提供されました。
標準 FSF リリースとの diff が提供されました。
自分自身でホストになります。
シンボリックリンクをサポートします。
ディレクトリレイアウトがより unix 風に変更されました。
c 以外のドライブへのアクセスする方法が新しくなります。
i:\foo.cc が /di/foo.cc になります。
fork の厄介なバグが見つかり、修正されました。CPP は環境変数で与えたディ レクトリを検索するようになりました。
libc と libm を全て共有ライブラリ内に入れました。 これでいくつかのバイナリのサイズは、猛烈に小さくなります。 例えば、ls は 82,949 バイトから 26,624 バイトになります。 "Hello World" は 2564 バイトの大きさです。 これは舞台裏で行われているものの大きなスピードアップの初舞台です。
別々のプロセスは、共有メモリを使って通信します。
レジストリをほんのちょっと使います。
DLLTOOL は「とても」早くなりました。
DLL を割り付けたときについての小さな問題がいくつか修正されました。
GDB が動きます。
GCC はデバッグ情報を生成するようになりました。これは「非常に巨大な」実 行ファイルを作り出します。でも、幸運なことに strip も動作します。
クォーティングを動作させるために、さらなる作業が行われました。
termios の簡単なサポートが newlib に追加されました。
パスの表現にもっとよい方式をとります。例えば //c/foo は c:\foo のこと です。
再び Win 95 で動きます(これが Beta 6 が宣伝されなかった理由)。
パーミッションはよりうまくごまかせるようになります。
デモのソースは、win32 バイナリツリーを全て ftp しなくても利用できます。
DLL を作成できるようになりました。小さなデモが含まれています。 tcl、byacc、fileutils、diff、make が含まれています。
最近のバージョンの Win95 上での動作を妨げるものを全て修正しました。
vfork と exec の変なところが修正されました。
Import ライブラリは、ただの .o ファイルではなく本当のライブラリになり ました。
デバッグ情報はバイナリイメージとライブラリから取り除かれました。 これは gdb が動くようになるまではただの無駄ですから。
4つの主要な import ライブラリを書き入れました。
win*.h ファイルは <foo>/include/sys ではなく <foo>/include にインストールされるようになりました。これで箱か ら出してすぐコンパイルできるものが増えるでしょう。
PE サポートが修正されました。プログラムは NT 3.1 、NT 3.5、NT 3.51 、 WIndows 95 上で動作します。
GUI プログラムを作成できます。
他の三つの DLL の .DEF ファイルが開始されました。
新しい GUI のデモプログラム。
Cライブラリはテキストファイルとバイナリファイルを区別します。従って、 ツールによって生成されたテキストファイルは、DOS が大好きな、行末の見慣 れた ^M が入ります。
Cygnus の Doug Evans は、execve、opendir やその他さまざまなすごいこと について、素晴らしいサポートをいっぱい追加しました。
例外処理が良くなりました。
古すぎて覚えてません。
私は Geoffrey Noer (noer@cygnus.com) です。私は、1996 年中頃にこ のプロジェクトの担当になってから、ずっと Cygwin に熱中してきまし た。Cygwin の維持管理者として、beta 16 から現在までのネットワー ク上でのリリースを作成したり、開発スナップショットを作ったり、ネッ トワーク上の協力者達とバグを修正したり、自分でも修正したり、など を行ってきました。Cygwin の成功と Windows の重要性が増してきたこ とのおかげで、今は Cygwin の担当は、マネージャーの Eric Bachalo 氏のもと、私と Chris Faylor 氏と DJ Delorie 氏とで分担しています。
最近の Cygwin の変更の多くは Chris Faylor (cgf@cygnus.com) 氏の おかげです。彼は、 Cygnus に入る前はネット上の協力者として、プロ セス制御や環境のコードの大きな修正、strace 機構の作業のやり直し、 シグナル関連のコードの一からの書き直し、などに協力してくれました。
DJ Delorie (dj@cygnus.com) 氏は最近 Cygnus に入り、それ以来いろ いろと役に立ってくれています。彼は、Cygwin のプロファイリング、 自動試験フレームワークである Dejagnu の作業、ld/dlltool を行い、 Cygwin ユーザーズガイドの大部分を書き、cygcheck ユーティリティを 作成してくれました。
Cygnus で Cygwin に従事している我々は、受け取ったパッチや質問に 対して、できる限り応え、対処しようとしていますが、現実にはメイン のメーリングリストに送られたメールの全てにお答えする時間は無いと いうことはご承知ください。Win32 ツールのネット上のリリースの作成 や、ネット上での手助けは、私達の第一の仕事ではありませんので、お 答えできないメールもでてくるでしょう。
Sergey Okhapkin (sos@prospect.com.ru) 氏は、測り知れないくらい貴 重なネット上の協力者です。彼は tty/pty のサポートを実装し、シグ ナルと例外処理の改造において重要な役割を果たし、ライブラリ中のい たるところにおいて数えきれないほどの貢献をしてくれました。彼はま た、beta 19 リリース以降、ネット上での開発スナップショットのバイ ナリを提供してくれました。
Mumit Khan (khan@xraylith.wisc.edu) 氏は、EGCS 側について最も手 助けしてくれた方で、B20 リリースへのコンパイラ群に対してかなりの 数の安定化パッチを提供してくれました。
Corinna Vinschen (corinna.vinschen@cityweb.de) 氏は、パスの扱い やコンソールサポート、raw デバイスサポートについて、いくつか有用 な修正を施してくれました。
Philippe Giacinti (giac@dalim.de) 氏は Cygwin での dlopen、 dlclose、dlsym、dlfork、dlerror の実装に協力してくれました。
Steve Chamberlain (sac@transmeta.com) 氏は、Cygnus で働いていた ときに、Cygwin の原形を実装しました。彼はまた、beta 14 までのリ リースを全て作成しました。
その他多くの Cygnus の人々が、 Cygwin に重要な協力をしてくれまし た。Tobin Brockett 氏は beta 19、20 リリース用に InstallShield ベースのインストーラを書いてくれました。Ian Lance Taylor 氏は、 beta 18 において必要とされていた、パスの扱いのコードの作り直しを 行い、それに関連するたくさんの修正を、コード全体を通して行ってく れました。Jeremy Allison 氏は、select を一から書き直し、ファイル の扱いとプロセス制御の分野において多大な協力をしてくれました。 Doug Evans 氏は、beta 16 においてパスの扱いのコードを書き直すな どを行ってくれました。Kim Knuttila 氏と Michael Meissner 氏は、 今は亡き PowerPC 版の作業に多大な時間を費してくれました。Jason Molenda 氏と Mark Eichin 氏も、重要な協力をしてくれました。
そしてまた、このツールを使ってくれている皆さんに、アドバイス、バ グ報告、コード修正という形で協力してくださっていることに非常に感 謝します。これからもよろしく!
ほとんどのツールは GNU General Public License (GPL) で保護されて いますが、他のいくつかはパブリックドメインであり、その他は Berkeley スタイルの著作権を持っています。GNU GPL の「制限」を全 うすると、基本ルールは、もし何かのバイナリを配布すれば、ソースも 利用できるようにしなければならない、ということです。全詳細につい ては、以下の GNU GPL の文章を必ず読んでください。
ソースコードの winsup サブディレクトリにある Cygwin API ライブラ リもまた、GNU GPL によって保護されています。デフォルトでは全ての 実行プログラムはこのライブラリ(と、 GPL に従った Cygwin glue (糊 付け)コードを含むプロセス)をリンクしています。これは、コンパイル した実行プログラムが Cygwin ライブラリを使わないようにあなたがツー ルを修正しない限り、あなたのコンパイルしたプログラムも誰でもソー スコードが利用可能な GPL で配布されるフリーソフトウエアになる、 という意味です。
Cygwin は現在、Cygnus GNUPro ツールキットの一部として商用利用が 可能です。GNUPro ツールキットと 5 ユーザ以上の開発チーム向けミッ ションクリティカルサポートを購入されたお客様には、Cygwin ライブ ラリの商用バージョンがご利用いただけます。5 ユーザの値段は、 GNUPro ツールキット、一年のミッションクリティカルサポート、 Cygwin ライブラリの商用ライセンスを含めて、$7495 です。さらに詳 細な情報は info@cygnus.com までお問い合わせください。
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
Geoffrey Noer noer@cygnus.com
この文書の翻訳は Keisuke Mori(ksk@kt.rim.or.jp) が行いました。 ただし訳者はこの文書の内容に関していかなる責任も負うものではなく、 また Cygnus に対していかなるサポートを行うものでもありません。も ちろん誤訳の指摘、その他アドバイスなどは歓迎いたします。
謝辞: この文書を翻訳、公開するにあたって、公開を快く承諾してくだ さった Geoffrey Noer 氏、拙訳にご意見をくださった石尾孝弘(BERO) 氏に感謝いたします。
Last Modified: Mon Dec 7 20:36:25 PST 1998
This document was generated on 7 December 1998 using the texi2html translator version 1.51.