Cygwin ツール群は、広く普及している GNU の開発ツール群を Microsoft Windows 用に移植したものです。 これらのプログラムは、それらが必要とする UNIX システムコールや環境を提供する Cygwin ライブラリによって動作します。
これらのツールをインストールすることによって、標準 Microsoft Win32 API 及び Cygwin API を使った Win32 コンソールアプリケーション、 または GUI アプリケーションの作成が可能になりました。 結果として、多くの重要な UNIX プログラムを、 大規模なソースコードの修正なしで容易に移植することが可能になります。 これにはほとんどの利用可能な GNU ソフトウエアの configure とビルドも含まれます (Cygwin 開発ツール自身に入っているパッケージも含まれます)。 あなたにとって開発ツールはあまり意味がないとしても、 このパッケージで提供される沢山の UNIX 標準ユーティリティには興味を持たれるかも知れません。これらは(同時に提供される)bash シェル、 Windows 標準のコマンドシェルのどちらからでも使用できます。
ちょっと待って下さい…Red Hat のサポートに連絡を取るなどの手段を利用して、Cygwin に対してお金を支払った場合に限り、Cygwin はサポートされます。 Red Hat のサポートに連絡を取るための情報については、 http://www.redhat.com/software/tools/cygwin/ を参照して下さい。
すなわち、Cygwin は Windows CE を除く、近代化された全ての Windows のバージョンで動作するであろうと考えられています。 これには Windows 95/98/ME/NT/2000/XP が含まれます。
Cygwin はその下で動作する OS でサポートされている範囲だけしかサポートしないという点には注意して下さい。 このため、Windows の様々なバージョンの上で Cygwin は異なった動作をし、 異なった制限があります。
Cygwin プロジェクトのホームページは http://cygwin.com/ です。 ダウンロード及びセットアップへのリンク、ミラーサイトの最新リスト、 ユーザーズガイド、API リファレンス、メーリングリストとアーカイブ、 そして追加の移植済みソフトウェアなど、ここには Cygwin に関して必要な全てがあります。
個々の GNU ツールに関するドキュメントは http://www.fsf.org/manual/ で参照することが出来ます (GNU のマニュアルはローカルのミラーで読むべきです。 それらのリストについては http://www.fsf.org/server/list-mirrors.html で確認して下さい)。
はい。幾つかは GNU ソフトウェア(gcc、gas、ld など)であり、 あるものは標準の X11 ライセンスで保護されています。 パブリックドメインなものもあれば、 Cygnus が書いて GPL に置かれたものもあります。シェアウェアはありません。 これらを使用するために、誰かにお金を支払う必要はありませんが、 これらのツールを使用する上で GNU General Public License がどのように影響を与えるかについての更なる詳細な情報を、 この FAQ の著作権の項を読んで確認しなければなりません。
特に、もし Cygwin を使って(GPL でない)商用アプリケーションを移植しようとしているのであれば、 Cygwin ライブラリの商用ライセンスが必要になるかもしれません。 このライセンスは購入可能です。更なる情報については http://www.redhat.com/software/tools/cygwin/ を参照して下さい。 その他の質問は全て、このプロジェクトのメーリングリストである cygwin@cygwin.com に送ってください。
我々が「フリー(free)」といった場合、価格のことを言っているのではなく、 自由を意味しているということを覚えておいて下さい。 このような自由の最終目的は、誰もががソフトウェアの一部分を自身の目的のために改変することが出来、 ソフトウェアについて学習することが出来、 ソフトウェアを彼らの友人達、そしてその他の人々と共有出来るというものです。 Cygwin ライセンスはそのような自由を提供するので、 これはフリーソフトウェアなのです。
インストールされている Cygwin DLL のバージョンを調べるには、Linux と同じように `uname' を実行するか、`cygcheck' を実行して下さい。 更なる情報については、それぞれのコマンドの `--help' の出力か、Cygwin ユーザーズガイド を参照して下さい。
Cygwin 全体のバージョン番号を調べたいとしても、そのようなものはありません。 Cygwin に含まれる各パッケージには、個別のバージョンがあります。 Cygwin に含まれるパッケージは継続して改良されており、Cygwin のバイナリ移植版をメンテナンスして下さっている、 ネット上のボランティアの方々の努力に感謝します。 各パッケージはそのパッケージ自身のバージョン番号を持っていますし、 そのパッケージ自身のリリース過程があります。
それでは、どのようにして最新バージョンの Cygwin を取得すればよいのでしょう? 簡単です。 http://cygwin.com/setup.exe から Cygwin Setup プログラムをダウンロードするだけです。 このプログラムはあなたのシステムにあるパッケージ群を最新バージョンにアップデートします。 Cygwin の `setup.exe' に関する更なる情報については、 Cygwin ユーザーズガイドの Cygwin のセットアップ を参照して下さい。
Cygwin をインストールするにあたって推奨される唯一の方法は、 GUI インストーラである「Cygwin Setup」を使用することです。 これは柔軟かつ簡単に扱うことが出来ます。 インストールしたいパッケージを選択することが出来ますし、 パッケージを個別にアップデートすることも可能です。 全てのパッケージ及びツールについて、全てのソースコードが利用可能です。 Cygwin Setup の利用方法に関する更なる情報については、 http://cygwin.com/cygwin-ug-net/setup-net.html を参照して下さい。
他の方法でインストールしたければ、その方法でどうぞ! GUI インストーラは「現在作業中」であり、 そして、特にあなたがファイアウォールの後ろ側にいるか、 又は他の特別な必要条件の元にいる場合は、 幾つかの困難が存在するということを忘れないで下さい。もし http://cygwin.com/setup-snapshots/ から手に入る最新の開発版スナップショットで何かうまくいかないことがあれば、 そしてどうしてもそれを解決出来ないのであれば、何とかしてその問題をメーリングリストに報告して下さい。
Cygwin と共にインストール可能なパッケージの一覧については、 http://cygwin.com/packages/ を参照して下さい。パッケージの検索も可能です。
Cygwin Setup プログラムは 唯一 推奨される Cygwin のインストール方法です。
Cygwin Setup プログラムは「ルート」ディレクトリを要求します。 デフォルトは `C:\cygwin' ですが、これは変更可能です。 Cygwin のルートとして「C:\」(システムドライブのルートディレクトリ) などを選択しないよう強く要請します。もしそうしたならば、 `etc'、`lib' そして `bin' のような Cygwin の重要なシステムディレクトリが、 `\etc'、`\lib' 又は `\bin' を使用する他の(Cygwin 用でない)アプリケーション又はパッケージによって簡単に汚されてしまいます。 おそらく現在は何のコンフリクトもないでしょうが、 しかしあなたが将来的にインストールしないと、誰が言えるでしょう? Windows のシステムディスクの他の部分から Cygwin の「ファイルシステム」を分離しておくこともまた良い常識です (かつて、Cygwin を `C:\' にインストールしていた場合に問題が発生するという、純粋なバグがありました。 しかし、今やそれはないと我々は信じています)。
Cygwin Setup は Cygwin のミラーサイトに置かれているあらゆるパッケージをインストールするために利用可能です。 通常、ミラーサイトには現在のバージョンの一つ前のバージョンも置かれています。 完全な一覧が必要であれば、 http://cygwin.com/packages/ を検索してみて下さい。過去のバージョンを保存した完全なアーカイブはありません。 Cygwin パッケージの現在のバージョンで何か問題があった場合は、 http://cygwin.com/problems.html にあるガイドラインに従って、メーリングリストに報告して下さい。
古いパッケージがどうしても必要なのであれば、古いパッケージバージョン(例えば `gcc2-2.95.3-10-src.tar.bz2')で Web を検索し、古いままになってしまっている、 或いはアーカイブを行っているミラーサイトを見つけることが出来るかもしれません。 しかし、心に留めておいて下さい。メーリングリストは古いバージョンをサポートしません。 そして古いバージョンをインストールすることは、Cygwin を改良する助けにはなりません。
そのようなことはありません。それが事実だと確認出来ない限り、 どうかそのことをメーリングリストで報告しないで下さい。
アンチウィルス製品は圧縮された tar アーカイブを展開する際に、 誤って陽性として検出することがあるとが知られています。
このような問題に遭遇した場合は、setup
を実行する際にアンチウィルスソフトウェアを無効化することを考えて下さい。
この作業を安全な方法で行うためには、次のエントリを参照して下さい。
Network Associates (以前は McAfee)の製品と Norton AntiVirus の両方については、 Cygwin の tar アーカイブを展開する過程で「ハング」 するという報告がなされています。 このような事態に陥った場合、Cygwin Setup を実行する際にアンチウィルスソフトウェアを無効化することを考えて下さい。 以下の手順に従えば、安全な方法でセットアップを行えます。
setup.exe をダウンロードし、それを明示的にスキャンします。setup.exe が悪意を持った誰かによって置き換えられてしまっており、 全てのミラーサイトに危険が及んでいないのであれば、これで安全でしょう。
最初に Cygwin Setup を起動した時点では、 デフォルトではパッケージ群の最小のサブセットがインストールされます。 もし全てのパッケージをインストールしたいのであれば、 明示的に選択する必要があります。 利用可能なパッケージの検索可能なリストについては、 http://cygwin.com/packages/ を参照して下さい。
プログラムをビルドするつもりであれば、無論 「Devel」カテゴリから `gcc'、+`binutils'、`make'、 そして恐らくは他のパッケージ群もインストールする必要があるでしょう。
大昔には全てのパッケージがデフォルトでインストールされていましたが、 それは多くのユーザを苛立たせるものでした。 現在ではパッケージの中核となるものだけがデフォルトでインストールされます。
Cygwin Setup はカテゴリのブラウズ、インストールしたいパッケージの選択、或いはこれらのカテゴリの省略が簡単に行えるようにデザインされています。 全てのパッケージをインストールするのもまた簡単です。
この手順は、現在入手可能なパッケージについてのみ適用出来ます。 これ以降、デフォルトで全てのパッケージをインストールすることを Cygwin Setup に伝える方法はありません。 新しいパッケージが入手可能になった場合、デフォルトではインストールされませんので、それらをインストールするためには上記の手順を繰り返す必要があります。
一般的には、(私の意見としては)より良い手順は以下の通りです。
それは明らかに、ダウンロードそしてインストールしたものに依存します。 完全なインストールを行った場合、今では恐らくは 800MB 以上となるでしょう。 この容量には、パッケージアーカイブ及びソースコードは含まれていません。
パッケージアーカイブはインストールした後も「ローカルパッケージディレクトリ」(デフォルトでは
setup.exe が置かれている位置)に残されています。
ここにあるサブディレクトリ群を削除することで、ディスクスペースを節約することが出来ます。
これらのディレクトリ群の名前はそれらの取得先の URL をエンコードしたものなので、非常に奇妙なものとなっています。
まず、最新版の Cygwin Setup を使用していることを確認して下さい。最新版は常に Cygwin のホームページ( http://cygwin.com/ )にある「Install Cygwin now」リンクから取得出来ます。
インターネットからダウンロードしている場合、 http://cygwin.com/mirrors.html にあるミラーのリストがダウンロード出来なければ setup は失敗します。 これはネットワークが混雑しているときに発生し得ますし、 ftp ダウンロードサイトが動作していないときも同様です。 他のミラーを試すか、後から再度試してみて下さい。
setup がアップグレードすべきパッケージのダウンロードを拒否する場合、 /etc/setup からパッケージのエントリを削除してみて下さい。 あなたがメーリングリスト上での告知に速やかに反応したとしても、 あなたが使用するミラーにはまだ最新のコピーが置かれていないかもしれません。 別のミラーを試すか、明日にでも再度試してみて下さい。
もし setup が別の奇妙な振る舞いを示すときは、 /var/log(デフォルトでは
{C:\cygwin\var\log です) にある
`setup.log' 及び `setup.log.full'
の両ファイルをチェックして下さい。 何がなぜ悪かったのかを示す手がかりが記されているかもしれません。
まだ駄目なようでしたら、手がかりを得るために Cygwin メーリングリストを検索して下さい。 他の人も同じ問題を抱えているかもしれませんし、 解決策が投稿されているかもしれません。 この検索が無益であると分かった場合は、 Cygwin メーリングリストで質問して下さい。 setup のバージョン、選択したオプション、 setup.log 及び setup.log.full の内容、 どのような事態が発生したのか、など、 質問には完全な詳細を記述する必要があります。
明らかに問題です! UNIX シェル(従って Cygwin も)はスペースを単語の区切りとして使用します。 特定の環境の元では、様々なシェルのクォートメカニズムのおかげでうまくいくことでしょうが、 もし完全に問題を避けることが出来るのであれば、 そのほうがずっと順調です。
特に、環境変数 `USER' と `HOME' は /etc/profile 内で設定されます。デフォルトでは、これらは Windows のログオン名から決定されます。 確実にスペースが含まれないように両変数を設定するために、 このファイルを編集しても差し支えありません。
(もし `login' パッケージを使用するか、 あるいは他のパッケージが /etc/passwd を読むのであれば、 それに対応した変更をかける必要があるかもしれません。 それらのパッケージの README ファイルを参照して下さい。)
パッケージをインストールするときと同じように、 Cygwin Setup を実行します。 インストールするパッケージのリストで関連するカテゴリをブラウズするか、 完全なリストが表示されるまで「View」ボタンをクリックします。 アクションとして「Uninstall」が表示されるまで回転記号をクリックし、 「Next」をクリックして作業を継続します。
setup は自動アンインストールの機能を持っていません。 以下の全てを手動で削除するだけです。
HKEY_LOCAL_MACHINE あるいは
HKEY_CURRENT_USER の下にある `Software\Cygnus
Solutions' レジストリツリーinetd サービスのインストール、システムパスの変更などといった、 システムに起こした他の変更をどのようにするかはあなた次第です。 setup はこれらに対しては、いかなる変更も行っていません。
まず最初に、スナップショットは貴方にとって本当に必要なものでしょうか? スナップショットは危険なものです。スナップショットはテストされていません。 試すべき機能又はバグフィックスがあり、そしてあらゆる問題に対応するつもりがある場合のみ使用して下さい。
スナップショットをインストールして cygwin1.dll
を更新する前に、シェルやサービス(inetd や sshd など)を含む全ての Cygwin
アプリケーションを終了しておきます。 メモリから DLL をクリアするために、Windows
を再起動する必要があるかもしれません。
Setup を利用してスナップショットをインストールすることは出来ません。
通常は DLL だけでなく cygwin-inst-YYYYMMDD.tar.bz2
全体をインストールすべきであり、 そうしなければば幾つかのコンポーネントと同期が取れなくなるかもしれません。 Cygwin の tar
は /usr/bin/cygwin1.dll
をアップデートすることは出来ませんが、他の手段によって行うことは可能です。
cd /
tar jxvf /posix/path/to/cygwin-inst-YYYYMMDD.tar.bz2 --exclude=usr/bin/cygwin1.dll
cd /tmp
tar jxvf /posix/path/to/cygwin-inst-YYYYMMDD.tar.bz2 usr/bin/cygwin1.dll
C:\cygwin\tmp\usr\bin\cygwin1.dllを
C:\cygwin\bin\cygwin1.dll へと移動します。いいえ。Cygwin Setup ではそのようなことは出来ません。 そのような目的のために設計されたツールを利用して下さい。 この目的を果たすユーティリティについては、 http://rsync.samba.org/、 http://wget.sunsite.dk/ を参照して下さい。 Cygwin パッケージのサーバを立てるための更なる情報については、 http://sources.redhat.com/cygwin-apps/setup.html. にある Cygwin Setup のホームページを参照して下さい。
Cygwin をインストールした後であれば、沢山のドキュメントが `/usr/share/doc/' 以下で見つかるでしょう。 多くのパッケージは標準的な文書と共に提供されており、それらは `/usr/share/doc/パッケージ名' 以下に置かれています。 加えて、幾つかのパッケージでは `/usr/share/doc/Cygwin/パッケージ名.README' というファイル中に Cygwin 特有の説明が書かれています。 他の古いパッケージは、未だにドキュメントを `/usr/share/doc/' ではなく、`/usr/doc/' 内に置いています。
Cygwin プロジェクトの WWW ページである http://cygwin.com/ には、非常に多くのリンクがあります。最低限、メインの Web ページにある「Release Notes」又は「Readme」、或いは「read this」のいずれかは読んでおきましょう。 何か書いてあるかも知れません。
包括的な Cygwin ユーザーズガイドは http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html に、API リファレンスは http://cygwin.com/cygwin-api/cygwin-api.html にあります (1)。
個々の GNU ツールに関するドキュメントは http://www.fsf.org/manual/ で参照することが出来ます(GNU のマニュアルはローカルのミラーで読むべきです。それらのリストについては http://www.fsf.org/server/list-mirrors.html で確認して下さい)。
Cygwin メーリングリストに関する包括的な情報は http://cygwin.com/lists.html で参照出来ます (2)。
メインのメーリングリストに参加するには、cygwin-subscribe@cygwin.com にメッセージを送って下さい。メインのメーリングリストから退出するには cygwin-unsubscribe@cygwin.com にメッセージを送ります。 どちらの場合でも、サブジェクトとメッセージ本文は無視されます。
同様に、Cygwin のアナウンス用のメーリングリストに参加するには cygwin-announce-subscribe@cygwin.com にメッセージを送ります。退出するには cygwin-announce-unsubscribe@cygwin.com にメッセージを送ります。
本プロジェクトに対するボランティアとして Cygwin ライブラリの開発に関わるつもりであれば、cygwin-developers と呼ばれる Cygwin 開発者用メーリングリストに参加したくなるかもしれません。 ライブラリそれ自身よりも、Cygwin ツールやアプリケーションに貢献するのであれば、cygwin-apps に参加すべきでしょう。 参加方法は最初に記述した二つのメーリングリストと同様です。 cygwin-developers と cygwin-apps は承認制のメーリングリストです。
メインのメーリングリストの検索可能なアーカイブは http://cygwin.com/ml/cygwin/ にあります。やはり検索可能な別のアーカイブが http://www.delorie.com/archives/ にあります。検索語に「cygwin」を含めて http://www.google.com/ で検索することも出来ます。
Cygwin メーリングリストは USENET にゲートウェイされていませんので、電子メールアドレスに対する SPAM よけの工夫は必要ありませんし、評価もされません。HTML で記述されたメールも Cygwin メーリングリストには送信しないで下さい。
これらのガイドラインに従えば、Cygwin 開発者又は一般の Cygwin コミュニティからずっと役に立つ反応を得ることが出来るでしょう。
もし上記のガイドラインに従わなければ、反応を引き出すことは出来ても、感謝することはないでしょう。
サポート契約や商用ライセンスに関するお問い合わせについては、 http://www.redhat.com/software/cygwin/ を参照して下さい。
その向こうでは、おそらく誰もあなたの質問に答える時間がないのでしょう。或いは、誰も答えを知らないのかも知れません。
最近アップグレードを行った後で、急に vim(や他の Cygwin アプリケーション)が
「cygncurses5.dll が見つかりません」といって失敗するようになった場合、 あなたは
http://cygwin.com/ml/cygwin-announce/2001/msg00124.html
に示された手順に正しく従っていません。 この問題を解決するためには、Cygwin Setup を再度実行して
`libncurses5' を再インストールする必要があります。
デフォルトでは、Cygwin Setup はこのオプションを示さないことに注意して下さい。 「Select packages to install」ダイアログで `Full/Part' ボタンをクリックします。これによって、 既にインストール済のものも含めて全パッケージが表示されます。 下へスクロールして `libncurses5' を探し出し、 「Reinstall」と表示されるまで「回転」記号をクリックし、 インストール作業を継続します。
同様に、もし何らかのパッケージが「cygintl.dll が見つかりません」といった場合、Cygwin
Setup を実行して `libintl' と
`libintl1' パッケージを再インストールして下さい。
一般的な問題に関する詳細な説明、そしてこの問題を(cygreadline5.dll のような)他の「見つからない」DLL に展開する方法、 そしてそれらの DLL が含まれているパッケージを探し出すには、 http://cygwin.com/ml/cygwin/2002-01/msg01619.html を参照して下さい。
つい最近 `cygwin' パッケージをアップグレードした後で、
全てのコマンドの実行に非常に長い時間がかかるのであれば、 恐らく既に過去のものとなった
//c 記法が PATH 中に含まれていることでしょう。
現在では、この記法はネットワーク共有 c
を意味します。そしてそのような共有が存在しない場合、 途方もなく遅くなってしまいます。次の FAQ エントリを参照して下さい。
(例えば Z: に対する //z のように、
全てのドライブ文字に対して当てはまります)
この「機能」は長い間非難されてきており、 今後の全ての最新版リリースにおいて、もはや動作しません。 リリース 1.3.3
では、//c は ネットワーク共有 c を意味します。
なぜこのような変更が行われたかに関する詳細な議論について、 そして今ではどのように取り扱われるかについては、 http://sources.redhat.com/ml/cygwin/2001-09/msg00014.html を参照して下さい。
setup.exe によって作成される /etc/profile で全ての設定は完了しています。
このファイルはデスクトップ又はスタートメニューから bash を起動した際に読み込まれ、その内容は以下のようになっています。
PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
実際のところ、この設定は /usr/local/bin と /usr/bin を Windows
システムのパスへと追加します。 もし PATH をリセットしたいのであれば、以下のルールに従って
$HOME/.bashrc に設定するか、又は直接 /etc/profile を編集して下さい。 PATH
の設定時には、/usr/bin を全ての Windows
システムディレクトリの前に設定する必要があります (そして
Windows システムディレクトリを省略してはなりません!)。 そうしなければ、おそらく Cygwin
アプリケーションの実行時にあらゆる問題に遭遇することになります。
プログラムをコンパイルしたのに、 それが実行できないように見えるかもしれません。
bash$ gcc -o hello hello.c
bash$ hello
bash: hello: command not found
Windows とは異なり、デフォルトでは bash はプログラムを `.'(カレントディレクトリ)からは探しません。 PATH(上記を参照)に `.' を追加することも出来ますが、 セキュリティ上の理由から、(少なくとも UNIX では)推奨されません。 bash にどこから探すかを伝えるには、 コマンドライン上でこのようにタイプします。
bash$ gcc -o hello hello.c bash$ ./hello Hello World!
「cypath」ユーティリティを使用します。 使用方法を知るためには、cygpath --help
を実行します。 例えば(私の環境では)、
bash$ cygpath --windows ~/.bashrc D:\starksb\.bashrc bash$ cygpath --unix C:/cygwin/bin/cygwin.bat /usr/bin/cygwin.bat bash$ cygpath --unix C:\\cygwin\\bin\\cygwin.bat /usr/bin/cygwin.bat
bash が「\」をエスケープキャラクタとして扱うことを覚えておいて下さい。 そのため、「\」を認識させるには bash シェル上で二回タイプする必要があります。
.bashrc は環境変数 HOME が示すホームディレクトリから読み込まれます。 HOME が設定されていない場合は /.bashrc が読み込まれます。 正しく HOME を設定するか、.bashrc を Cygwin の / としてマウントされたドライブの最上位に移動する必要があります。
~/.bashrc ファイルに以下を追加して下さい。
shopt -s nocaseglob
また、~/.inputrc ファイルに以下を追加して下さい。
set completion-ignore-case on
Cygwin はファイル名やパス名の中のスペースはサポートしません。 つまり、このライブラリを使ったユーティリティは動かないかもしれない、 ということです。通常、UNIX ではファイルにスペースは含まれないからです。 もしあなたがこの問題に引っかかってしまったら、 そのユーティリティを修正するか、 Cygwin ツールでスペースのあるファイル名を使うのをやめるかするしかありません。
特に、bash はスペースを単語の区切りとして認識します。 スペースを含んだファイル名はクォートするか、 スペース文字をエスケープする必要があります。例えば、
bash-2.03$ cd '/cygdrive/c/Program Files'
又は、
bash-2.03$ cd /cygdrive/c/Program\ Files
のようにします。
これはバージョン 1.3.0 未満のバージョンに対してのみ有効です。
Cygwin は Windows Explorer ショートカット(*.lnk ファイル)を辿りません。 ショートカットは通常のファイルとみなされるので、その中には「cd」出来ないのです。
中には現在のシンボリックリンクの仕組みをショートカットで置き換えることを提案する人もいます。 これに関する一番の問題は、Cygwin パスのシンボリックリンクを使った .LNK ファイルは、Explorer などのような非 Cygwin の Win32 ネイティブアプリケーションにとっては、正しいかもしれないし、正しくないかもしれないということです。
バージョン 1.3.0 以降、Cygwin はショートカットをシンボリックリンクとして扱います。
Cygwin ツールに付属している find を使っていること、つまり間違って Win32 の find コマンドを使っていないことを確認して下さい。 正しいものを使っていることを確認するには、bash から「type find」を実行します。
find に対するパス引数(デフォルトではカレントディレクトリも含む)それ自身がシンボリックリンクである場合、find は `-follow' オプション (3) が指定されない限りそれを参照しません。 この動作は他の多くの UNIX の実装とは異なりますが、これは変更されそうにはありません。
満足のいく結果が得られないように思われる場合、或いは幾つかのディレクトリが見つからない場合、find による最適化に付随する問題に遭遇したのかもしれません。 DVD-R UDF のような、`.' や `..' が欠如したファイルシステムでは、find は正しく動作しません。 マニュアルページでオプション `-noleaf' の説明を調べてみて下さい。
かつて存在した `su' は一旦 Cygwin ディストリビューションから外されており、Cygwin に移植されることも、動作することもありません。現在は sh-utils の一部として再びインストールされるようになりましたが、動作しません。
代わりに `login' を使うことが出来ますが、まず最初に http://www.cygwin.com/ml/cygwin/2001-03/msg00337.html を読んで下さい。
`su' が動作しない技術的な背景については、 http://www.cygwin.com/ml/cygwin/2003-06/msg00897.html 及びリリースメッセージを参照して下さい。
`man' パッケージをインストールした後でさえ、このようなエラーを受け取ることがあります。
bash-2.04$ man man Error executing formatting or display command. System command (cd /usr/man ; (echo -e ".pl 1100i"; cat /usr/man/man1/man.1; echo ".pl \n(nlu+10") | /usr/bin/tbl | /usr/bin/groff -Tascii -mandoc | less -is) exited with status 32512. No manual entry for man
`ash' パッケージに含まれている /bin/sh が必要ですので、これもインストールしなければなりません。
更に、`man -k' 又は `apropos' を利用する前に whatis データベースを作成しておく必要があります。 これには以下のコマンドを実行します。
/usr/sbin/makewhatis
(完了するまでには少し時間がかかります)
`ntsec' は Windows NT の NTFS ファイルシステム上で UNIX パーミッションを実現します。 (最近の変更によって)これはデフォルトになっています。
`ntea' は NTFS 及び FAT 上で動作しますが、 FAT ファイルシステム上では巨大で削除出来ないファイルを生成します。
(`ntsec' 及び `ntea' は環境変数 `CYGWIN' に設定する値です。 この変数と設定方法についての更なる情報は、 http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html にある Cygwin ユーザーズガイドを参照して下さい。)
全ての Windows 9x では対応出来ません。
もしファイルに対して特定のパーミッションを要求するアプリケーションがあるなら、 アプリケーションのソースコードを修正することでこの問題を回避することが出来るかもしれません。 Corinna Vinschen による OpenSSH に対する変更がヒントになるでしょう。 Cygwin メーリングリストのメッセージ http://cygwin.com/ml/cygwin/2000-11/msg01176.html を参照して下さい (4)。
不幸なことに、このようなことは出来ません。
bash$ mkdir -p //MACHINE/Share/path/to/new/dir mkdir: cannot create directory `//MACHINE': No such file or directory
mkdir はパス中の個々のディレクトリの存在を確認し、必要であればそれを作成するからです。 `//MACHINE' はディレクトリではありませんが(そこへは cd 出来ません)、mkdir はそれを作成しようとし、そして失敗します。
いつかは修正されるかもしれませんが、今のところはこのようにする必要があります。
bash$ cd //MACHINE/Share bash$ mkdir -p path/to/new/dir
実行するには二つの本質的な問題があります。 一つは、/bin/sh は実際には ash であり、特に /bin/sh を bash(Linux) や ksh(Tru64) と見なして利用しようとした場合には、/bin/sh に期待される幾つかの機能が欠けているからです。例えば、
或いはパーミッションの問題であり、Cygwin はあなたのスクリプトを実行形式だと認識しなかったのでしょう。 `chmod' が動作しないので(FAQ の上記項目を参照)、Cygwin はスクリプトが実行可能かどうかを、ファイルの内容を読んで判断しなければなりません。もしあなたのスクリプトが
#! /bin/sh
で始まっていなければ(或いは /bin/sh に限らず、任意のスクリプトのインタプリタ)、Cygwin はそれが実行可能なスクリプトであることを知ることが出来ません。Bourne シェルの慣用法である
: # これは 2 行目で、/bin/sh が処理することを仮定しています。
もまた有効です。
`mount -x' を使えば、Cygwin はマウントポイント以下の全ファイルを実行可能として取り扱うということを覚えておいて下さい。 これはディレクトリだけでなく、個々のファイルのために使用されます。 そして Cygwin はそれらが実行可能であるかどうかを判定するためにわざわざファイルを読み込みません。
UNIX 上に存在する lp や lpr システムは動作しません。
Jason Tishler は(テキストを正しく PostScript に整形する) a2ps と (PostScript ファイルを PostScript 非対応の Windows プリンタで印刷する) ghostscript の利用方法について説明した二通のメッセージを書きました。 http://cygwin.com/ml/cygwin/2001-04/msg00657.html から始めましょう。`file' コマンドは現在、Cygwin セットアップの一部分として利用可能になっていることに注意して下さい。
NT 上では代わりに、Windows の `print' コマンドが利用出来ます(これは Win9x 上では動作しないようです)。
bash$ print /\?
をタイプすれば利用方法が表示されます(`?' をシェルからエスケープする必要があることに注意して下さい)。
最後に、ファイルをプリンタの共有名に対して単純に `cat' することも出来ます。
bash$ cat myfile > //host/printer
プリンタの用紙送りボタンを押すか、用紙送り文字をファイルに追加する必要があるかもしれません (5) 。
bash 上で国際化文字をタイプする前に、 以下の行を ~/.inputrc
ファイルに追加しなければなりません (6) 。
set meta-flag on set convert-meta off set output-meta on
これらは readline ライブラリに対するオプションです。 詳細については
bash(1) 及び readline(3) の man ページを参照して下さい。
less や ls のような、readline を利用していない他のツールで 8
ビット文字を表示させるには、追加の設定が必要です。 ~/.bashrc
に以下の内容を記述して下さい。
alias less='/bin/less -r' alias ls='/bin/ls -F --color=tty --show-control-chars'
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
慎重な実験によって、カーソルキーが実用的ではなく、むしろ奇妙に振舞うことが分かります。 例えば、NumLock がオフであれば、数値キーパッドのキーは通常のカーソルキーを押すまで動作しますが、個々の数値キーが動作しないときに数値/文字キーを再度タイプすれば、カーソルキーは再び動作し始めます。 この現象は Win98 と Win95 の地域化バージョンで発生すると報告されており、Cygwin に特有のものではありません。これらは Alt+Enter(フルスクリーン/ウィンドウの切り替え)が動作せず、他のプログラムに移り続けるという問題として知られています。 この問題の原因は、デフォルトで「autoexec.bat」にインストールされる Microsoft のキーボードローカライザです。このような行がそうです(これはロシア語用ロカールです)。
keyb ru,,C:\WINDOWS\COMMAND\keybrd3.sys
キーを正しく動作させるためには、このような行をコメントアウトする必要があります。 勿論、これは使用している各地域用のアルファベットキーボードのサポートを剥奪するため、他のローカライザを使用することを考える必要があるでしょう。 例えば、ロシアのユーザは勿論 Keyrus ローカライザのことを知っていますし、キーボードエディタを使用すればそれは他のロカールででも動作するでしょう。しかし、それにはロシア語メッセージと文書しかありません ;-( 参考となる URL は http://www.hnet.ru/software/contrib/Utils/KeyRus/ です(Keyrus を正しく動作させるためには、Windows ロゴ表示を切る必要があるかもしれません)。
システム内には Cygwin DLL のコピーは一つだけにしておくべきです。 複数のバージョンが存在する場合、衝突して問題を起こすことでしょう。
「shared region is corrupted(共有領域が汚染されている)」又は 「shared region version mismatch(共有領域のバージョンが合致しない)」 というエラーが出た場合、複数のバージョンの cygwin1.dll が同時に動作していることを意味します。 例えば、あらかじめ全ての Cygwin アプリケーション(inetd を含む) を終了させずに cygwin1.dll をアップデートしたような場合、 この事態が発生します。
DLL がまだメモリ中にロードされているということが原因ですので、 この問題を起こす複数のバージョンの DLL を発見するには、 まずリブートします。続いて、Windows システムの検索ユーティリティを使い、 PATH(「type」が使用します)に含まれている部分、 又は Cygwin がマウントしているファイルシステム (Cygwin の「find」が使用します)だけでなく、 マシン全体を検索します。
「more」ページャを探しているのであれば、 その代わりに「less」ページャを使いましょう (7)。
恐らく、誰もそれをメンテナンスしていないからでしょう。 それは時間がかかる作業ですし、Cygwin チームの最優先事項は Cygwin パッケージです。残りはボランティアの努力によるものです。 協力したいですか? それでは以下を参照下さい。
幾つかの柔軟性があります。
Cywin はマウントされていないドライブ用に、組込みの「cygdrive プレフィックス」を備えています。 任意のドライブ、例えば Z: の場合は「/cygdrive/z/」でアクセス出来ます。
幾つかのアプリケーション(特に bash)では、Windows のバックスラッシュ(「\」)の代わりに POSIX のスラッシュ(「/」)を使って、慣れ親しんだ Windows の <drive>:/path/ が使用できます (しかし以下の警告を参照して下さい!)。 これは分かりきった方法での Windows パスへのマップですが、しかし内部的には以下の(デフォルト、又は明示的な)マウントに従って、Cygwin パスを使用するために変換されています。 デフォルトの設定では、例えば、
bash$ cd C:/Windows bash$ pwd /cygdrive/c/Windows
そして
bash$ cd C:/cygwin bash$ pwd /
です。Windows パスにバックスラッシュも使用できますが、それらはシェルからエスケープされねばならないでしょう。
警告: 異なるマウントポイントを経由した異なる POSIX パスが同じ Windows ディレクトリへとマップされ得るため、Windows パスを POSIX パスに変換する際には幾つかの曖昧さが存在します。 異なるマウントポイントがそれぞれ binmode 又は textmode であることがあり、Cygwin アプリケーションの動作はここで得られる POSIX パスに非常に依存したものであるため、これは問題になります。
POSIX パスへのマウントされたドライブを明確化することで、この Windows パスの曖昧さと、「/cygdrive」とタイプすることを避けることが出来ます。 例えば、
bash$ mkdir /c bash$ mount c:/ /c bash$ ls /c
これにより、`/cygdrive/c/Windows' はよりタイプ量の少ない `/c/Windows' になります。
ドライブのマウントは一回だけ必要であることに注意して下さい。 マッピングはレジストリに保持されるので、マウントはほぼ無期限で有効です。 umount、又はレジストリエディタだけがマウントを削除します。
mount への「-b」オプションは、テキスト及びバイナリファイルを同等に扱う バイナリモード(「binmode」)でマウントします。 これは open 呼び出しにバイナリフラグが付与されていない、悪い移植がなされた UNIX プログラムに対してのみ必要です。 デフォルトの Cygwin のインストールでは、/、/usr/bin そして /usr/lib もこの設定になっています。 新しいマウントへのデフォルトはテキストモード(「textmode」)であり、全ての「cygdrive」マウントのモードもそうなっています。
デフォルトの `cygdrive' プレフィックスと、それが binmode 又は
textmode のどちらを使用するのかは、mount
コマンドを使用して変更することが出来ます。例えば、
bash$ mount -b --change-cygdrive-prefix cygdrive
は /cygdrive/... マウントを binmode へ変更します。
まず、標準のコンソールウィンドウの代わりに rxvt を利用することを検討して下さい。 rxvt では、左マウスボタンで選択することによってコピーが、中央のマウスボタンでペーストが出来ます。 なんて簡単なんでしょう!
Windows NT では、コンソールウィンドウのプロパティダイアログを開きます。 「簡易編集モード」のトグルボタンがありますので、それを ON にしてプロパティを閉じます。
Windows 9x では、コンソールウィンドウのプロパティダイアログを開きます。 「その他」タブを開き、「高速ペースト(Fast Pasting)」のチェックを外し、「QuickEdit」をチェックします。
.inputrc ファイルに以下の行を追加すれば、クリップボードからペーストするための機能を insert キーにバインドすることも出来ます。
"\e[2~": paste-from-clipboard
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
通常、これは既ににマウントされている場所に更にマウントしようとしているという意味です。 例えば、c: が「/」にマウントされているとして、d: を同じようにマウントしようとするとこのエラーメッセージが出ます。 まず古いものを「umount」して、それから新しいものを「mount」すればよいでしょう。
もし '/' を umount
しようとしたときにこのメッセージが出たのであれば、regedit.exe を起動して
HKEY_CURRENT_USER/Software/Red Hat, Inc./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 のパス操作コードを書き直すときに削除することに決めました。 標準の Windows アプリケーション -- explorer.exe、cmd.exe/command.com など -- は大文字 / 小文字だけの違いだけではファイル名の違いを区別しません。 結果として幾つかの(重大な)望まざる動作が生じます。
Sergey Okhapkin は B20.1 まで mixed-case パッチ(「coolview」)を保守していましたが、これは最近のバージョンの Cygwin 用にはアップデートされていません。
ファイル名として(幾つか例を挙げれば) com1、lpt1、aux は使えません。 ファイル名の基幹部分としても、拡張子部分としてもです。 もし使ってしまうと面倒が起きるでしょう。 UNIX プログラムはこれらの名前を避けるような楽しいことはしてくれません。 例えば、 perl のディストリビューションの中には aux.sh というファイルがあります。perl のコンフィグレーションでは aux.sh ファイルが存在することを確認しようとしますが、「aux」という魔法の文字が含まれているファイルを操作しようとしてハングしてしまうでしょう。
何かがおかしくなって、何らかの理由でツールが帰ってこなくなった場合(aux.sh というファイルを読んでみれば簡単にこの状態になります)、まず ^C を叩き、bash あるいは cmd プロンプトに戻ってみて下さい。
別のシェルを起動してもアプリケーションが動かないのであれば、暴走したプロセスがまだどこかで動いてると考えるべきです。 タスクマネージャ、pview、或いは同様のユーティリティを使ってそのプロセスを殺して下さい。
そして、もし全てが失敗したとしても、リセットボタン / 電源スイッチはいつでもあります。 これは Windows NT では必要ないはずですが。
なぜ /lib と /usr/lib (そして /bin と /usr/bin)が同じものを指しているのでしょうか?
なぜシンボリックリンクの代わりにマウントを使用するのですか?
(C:\ のような)ディスクルートを Cygwin のルートとして使用できますか? なぜそれは禁止されているのですか?
デフォルトの場所に新規にインストールした直後は、マウントポイントは以下のようになっています。
bash$ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode)
(厳密には、これは setup.exe に対して与えたオプションに依存します)
/bin と /usr/bin、/lib と /usr/lib が同じ場所を示していることに注意して下さい。 これは内部的なものであり、自分が何をしているのかについて本当に理解していない限り、これを変更するべきではありません。
様々なアプリケーションとパッケージは /lib 又は /usr/lib(/bin 又は /usr/bin も同様)がインストールされていることを期待しています。 それらの間の区別、そしてそれらに絶えず注意を払うよりも(もしかすると、時々複製やシンボリックリンクが必要となるかもしれません)、 同じ方法でアクセス出来るたった一つの実在のディレクトリをメンテナンスすることに決めました。
この目的のためにシンボリックリンクを使用することも考えましたが、Samba ドライブ上では常に正しく動作するわけではないので、この案は却下されました。 マウントを解決する際にディスクアクセスは必要ないため、マウントはより高速であるというのも理由です。
非 Cygwin アプリケーションは Cygwin のマウントを検知しないことに気をつけて下さい(シンボリックも同様)。 例えば、仮に Cygwin パッケージの tar 配布物を展開するために WinZip を使用したとしても、正しい Cygwin パスへとはインストールされないでしょう。 そのようなことは行わないで下さい!
何を行っているのかを知らないのであれば、そしてその結果に対する心構えがないのであれば、ドライブのルートディレクトリと Cygwin のルートディレクトリを同一にしないことを強くお奨めします。 例えば C:\ から Cygwin のファイル階層を分離しておくことは、一般的に Cygwin のファイル階層を管理しやすくします。 第一、(例えば) \bin や \lib を作成する他の(非 Cygwin)アプリケーションとの起こりうる衝突を避けられます(そのようなアプリケーションを今はインストールしていなくとも、将来的にインストールしないと誰が言えるでしょうか?)。
ある方の報告では、 NT 用(他のものもか?)の NAI(以前は McAfee) VirusScan は Cygwin とは相容れないとのことです。 cygwin.dll の中で新しくロードされた共有メモリをスキャンしようとするため、結果として fork() が失敗し、多くのツールに大破壊をもたらします。
NAI VirusScan のせいで、tar.gz アーカイブを展開する際にシステムがハングするという報告が幾つもあります。 これは恐らく VirusScan のバグであり、NAI に対して報告されるべきでしょう。 正しく動作させる唯一の方法は、これらのファイルにアクセスする際に VirusScan を無効にしておくことです。 これはセットアップの際に問題となるかも知れないので、FAQ の項目中でも議論されています。
何人かのユーザは、それらのアンチウィルスソフトウェアが有効になっていると、Cygwin
の使用中に重大なパフォーマンス低下が発生すると報告しています。
完全にアンチウィルスソフトウェアを無効にしてしまうよりも、特定のディレクトリの内容をスキャンしないように指定するほうがよいでしょう。
デフォルトのインストールでは `C:\cygwin\bin'
に相当します。 悪意のある 非 Cygwin プログラムから利用され得るのは明らかですので、自己責任でお願いします。
はい! X11 (`http://cygwin.com/xfree/')の Windows インタフェースで利用出来ます。 リモートログインシェルからであれば、「emacs -nw」が正しく動作します。 非 X11 バージョンの Emacs もまた、テキストのみのターミナルインタフェース用に用意されています。 いずれ(或いはその両方)も、Cygwin Setup を利用してインストールすることが出来ます。
X を利用せず、ネイティブの Microsoft Windows のインタフェースを利用して GNU Emacs を利用したいのであれば、一般的に「NT Emacs」として知られている Emacs の Windows 移植版を利用する必要があります。NT Emacs は GNU のミラーサイトから入手可能です。 これを Cygwin Setup から取得することは出来ません。
NT Emacs は、デフォルトでは Windows のコマンドシェルを使用します。 Emacs は Cygwin アプリケーションではないので、Cygwin のマウントについては関与しません。 これらの点を念頭において、bash を使用するためには以下のコードを ~/.emacs(又は ~/_emacs)に記述する必要があります。これは特に JDEE パッケージ( http://jdee.sunsite.dk/ ) を使用するために有用でしょう。以下の設定は Emacs 21.1 用のものです。
;; Cygwin は C:\cygwin(デフォルト)にインストールされており、
;; C:\cygwin\bin が既に Windows パスに含まれていないことを
;; 仮定しています(一般にはそうではない筈ですが)。
;;
(setq exec-path (cons "C:/cygwin/bin" exec-path))
(setenv "PATH" (concat "C:\\cygwin\\bin;" (getenv "PATH")))
;;
;; NT-emacs は、ここで変更する Windows コマンドシェルを
;; 使用します。
;;
(setq process-coding-system-alist '(("bash" . undecided-unix)))
(setq shell-file-name "bash")
(setenv "SHELL" shell-file-name)
(setq explicit-shell-file-name shell-file-name)
;;
;; これは、Java アプリケーションの出力に出現する
;; 見苦しい ^M 文字を削除します。
;;
(add-hook 'comint-output-filter-functions
'comint-strip-ctrl-m)
もし NT Emacs に Cygwin パスを理解させたいのであれば、cygwin-mount.el を http://www.emacswiki.org/elisp/index.html から手に入れて下さい。
XEmacs の現在の状態に関する簡単な説明については、Cygwin メーリングリストに流れた `http://cygwin.com/ml/cygwin/2002-11/msg00609.html' の内容を参照して下さい。
はい! 代わりに rxvt を利用して下さい。これは Cygwin Setup で入手可能なオプショナルパッケージであり、X11 なしでも利用可能です。 ウィンドウの端又は角をドラッグすることによって簡単にサイズを変更することが出来ますし、マウスの左及び右ボタンをそれぞれ利用することによって、簡単にコピーとペーストを行うことが出来ます。 rxvt は X こそ利用しませんが、~/.Xdefaults の設定は利用します。
単純に「rxvt」を起動することは避けて下さい。なぜなら、rxvt は対話的シェルとしてはあまり良くない
/bin/sh(実際には ash)を起動するからです。 詳細については
/usr/share/doc/Cygwin/rxvt-<バージョン>.README
を参照して下さい。
Cygwin パッケージはそのパッケージの info ドキュメントを /usr/share/info
ディレクトリにインストールします。 しかし、事前にそのディレクトリ中に、スタンドアロンの info プログラム(恐らく
/usr/bin/info) がそれらの info ファイルを読む際に使用する
dir ファイルを作成しておく必要があります。このようにします。
bash$ cd /usr/share/info bash$ for f in *.info ; do install-info $f dir ; done
このような警告が出るでしょう。
install-info: warning: no info dir entry in `gzip.info' install-info: warning: no info dir entry in `time.info'
install-info コマンドはこれらのファイルをパース出来ないので、
それらのエントリについては手で /usr/share/info/dir
に追加しなければならないでしょう。
dir ファイルが既に存在したとしても、新しい Cygwin パッケージをインストールしたならば dir ファイルを更新する必要があります。 幾つかのパッケージはあなたに代わって dir ファイルを更新してくれますが、大部分のパッケージはそんなことはしてくれません。
「Out of queue slots!」は通常、削除する権限のないファイル(パーミッションがない、排他的に使用中である、など)を数多く消去しようとしたときに発生します。 何が起こるかというと、Cygwin はこれらのファイルは後で削除出来るようになるであろうという仮定のもとに待ち行列に入れてしまうのです。 そのファイルのパーミッションが後で変更されたとすると、そのファイルは要求通りに削除されるでしょう。 しかし、アクセス出来ないファイルを削除する要求があまりに数多く発生するとキューが溢れてしまうので、質問のメッセージが発生するのです。 通常は、すぐに chmod する、ファイルを閉じる、などによって対処することが出来ます(Larry Hall 氏に説明を頂きました。感謝します)。
シンボリックリンクには「system」ファイル属性が付与されますが、デフォルトでは samba はこの属性をサポートしていません。 これを有効にするには、Samba のドキュメントを参照し、Samba の設定ファイルに以下の行を追加して下さい。
map system = yes create mask = 0775
0010 ビットが設定されている限り、0775 は何でもあるかもしないことを覚えておいて下さい。
Win32 API 関数の GetFreeDiskSpace にはバグがあり、 2 GB 以上の大きさのディスクに対して誤った値を返してきます。 おそらくこれが問題なのではないでしょうか?
Cygwin と共に配布されている Tcl/tk のバージョン(例えば cygtclsh80.exe や
cygwish80.exe)は、実のところ Tcl/tk の「Cygwin 版」ではありません。これらは
gcc に `-mno-cygwin'
オプションを与えてコンパイルしたものです。これはつまり、Cygwin
のマウントやシンボリックリンクを理解しないということを意味します。
本 FAQ の「Windows パスと UNIX パスを変換するにはどうすればよいのですか?」の項を参照して下さい。
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 ライブラリ中に何か関心を惹くことが起こった時点で作られます(どれだけ進んだかにもよりますが、通常、おおまかには日次でです)。 これは主に、このプロジェクトにコードを寄贈しようとする方々のためのものです。 バグだらけのスナップショット内の問題をデバッグすることに興味がなければ、これを避けて本当のリリースを待ってください。 このスナップショットは http://cygwin.com/snapshots/ から取得できます。
まずはその背景から説明しましょう。
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 はそれを単に無視するだけです。
メーリングリストでの Earnie Boyd 氏 <earnie_boyd@yahoo.com> のメールを基に説明しました。
はい。そうです。
「POSIX スレッド」に対する広範囲ののサポートもあります。 提供されている POSIX
スレッド関数のリストについては、cygwin.din ファイルを参照して下さい。
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. (8)
しかし本当のところ、Windows 9x には殆どのセキュリティ関連の関数がなく、Win32 API の 1 バージョンとしては足りないものが他にも幾つかあります。 Win 9x において何がサポートされていないかについての情報は、calls.texinfo を参照してください。
Cygwin の fork() は、本質的に「non-copy on write」方式(古い UNIX のバージョンで取られていた方式)の fork() のように動作します。このため、多少遅いです。多くの場合、可能な限り spawn の類の呼び出しは使用しないほうが良いです。
fork() はこのように動作します。
親は、子のための Cygwin プロセステーブル領域を初期化します。 親は Win32 の CreateProcess に自分が起動されたときと同じパスを与えて、中断した子を生成します。 親は setjmp を呼び出してコンテキストを保存し、このポインタを Cygwin の共有メモリ領域にセットします(この領域は全ての Cygwin タスク間で共有されてます)。 親は子の .data と .bss サブセクションを、自分のアドレス空間から中断した子のアドレス空間へとコピーして埋めます。 そして親はその子を開始させます。親はミューテックス (9)を使用して、子が安全な地点に来るまで待ちます。 子は開始して fork されたのがわかったら、保存されたジャンプバッファを使って longjump します。 子は親が待っているミューテックスをセットし、そして親がスタックとヒープを埋めてくれるまで、別のミューテックス上でブロックします。 親は子が安全な領域に入ったことを知ってから、スタックとヒープを自分のものから子の中へコピーし、子が待っているミューテックスを解放して fork 呼び出しから戻ります。 子はブロックしているミューテックスから起きて、共有領域を通して渡された mmap 領域を再作成して、fork 自身から戻ります。
DOS スタイルのプロンプトから起動されたと DLL
が判断した場合、与えられたコマンドラインに対してファイル名の展開を実行します。 これはつまり、DOS から LS
*.EXE とタイプした場合、あなたが期待しているであろう動作を行う、ということです。
注意: ファイル名展開は malloc を使用します。 あなたのアプリケーションが
malloc を定義している場合、それが使用されます。 これはあなたにとっては恐ろしいことかもしれません
(10)。
Cygwin にはシンボリックリンクを作成するための二つの方法があります。
古い方法はバージョン 1.3.0 未満のバージョンに対してのみ有効です。 (1.3.0 以降では CYGWIN 環境変数に「nowinsymlinks」を設定することにより)この方法が有効であれば、Cygwin は魔法のヘッダ(magic header)を持つリンクファイルを生成します。 どこかへとリンクされているファイルまたはディレクトリをオープンすると、その魔法のヘッダに書かれているファイルまたはディレクトリをオープンします。シンボリックリンクかどうかを確認するために毎回全てのファイルをオープンしたくはないので、Cygwin はシステム属性でシンボリックリンクの印をつけます。 システム属性のついていないファイルはチェックされません。 リモートの samba ファイルシステムはシステム属性をサポートしていないので、システム属性を明確に有効にしていない限りネットワークドライブではシンボリックリンクは動作しません。
Cygwin バージョン 1.3.0 と共に導入された新しい方法は、デフォルト、或いは環境変数 CYGWIN に「winsymlinks」が設定されている場合に有効となります。 この方法を利用すると、Cygwin は Windows ショートカットを作成することでシンボリックリンクを生成します。 Cygwin は(Explorer が決して作成しないような)特別なヘッダを持ったショートカットを作成し、読み取り専用属性を設定します。通常、DOS パスはショートカットに格納され、記述エントリ(description entry)は POSIX パスを格納するために利用されます。 POSIX パスがこのように格納されている場合、DOS パスが有効なパスとなるように組替えることが必要となることがあります。 この処理はシンボリックリンクがマウントポイントを跨いで移動させられた際に、DOS パスと POSIX パスの間で相違が生じることにより発生します。 Cygwin ショートカットは「ls」の出力中では「.lnk」拡張子なしで表示されますが、非 Cygwin ショートカットは拡張子付きで表示されます。しかし、両者ともシンボリックリンクとして扱われます。
古いシンボリックリンクと新しいシンボリックリンクは平和的に共存出来ます。 Cygwin は環境変数 CYGWIN 中の「(no)winsymlinks」設定とは無関係に、両者をシンボリックリンクとして扱うからです。
ファイルに対して UNIX 形式の属性ビットを操作するときは、ライブラリは Win32 API では提供されていない幾つかの情報を埋めなければなりません。
ファイル名が .exe 及び .bat であれば実行可能と判断しますし、またファイルの先頭が「#!」であるものも同様です。
Cygwin はマルチユーザ環境では安全ではありません。 例えば、普通のユーザがログインするような環境で「inetd」のようなデーモンを Administrator 権限でずっと走らせたり、 あるいは誰かがコンソールからログインしている間に他のユーザがリモートからログインしたりすると、ある種の Cygwin クライアントは他のクライアントをだましてコードを実行させることができます。 この方法によってあるユーザは、そのマシンで動作している他の Cygwin プログラムの権限を得ることができてしまいます。 全てのプロセスからアクセス可能な共有状態を Cygwin が持っているからです。
(Tim Newsham (newsham@lava.net) 氏から説明を頂きました。 ありがとうございます。)
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
Cygwin におけるネットワークのサポートは、WinSock API ではなく UNIX API の提供を想定しています。
API 上は同じ名前の関数でも、意味の違う関数が存在します。
例えば、UNIX の select システムコールは標準ファイルハンドル及びソケットのハンドルに対して待つことができますが、 WinSock の select コールはソケットのみです。 このため、cygwin.dll はさまざまな WinSock/Win32 関数に、無理矢理 UNIX select と同じようなことをさせるために、裏ではかなり汚い手を使っています。
もし既に WinSock を使っているアプリケーションを移植しようとしているのであれば、 Cygwin のネットワークサポートを使用するのは間違っています。
しかし、Cygwin ではネイティブの WinSock も使用可能です。 cygwin.dll が export している関数は「cygwin_<name>」という名前です。 数多くのマクロ定義によって、標準の UNIX での名前から DLL で export されている名前への関連付けが行われています。include/netdb.h を覗いてみてください。
..(中略).. void cygwin_setprotoent (int); void cygwin_setservent (int); void cygwin_setrpcent (int); ..(中略).. #ifndef __INSIDE_CYGWIN_NET__ #define endprotoent cygwin_endprotoent #define endservent cygwin_endservent #define endrpcent cygwin_endrpcent ..(中略)..
標準 UNIX ヘッダファイルをインクルードすれば、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 のバージョン付けは比較的分かりにくいものとなっています。 まず最初に、1998
年 10 月以降の全ての Cywgin DLL は cygwin1.dll と命名されています。ここで、1
はリリース名です。 加えて、DLL にはリリース名に対応したメジャー番号及びマイナー番号があります。
つまり、cygwin-1.5.10-2 はメジャー番号 5、マイナー番号 10、リリース 2 の
cygwin1.dll ということです。
cygwin1.dll
のメジャー番号は、既存のソフトウェアに対する非互換性が発生した場合にのみ上がります。 例えば、メジャーバージョン 5
の最初のリリースである cygwin-1.5.0-1 では、64 ビットファイル I/O
操作が加えられました。これによって、多くのライブラリで再コンパイル及び再リンクが必要となりました。 マイナー番号の変更では、常に
Cygwin のリリースで後方互換性が維持されています。cygwin1.dll
のリリースバージョン番号もありますが、リリース番号は既存のリリースに対して、DLL
に対して何ら影響を及ぼさない変更(ヘッダファイルが不足していた、など)が加わった場合にのみ上がります。
Cygwin API のメジャー番号、及びマイナー番号もあります。このメジャー番号は、API の後方互換性を失わせるような重大な変更が行なわれるにつれて変化します。 以前のメジャー番号の DLL とリンクされた実行ファイルは、最新の DLL との互換性はなくなるでしょう。 マイナー番号は、意味のある API の追加や変更に対して変化します。 これは古い実行ファイルを壊すことはしませんが、再コンパイルしたものが必要になることがあります。
そして、共有メモリ領域の互換性バージョン番号があります。
これは共有メモリ領域やその他の名前付き共有ミューテックス、セマフォなどに対して互換性を失わせるような変更が行われたときに上げられます。
最後に、レジストリ内のマウントテーブルのレイアウトに対して後方互換性のない変更が加えられた場合に変更されるマウントポイントレジストリバージョン番号があります。
これは長い間、mounts v2 となっています。 Cygwin
のバージョン番号に関する更なる詳細については、ファイル
/usr/include/cygwin/version.h を参照して下さい。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
_timezone の値を参照する前に tzset() を明示的に呼び出していますか? そうでなければ、これを呼び出しておかなくてはなりません。
Cygwin からマウスイベントを取得する方法はありません。 このサポートを追加する計画は今のところありません。
パッケージのメンテナになるつもりでしょうか。素晴らしいことです。Cygwin チームの最重要目的は Cygwin それ自身であるので、我々はパッケージを準備しメンテナンスするボランティアを早急に必要としています。
パッケージメンテナとなるために知っておかなければならないことについての詳細は http://cygwin.com/setup.html にある Cygwin Package Contributor's Guide に全て記述されています。 パッケージのメンテナンスに関する質問があれば、cygwin-apps メーリングリスト( http://cygwin.com/lists.html から始めて下さい)が利用出来ます。勿論、cygwin-apps メーリングリストのアーカイブを調べた後にですよ。 Charles Wilson 氏は texinfo を例にとって、何を含むべきかについての短いレシピを投稿しました。このレシピは http://cygwin.com/ml/cygwin-apps/2000-11/msg00055.html で参照することが出来ます (11)。 何が必要かについてのアイデアを与えてくれることでしょう。
他の人が同じ事を考えているといけないので、その意図を一般の Cygwin メーリングリストに対して発表すべきです。
Cygwin それ自身に対して何かを寄贈したいのであれば、 http://cygwin.com/contrib.html を参照して下さい。
デフォルトでは、gcc は全シンボルを含んでコンパイルします。UNIX でも gcc は巨大な実行形式を作成します。
もしそれが邪魔であれば、binutils パッケージ中に含まれる「strip」プログラムを使うだけです。又は gcc に `-s' オプションを与えてコンパイルします。
Cygwin は glibc を提供しません。代わりに、同じ機能の大部分(全てではありません)を提供する newlib を使用します。 glibc を Cygwin へ移植するのは難しいでしょう。
Objective C は gcc の Cygwin 版は含まれておらず、また含まれる予定もありません (12) 。 gcc パッケージのメンテナはそれをビルドするのに苦労していましたし、 しかもビルド出来たとしてもそれには問題が残っていました。 とにかく、メインの GCC ディストリビューションに含まれる Objective C フロントエンドには最低限のサポートしか含まれていないように思えるのです。
まず最初に、`make -j[N]' を使用しているのであれば make は止まります。 それは正しく動作しません。
そうでなければ、読み続けて下さい...
make は UNIX と WIN32 という二つの処理モードを持っています。 正しいモードで処理していることを確かめる必要があります。
UNIX モードでは、make はサブシェルとして sh.exe を使用します。 パスのリストは「:(コロン)」、エスケープキャラクタは「\」となり、 POSIX パスが使われ、Cygwin のマウントが解釈されます。 UNIX 用に書かれた Makefile を扱うときはこのモードを使用します。
WIN32 モードでは、make は「ネイティブ」のコマンドシェル (cmd.exe 又は command.com)を、 そのコマンドシェルが持つ全ての制限と共に使用します。 パスのリストは「;(セミコロン)」で区切られ、 パスの区切りは「\」です。「copy」と「del」が使用できますが、 Cygwin のマウントテーブルは利用できません。 nmake (13) スタイルの Makefile を扱うときはこのモードを使用します。
ネットリリース版の make(setup.exe でインストールされるもの) のデフォルトのモードは
UNIX です。 Redhat(以前は Cygnus)の顧客に対する製品版リリースでは WIN32 です。
デフォルト値は環境変数 MAKE_MODE を 「UNIX」(実際には大文字小文字の区別はありません) 又は「WIN32」(実際には「UNIX」以外) と設定することによって上書き出来ます。 make のコマンドラインオプション --unix 又は --win32 によっても指定できます。
ソースの中に空の main() 関数を追加してみてください。
又は、リンクのコマンドライン中で `-lm' をかなり前のほうにおいているのでしょう。 それは最後に置かれなければなりません。
bash$ gcc hello.c -lm bash$ ./a.exe Hello World!
は動作しますが、しかし次の場合は動作しません。
bash$ gcc -lm hello.c /c/TEMP/ccjLEGlU.o(.text+0x10):hello.c: multiple definition of `main' /usr/lib/libm.a(libcmain.o)(.text+0x0):libcmain.c: first defined here /usr/lib/libm.a(libcmain.o)(.text+0x6a):libcmain.c: undefined reference to `WinMain@16' collect2: ld returned 1 exit status
libm.a は作り物で、libcygwin.a へのシンボリックリンクです。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
非常に簡単です。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 などを含む基本的なライブラリ群を含めることが出来ます(そしてプログラムはコンソールプログラムではなく、GUI プログラムになります)。
但し、ld を直接起動しているのでない限り -lkernel32 をリンク行に含めてはいけないことに注意してください。 リンク行に同じインポートライブラリを二度含めてはいけません。 最後に、インポートライブラリはリンク行の最後か、少なくともそれを参照する全てのオブジェクトファイル、スタティックライブラリの後ろに置くのが良い方法です。
最初の 2 つは、インポートライブラリが二度参照される際に発生するリンカの問題に関連しています(少なくとも b18 以降)。 テーブルが破壊され、プログラムが無作為にクラッシュしてしまいます (14)。 最後の点は、gcc がコマンドライン上のファイルのリストを順番に処理し、ライブラリを参照しているファイルの後ろにあるライブラリに対してのみ参照の解決を行うという事実に関係しています。
gcc の -mno-cygwin フラグによって、gcc は Cygwin の代わりに標準の Microsoft DLL をリンクするようになります。 これは UNIX エミュレーション層を必要としないネイティブ Windows プログラムのためのものです。
これは完全に別個の試みである「MinGW」(Minimalist GNU for Windows) とは混同されません。このプロジェクトのホームページは http://www.mingw.org/index.shtml です。
いいえ。プログラムが Cygwin API を利用するのであれば、その実行形式は cygwin1.dll なしには実行出来ません。 特に、ライブラリから独立しライブラリを自分自身に包含した形の実行形式を作成すべく、Cygwin ライブラリを静的リンクすることは不可能です。
あなたの Cygwin アプリケーションを配布する際にこれが問題となるのであれば、ライセンスオプションについて記述された http://cygwin.com/licensing.html を読み、理解することをお薦めします。 Red Hat から特別な商用ライセンスを購入しない限り、あなたの Cygwin アプリケーションは必然的にオープンソースとなります。
いいえ、どちらか一つだけを使用しなければなりません。それらは相互に排他的なものです。
コンパイル時のデフォルトは、コンソールアプリケーションを生成するようになっています。 GUI プログラムを書いているのであれば、先に説明したように -mwindows オプションをつけてコンパイルするか、「-Wl,--subsystem,windows」を gcc のコマンドラインに追加して下さい。
通常、この問題はテキストエディタで Makefile のタブをスペースで置き換えた結果として発生します。 コマンド行はタブで始まらなくてはなりません。これは Cygwin に限った話ではありません。
「Microsoft Open Tools License agreement」のサブセクション 2.d.f には、「エンドユーザに対して再配布可能な形で更に再配布することは認められない」とあるようです。 我々はこれを、「我々はこれらをあなたに提供することは出来るが、あなたは他の誰かにこれらを提供することは出来ない」という意味であると理解しました。 これは Red Hat としては賛成出来ないことです。しかしながら幸運にも、我々はほぼ完璧な独自の Win32 ヘッダを持っています。
私の知っている限り、Cygwin の開発者でそのようなことをした人間はいません。 しかしメーリングリストでの報告によれば、次のようにすれば出来るようです。
impdef cygwin1.dll > cygwin1.def
lib /def=cygwin1.def /out=cygwin1.lib
#include <sys/cygwin.h>
#include <stdlib.h>
typedef int (*MainFunc) (int argc, char *argv[], char **env);
void
my_crt0 (MainFunc f)
{
cygwin_crt0(f);
}
他の Cygwin を利用するライブラリを利用する場合は、gcc を利用してそれらのライブラリを DLL としてビルドし、Microsoft Visual C リンカ用のインポートライブラリを作成する必要があるでしょう。
この情報を提供してくれた Alastair Growcott (alastair dot growcott at bakbone dot co dot uk) 氏に感謝します。
`.lib' ファイルが通常の静的な、或いは C から呼び出し可能なエントリポイントを持つインポートライブラリであれば、`foo.lib' を `*.o' のような gcc/g++ のオブジェクトファイルとして利用することが出来ます。 そうでなければ、以下の作業を行って下さい。
この方法で、Microsoft Visual C(とその他多くのランタイムライブラリ)を Cygwin 開発ツールから使うことができます。 これは大変な作業(丸半日かその程度かかるでしょう)ですが、それでも問題のランタイムライブラリを仕様から書き直すよりはまだましでしょう…。 (Jacob Navia (root at jacob dot remcomp dot fr) 氏から説明をいただきました。ありがとうございます。)
必要となる全てのコンポーネントを単一のディレクトリ(我々は /src を利用しています)に展開します。 理想的には、必要となるものを CVS (http://cygwin.com/cvs.html)からチェックアウトすべきです。 それは、ソースを手に入れるために 推奨されている方法 です。 そうでなければ Cygwin ディストリビューションから適切なソースパッケージを取得して展開することも可能です。
これを書いている時点では、少なくとも Cygwin のソースパッケージと w32api のソースパッケージを展開する必要があります。 winsup ソースパッケージは最初に展開されるべきであり、w32api ソースディレクトリは winsup ソースパッケージ展開後に作成される「winsup」ディレクトリの中で展開されなければなりません。 そして、w32api-<バージョン番号> を w32api へとリネームします。
パッケージのリリースは常にロックステップ(lock step)にあるわけではないので、Cygwin ソースパッケージは w32api パッケージのより新しいバージョンを必要とするかもしれません(CVS を利用する、もう一つの理由です)。
Cygwin はソースとは別のディレクトリでビルドする必要があります。 /obj ディレクトリのようなディレクトリを作成して下さい。そのディレクトリでビルドを実行することになります。
bash cd /obj /src/configure --prefix=/install -v > configure.log 2>&1 make > make.log 2>&1 make install > install.log 2>&1
通常、この手順ではドキュメントのビルド時に発生するエラーは無視されます。 ドキュメントのビルドには Cygwin ディストリビューションには含まれていないツールが必要です。 Linux 上でドキュメントのビルドを行いたければ、大部分のディストリビューションで docbook-utils として提供されているパッケージに、必要となる全てが含まれています。 ドキュメントのビルドに関する更なる情報については、cygwin-doc パッケージに含まれている README ファイルを参照して下さい。
cygwin1.dll のチェックを行うためには、winsup/cygwin ディレクトリで「make check」を実行します。 これが動作したなら、(可能であれば)DLL を除く全てをインストールします。 続いて、全ての Cygwin プログラム(bash、inetd などを含む)を終了させ、古い DLL を保存し、新しい DLL を正しい場所にコピーします。そうしたら bash、或いは他の Cygwin プログラムを Windows のコマンドプロンプトから実行し、何が起こるのかを見てみましょう。
「shared region is corrupted(共有領域が汚染されている)」というエラーが出た場合、二つのバージョンが異なる cygwin1.dll が同時にマシン上で動作していることを意味しています。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
残念ながら、これは難しいです。 Microsoft が PowerPC 版 NT の開発を打ち切って以来(1996 年後半)、ずっとビルドされていません。 例外処理やシグナルサポートのセマンティックス、引数が x86 版では修正されていますが、PPC 用には更新されていません。 従って、PPC 特有のサポートを書き直す必要があるでしょう。 他にどのような非互換性があるかわかっていません。もしこれを修正して下さるなら、ぜひ我々にパッチを送ってください!
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
Alpha 版 NT 用には移植されておらず、現時点では移植する予定もありません。 Alpha 版 NT をサポートする修正をどなたか寄贈していただけると嬉しいです (15)。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
gcc にヒープ・スタックサイズのリンクオプションを渡して下さい。 foo.exe をヒープサイズ 1024、スタックサイズ 4096 で作成するには、 gcc をこのように起動して下さい。
gcc -Wl,--heap,1024,--stack,4096 -o foo foo.c
`objdump -p' がこの情報を提供しますが、少し冗長です。
`cygcheck' はより簡潔であり、パスに含まれるコマンドを再帰的に処理します。
cygcheck には現在、Windows システムディレクトリ(C:\WINDOWS や C:\WINNT など)にあるプログラムは、仮にパスに含まれていても報告されないというバグがあることに気をつけて下さい。 このバグに対処するには、実行形式への完全な Win32 パスを .exe 拡張子を含めて指示します。
cygcheck c:\\winnt\\system32\\cmd.exe
(bash 上でタイプする場合、Windows パスの区切り文字はエスケープされねばならないことに気をつけて下さい。)
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
Cygwin プロジェクトのメインの Web ページ( http://cygwin.com/ )に、この手順について説明したドキュメントがあります (16)。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
gdb で *0x401000 にブレークポイントを設定し、当該プログラムを実行して下さい。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。 しかし、この問題に関する議論が最近 Cygwin メーリングリストで行われました。 http://cygwin.com/ml/cygwin/2000-06/msg00688.html 及び関連するメッセージを読んで下さい。)
以下に示す 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)」ポインタを初期化する必要があります。これはグローバル変数 `_impure_ptr' を宣言し、エントリ関数中で初期化することによって行います。 このグローバル変数 `_impure_ptr' は DLL から公開しないように注意して下さい。つまり、DELFILE には入れないで下さい。
/* これは大域変数です。 */
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
のデバッグ情報をロードできないと文句を言ってくるでしょう。 これは正常です。何故なら、これらの DLL
はデバッグ情報を持っていないからです(仮に持っていたとしても、そのデバッグ情報には gdb との互換性はないでしょう)。
はい。様々なデバッグ及びトレースメッセージを利用可能にして他の Cygwin
プログラムを実行させるために、strace.exe ユーティリティを使用することが出来ます。
strace の使用方法に関する情報については、Cygwin ユーザーズガイド又は
winsup/utils/utils.sgml ファイルを参照して下さい。
不幸なことに、現在の gdb には最小限のシグナルハンドリングしか実装されていません。 シグナルハンドリングは Windows タイプのシグナルに対してのみ動作します。 SIGINT、SIGFPE に対しては動作し、無論 SIGSEGV に対しても動作します。 デバッグ中のプロセスに対する SIGUSR1 又は SIGHUP のような「stop」「print」又は「nopass」シグナルは扱えません。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
よくあるエラーとしては、コマンドライン上で、ライブラリを必要とするものよりも前にそのライブラリを置いてしまう、というものがあります。
誤: gcc -lstdc++ hello.cc.
正: gcc hello.cc -lstdc++.
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
その関数は恐らくヘッダファイルで宣言されていないか、あるいは Unicode 用のものが入っていないかでしょう。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
はい。
(注意: このセクションは最新のネットリリースに合わせて更新されていません。)
malloc.h の代わりに、stdlib.h をインクルードして下さい。
もしあなたのプログラム中で malloc という名前の関数を定義して DLL(cygwin1.dll)
(17)
をリンクした場合、 DLL はあなたの malloc を呼び出します。
言うまでもないことですが、もしあなたの malloc にバグがあるようなら深刻な問題に陥るはめになるでしょう。
プログラムを bash からではなく DOS コマンドプロンプトから実行した場合、DLL
はコマンドラインのワイルドカードを展開しようとします。 この処理は main 関数の処理が開始される前に
malloc を呼び出します。もしあなたの malloc
が、main
が呼び出された後に発生する初期化を必要とするように記述されている場合、間違いなく問題が起こるでしょう。
更に、newlib には _malloc_r
に関する未解決の問題があります。 この malloc の再入可能バージョンはあなたが作成した
malloc をバイパスして newlib 内部で直接呼び出され、自作の
malloc とは両立しないことでしょう。 しかし、_malloc_r
をも置き換えるということは恐らく出来ません。 なぜなら cygwin1.dll は
_malloc_r をエクスポートしておらず、しかも Cygwin はあなたのプログラムが
_malloc_r を置き換えているということは想定していないからです。 これは newlib
の問題ですが、我々はこの問題をどうするかということに対する提案は受け付けています。
はい、C のオブジェクトファイルを扱っている限りは動作するはずです。 Microsoft Visual C++ は GNU C++ とは異なった方法で名前の変形を行なうため、C++ オブジェクトを混在させるのは困難でしょう。
いいえ、完全な(高級言語レベルでの)デバッグはできません。 Microsoft のコンパイラは gdb が理解出来ない異なったタイプのデバッグ用シンボル情報を生成します。
しかし、Microsoft のコンパイラが生成する低レベル(アセンブラ型)のシンボルは coff であり、これは gdb が理解「出来ます」。 従って、少なくとも全てのグローバルシンボルは見ることが出来るはずですが、データ型、行番号、ローカル変数などの情報は得られません。
Intel の現在のチップの CPU リファレンスマニュアルは、Intel の Web サイト( http://developer.intel.com/design/pro/manuals/ )から PDF 形式でダウンロード出来ます。
スクリプトがカレントディレクトリにある場合、$PATH の中に `.'(ドット)が必要です(通常、これはデフォルトではありません)。 Makefile から起動される全てのシェルスクリプトの前に、個々に /bin/sh を付け加える必要はありません。
Win32 API へアクセスすることを示すには _WIN32 を、DLL が提供する Cygwin 環境にアクセスすることを示すには __CYGWIN__ を使用します。
_WIN32 を選んだのは Microsoft が VC++ の中で定義しているものであり、VC++ のサンプルに従えるよう互換性を保持するのは良いことであると考えたからです。 我々は _MFC_VER を使用して、VC++ でコンパイルされるべきコードを指示しています。
_WIN32 は gcc コマンドラインオプションで、 -mno-cygwin 或いは -mwin32 のどちらかを指定したときのみ定義されます。 これは、Cygwin が UNIX のエミュレーション環境をサポートしているからであり、また Windows 環境上での特別な利権(これらは、Cygwin が自動的に取り扱います)を必要とすると考えられる、幾つかのプログラムを混乱させないようにするためです。
-mno-cygwin を利用すると、利用するコンパイラ(或いは設定)に __CYGWIN__ ではなく __MINGW32__ を有効にするよう伝えることになることに注意して下さい。 例えば、以下を実行すれば何が起こるか分かるでしょう。
$ gcc -dM -E -xc /dev/null >gcc.txt $ gcc -mno-cygwin -dM -E -xc /dev/null >gcc-mno-cygwin.txt $ gcc -mwin32 -dM -E -xc /dev/null >gcc-mwin32.txt
何か異なっているかを調べるには、diff 及び grep ユーティリティを使って下さい。
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 エクステンダ」を使用しています。 Cygwin ツールセットでは全てのアプリケーションがネイティブ Win32 なので、その必要はありません。 Cygwin ツールでコンパイルされたアプリケーションは全ての Win32 API 関数にアクセスできるので、Windows の GUI を使ったプログラムを書くことも出来るのです。
DJGPP に関する詳しい情報は http://www.delorie.com/ から得ることが出来ます。
この問題はいつか修正されるでしょうが、しかしその間は rxvt のようにこの問題が発生しないものを利用して下さい。rxvt には他にも数多くの利点がありますので、これは実質的な問題とはならないはずです (代わりに「割れた」パイプキーを利用しようとは考えてないで下さい。それは別の文字です)。
Win9x は Cygwin の fhandler_dev_tape クラス内で使用されている API をサポートしていません。詳細については http://sources.redhat.com/ml/cygwin/2000-12/msg00331.html を参照して下さい。
(何もありません)
このセクションはもはやメンテナンスされていません。 代わりに、http://cygwin.com/history.html を参照して下さい。
(Cygwin 特有の疑問がある場合、 個人的な電子メールを送るのではなく Cygwin メーリングリストを利用すれば、 ここに挙げた全ての人々がその疑問を認識するであろうことを覚えておいて下さい)
最近の Cygwin の変更の多くは Chris Faylor のお陰です。 彼は Cygnus に入る前からネット上の協力者として、プロセス制御及び環境のコードの大きな修正、strace 機構の作り直し、シグナル関連のコードの一からの書き直し、などに協力してくれました。 加えて技術的な協力を継続しています。Chris は現在のグループの管理者でもあります。
Corinna Vinschen は、パスのハンドリング、及びコンソールと raw デバイスのサポートについて、幾つかの有用な修正を施してくれました。 Corinna は GDB/Cygwin のエンジニアとして、現在 RedHat で働いています。
DJ Delorie は Cygwin のプロファイリング、自動テスト用のフレームワークである Dejagnu に関する作業、ld に対する dlltool の機能のマージ、Cygwin ユーザーズガイドの大部分の記述、cygcheck ユーティリティの作成、プロジェクトの WWW ページから自動的にスナップショットを取得可能にする、などの重要な作業を行いました。 DJ は GCC のエンジニアとして、現在 Red Hat で働いています。
Egor Duda は多くの有用な修正を施しました。 彼はコアダンプを作成することにより、致命的なエラーの検出をデバッガで行うための Cygwin の機能を担当しています。
Robert Collins は Cygwin それ自身に対する一般的な修正を行うことにより、スレッドハンドリングに対する数多くの改良を行いました。
藤枝和宏は数多くのバグ修正とバグ報告を行いました。
Earnie Boyd は mingw と w32api のメンテナであり、数多くのバグ修正を行いました。
David Starks-Browning は専門の FAQ メンテナです。
Geoffrey Noer は 1996 年の中旬に、最初の作者である Steve Chamberlain から Cygwin プロジェクトを引き継ぎました。 beta 16 から beta 20 までの間、メンテナンス担当としてネットリリースをプロデュースしました。 その間、開発用スナップショットを作成し、ネット上の協力者達とバグを修正し、自分でも修正を行いました。 また、1998 年の Usenix NT シンポジウム用の Cygwin に関する論文及びプロジェクトの WWW ページ、FAQ、README を記述しました。 Geoffrey は既に Red Hat の社員ではありません。
Steve Chamberlain は 1995 年から 1996 の年の間 Cygnus で働き、Cygwin のデザインと実装を行いました。 彼はネット上で技術の改善、最初の Cygwin に対する数多くのユーザツールの移植と統合、beta 14 までの全リリースのプロデュースを行いました。Steve は既に Red Hat の社員ではありません。
Data Distilleries の Marco Fuykschot と Peter Boncz は最近、Cygwin をスレッドセーフにするための全ての変更に貢献しました。彼らはまた、pthreads インタフェースも提供しました。
Sergey Okhapkin は、かけがえのない貴重なネット上の協力者でした。 彼は tty/pty のサポートを実装し、シグナルと例外処理の改造に対して重要な役割を果たし、ライブラリ中の至るところにおいて数えきれないほどの貢献をしてくれました。 彼はまた、beta 19 リリース以降、ネット上での開発スナップショットのバイナリを提供してくれました。
Mumit Khan は EGCS 側について最も協力してくれた方で、B20 リリースに含まれていたコンパイラ群に対してかなりの数の安定化パッチを提供してくれました。
Philippe Giacinti は Cygwin の dlopen、dlclose、dlsym、dlfork、dlerror の実装に協力してくれました。
Ian Lance Taylor は beta 18 において必要とされていたパスの扱いに関するコードの作り直しを行い、コード全体を通して行って関連する数多くの修正をしてくれました。 Jeremy Allison は select を一から書き直し、ファイルハンドリングとプロセス制御の分野において多大な協力をしてくれました。 Doug Evans は beta 16 において、パスの扱いのコードを書き直すなどを行ってくれました。 Kim Knuttila と Michael Meissner は、今は亡き PowerPC 版の作業に多大な時間を費してくれました。 Jason Molenda と Mark Eichin も重要な協力をしてくれました。
Cygwin に関わっている我々全ては、受け取ったパッチや質問には可能な限り応え対処しようとはしていますが、現実としてはメインのメーリングリストに送られたメールの全てにお答えする時間は無いということをご承知下さい。 Win32 ツールのネットリリースの作成やネット上での助力は私達の第一の仕事ではありませんので、お答え出来ないメールも出てくるでしょう。
アドバイス、バグ報告、コード修正という形で協力して下さっていることに対し、このツールを使っている皆様に非常に感謝します。これからもよろしく!
(訳注: この項については原文をそのまま掲載します。 参考までに、最後に訳者による拙訳を付与しておきます。)
Most of the tools are covered by the GNU General Public License (GPL), although some are public domain, and others have a X11-style copyright. To cover the GNU GPL requirements, the basic rule is if you give out any binaries, you must also make the source available. For the full details, be sure to read the text of the GNU GPL which follows.
The Cygwin API library found in the winsup subdirectory of the source code is also covered by the GNU GPL. By default, all executables link against this library (and in the process include GPL'd Cygwin glue code). This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all.
Cygwin is currently available for proprietary use only through a proprietary-use license. Please see `http://www.redhat.com/software/cygwin/' for more information about the Red Hat Cygwin Product.
In accordance with section 10 of the GPL, Red Hat, Inc. permits programs whose sources are distributed under a license that complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL.
This means that you can port an Open Source(tm) application to cygwin, and distribute that executable as if it didn't include a copy of libcygwin.a linked into it. Note that this does not apply to the cygwin DLL itself. If you distribute a (possibly modified) version of the DLL you must adhere to the terms of the GPL, i.e., you must provide sources for the cygwin DLL.
See http://www.opensource.org/docs/definition_plain.html for the precise Open Source Definition referenced above.
---- 以下、日本語訳 ----
殆どのツールは GNU General Public License(GPL)で保護されていますが、他の幾つかはパブリックドメインであり、その他は X11 スタイルの著作権を持っています。 GNU GPL の「制限」を全うするならは、「もし何かのバイナリを配布するのであれば、そのソースも利用できるようにしなければならない」が基本ルールとなります。完全な詳細については、以下の GNU GPL の本文を必ず読んで下さい。
ソースコードの winsup サブディレクトリにある Cygwin API ライブラリもまた、GNU GPL によって保護されています。 デフォルトでは、全ての実行プログラムはこのライブラリ(及び GPL に従った Cygwin glue(糊付け)コードを含むプロセス)をリンクしています。 これは「コンパイルされた実行プログラムが Cygwin ライブラリを使わないようにツールを修正しない限り、あなたがコンパイルしたプログラムもまた、誰もがソースコードを利用可能である GPL で配布されるフリーソフトウエアになる」という意味です。
現在、Cygwin の商用利用(proprietary use)は商用利用ライセンスを通じてのみ可能です。 Red Hat の Cygwin 製品に関する更なる情報については、 http://www.redhat.com/software/cygwin/ をご覧下さい。
GPL 第 10 項によれば、結果としてプログラムが GNU GPL で保護されている libcygwin.a それ自身を除き、そのソースが Open Source definition の元にあるのであれば、Red Hat Inc. は libcygwin.a とリンクされるプログラムの配布を許可出来ます。
これは、Open Source(tm)アプリケーションを Cygwin に対して移植できること、 そしてリンクされる libcygwin.a を含まなければ、その実行形式を配布できることを意味しています。 Cygwin DLL それ自身に対してこれは適用されないことに気をつけて下さい。 本 DLL の(あるいは修正した)あるバージョンを配布する場合、「Cygwin DLL のソースを供給する義務がある」などの GPL の条項に従う必要があります。
先に言及されている Open Source Definition の詳細については、 http://www.opensource.org/docs/definition_plain.html をご覧下さい。
(訳注: この項については原文をそのまま掲載します。 日本語訳については、http://www.gnu.org/japan/gpl-2j.plain.txt を参照して下さい。)
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.
この文書の翻訳は、Keisuke Mori(ksk@kt.rim.or.jp)氏の手になる Cygwin B20.1 の Cygwin FAQ 日本語訳を元に Rue. SATOH(riue@sixnine.net)が行いました。 訳者の能力不足のため訳文の質はあまり高いものではありません。 本文書は可能な限り正確であることを意図していますが、原文の内容を正確に表現していることを保証するものではなく、あくまでも原文を読む際の補助としてのみ扱われることをお奨めします。
また、訳者はこの文書の内容に関していかなる責任も負うものではなく、Red Hat 及び Cygwin 開発チームに対していかなるサポートをも行うものでもありません。
誤訳等の本文書に関する不備については全て訳者に責任があります。 誤訳の指摘、その他アドバイスなどは歓迎致します。
本文書の最新版は常に、 http://www.sixnine.net/cygwin/translation/ 以下にあります。
This document was generated on 6 September 2004 using texi2html 1.56k.