最小限の Gnu-Windows 64 ビット Gnu コンパイラ コレクションが必要な場合は、MinGWTDM64 を確認する必要があると思います。MinGW32 が自分の目的に合わないのではないかと心配している場合は、おそらく誤解されているでしょう (ただし、何をしたいのか、それが可能かどうかさえわかりません)。しかし、TDM (Dragon?) は、mingw 組織自体よりも (少なくとも最近では) 最新の状態を維持するのに優れた仕事をしていることがわかりました。
もしあなたが上記に従えないなら、あなたにとってより適切であるように思えます。なぜなら、上記は *nice の FSSTND (Filesystem Hierarchy) Standard を反映したものだからです。configure ツールは GNU Build System (qv try Wikipedia) の一部であるため、それを理解するには、事前に決められたパス上のどのソース ファイルがどこにあると予想されるか、およびそのターゲット ファイルをどこに書き込むかを知る必要があります。これにより、ご使用の環境 (またはプラットフォーム、マシン、OS など) でコンパイルするための正しいヘッダー ファイルをセットアップして、正しく実行される製品 (コンパイラー) を生成することができます。
Gnu の Not Unix (GNU) と Windows は確かにそうではないため、単一のツールセットからどちらでも動作するコンパイラを作成するのは複雑です (「壊れやすい」と読みます)。コンパイラを構築することは、開発者のキャリアの最初のステップでもありません。ですから、血まみれの道で終わりのない失恋の準備ができていない限り (少し比喩が許されるかもしれませんが)、既製のパッケージを入手することをお勧めしますが、もう一度ユーモアを交わしてください.
私はもうあなたを思いとどまらせましたか？いいえ、まあ、私が試していないとは言わないでください。コンパイルに対するビルド ツールの重要性は、configureそれ自体がそれらから構築されることです。非常に多くの場合、一連のインストール手順 (GNU 要件) には、「このパッケージをビルドするには (「Hello, World」と言って、かなり安全なキャンプに保管しておく必要があります)、最初に次のコマンドを実行する必要があります。
$> ./configure
に続く
$> make
どちらも、使用するコンパイラのタイプと場所、および製品をインストールする場所に関してさまざまなパラメータを取る可能性があるため、それ自体は非常に単純化されすぎています。しかし、まだあまり発散しないようにしましょう。これらのパッケージの多くで、「 autotools セットを使用して構築されましたが、このバージョンのhelloworldconfigureをコンパイルするために再構築する必要はありません。」と指示が続きます。
IMHO、「すべきではありません」は常に大文字にし、イタリック体にし、太字で強調し、できるだけ頻繁に繰り返す必要があります。多くの場合、構成を再構築する必要がないのは、作成者と同一のプラットフォーム (アーキテクチャ、プロセッサ、OS、および環境) を使用している場合のみです。運が良ければ、作成者が徹底していれば、作成者が最初に Linux マシンでビルドした場合でも、Windows マシン でhelloworldをクリーン コンパイルできる場合があります。
GCC (mingw32、64、またはその他のフレーバー) を構築しないことをお勧めする大きな理由の 1 つは、独自の GNU ディストリビューションを作成せずに autotools を理解しようとすることをお勧めしないことです (たとえそれが練習のためであっても)。「コンパイラさえも持っていないのに、どうすればいいの?」とあなたは尋ねます。私はあなたの欲求不満を理解し、それをある程度共有することさえできます.
このコンパイラ スイートを自分で Windows マシンに (MinGWTDM などを使用せずに) 配置したい場合は、まず自宅で Linux 環境で実行する必要があります。ビルドがそこでどのように機能するかを確認すると、少し明確になります。それでも、完全なコンパイラ セット (実際には C コンパイラでさえも) のクリーン コンパイルを作成する可能性はないと思います。ハーバード大学の David Malan は、実際の設備と非常によく似た仮想化環境を使用して CS50 をリモートで教えています。それは無料で、彼はその過程で C も教えてくれます。これにより、コンパイラ オプション (さまざまな環境でのビルドに不可欠) を理解することができます。
仮想化を実行したくない場合、または仮想マシンを構築するための指示が得られない場合 (信じられないかもしれませんが、コンパイラを構築するよりも簡単です)、Linux のブランドをどこかにインストールできます。コンパイラや仮想マシンを構築するよりも破壊的な可能性があるため、デュアルブートの可能性があるにもかかわらず、Windows マシンで実行することはお勧めしません。
それを行って、Sourceforge からいくつかの Linux ソース パッケージをダウンロードします (何かを強くお勧めします -- 不適切な構成やビルド スクリプトは必要ありません)。指示に従ってください。それらを Linux でビルドし、Windows で同じプロセスを繰り返します ([99.9% の確率で] できないと誰かに言われない限り、32 ビット コンパイラで実行できます)。
チュートリアルの 1 つに移動しautotools/autoconfます (マニュアル ページではありません。後で演習の意味を詳しく理解するために行ってください)。独自のhelloworldパッケージを作成して独自のものを作成し、configureそれが何をしているかを理解できるようにします。成功の可能性を高めるために、まず Linux で実行し、次にそれを Windows に「移植」します。賢明な言葉 - シグナルを含むものは避けてください - それらは Windows では実装されていません。
そうは言っても、さらに厄介なことを言います: mingw-w64-howto-build.txt は特によく書かれているわけではありませんが、初心者の目に見えるほど下手に書かれているわけではありません。実際のところ、これは初心者以外の読者向けに書かれたものだと思います。ソースから (特に元の家の外で) コンパイラを構築するプロセスは些細な問題ではないため、同じ語彙をあまり使用せずに説明できる人を見つけることができれば、私は驚かれることでしょう. この種のことをする人々は、まったく同じ方法でお互いに話します。多くの場合、コードとビルド スクリプトの場合を除いて、上記よりもはるかに下手な作業を行います。
しかし、より達成可能なアプローチを選択していない場合、@prefix@またはスクリプトで最初に呼び出されるものは、(a) ビルド ソースの場合、(b) ビルド ターゲットの場合、および ( c) ビルド インストール用。Unix は MULTICS に基づいていました。これは、Microsoft が XENIX に取り組む前の Bill Gates の仕事であり、3 つすべてが「マルチユーザー オペレーティング」または「プロセッサ制御システム」であったことを思い起こさせるものです。マルチユーザーには、複数のアカウント、複数の役割、および複数のビルド/インストール ツリーの概念が含まれます。
自分自身のためにコンパイラを構築すること (特に構築の最後の部分がインストール手順である場合) は、同じマシンの他のユーザーのために構築することとは異なります。この概念をもう少し拡張してみましょう。あなたは自分自身や友人のためにそれを行っているのではなく、あなたの会社のために、あるいはおそらく「あなたの設備」のためにやっているとしましょう。この場合のインストールは、展開されるベースのようなものになります。自分や自分のマシンにアカウントを持つ友人のためにコンパイラをビルドすることだけでなく、上司のためにコンパイラをビルドすることも心配する必要があります。オペレーター、管理者、プログラマー、設計者、およびコンパイラーを必要としている/必要とする可能性のある他のすべての人が作業を行います。共存しなければならないいくつかのタイプのコンパイラがあるかもしれません。
ビルド ツリーとインストール ツリーには多くの共通点があります。 PREFIXこれに対処しようとします。私自身の小さなサンドボックスを構築するときは、私が設定した という接頭辞を使用します~/local。それは *nice にとって特別な場所です。~ は、Windows 用語で $HOME または %home% のショートカットです。これは、練習ビルドに最適な場所です。特別な権限は必要ありませんが、そこに存在するものにはいくつかの制限がある場合があります。 PREFIXすべての問題を解決するわけではありませんが、構成ツールに、ビルドとインストールのツリーをルート化する場所のアイデアを提供します。David Malan の言葉では、コードをビルドする場合/home/jharvard/local/<product name>/src(また、一部のツールの一部のバージョンでは、通常のショートカットではなくフル パスが要求されます~/<product name>/src)、私PREFIXのサンドボックス コンパイルは次のようになります。~/localまたは/home/jharvard/local、合理的なファイル システム標準の命名規則が与えられた場合、実行可能ファイル (生成されたものおよび/または既存のもの) は~/local/binライブラリに含まれ、自分のアカウントでこれをいじっている間に~/local/libインクルード ヘッダーが含まれます。~/local/includeそれらはどのようにしてこれらのディレクトリに入りましたか? あなたはそれをすべてそこに築きました。また、mingw-w64-howto-build.txt ファイルで引用されているソースなどから、ヘッダーなどを借用している可能性があります。
しばらく生き残ったいくつかのツールは、より幅広いユーザー層に宣伝され/usr/local/src /usr/local/bin /usr/local/lib /usr/local/include ます。. . などPREFIX。問題の 1 つは、そこにプロモートするには、そのパスの書き込み権限を持つ開発者でなければならないことです。そうしないと、configure が (とりわけ) 失敗します。
一部のツールには、まったくローカルではない種類のインストール スコープがあります。それらはコンパイル元になる可能性があります。これは/usr/src to /usr/bin using /usr/lib and /usr/include別のPREFIX.
神のみがコンパイルするシステム ルートでは、ツールは /sbin ではなくても /bin 自体に入りますlike /usr/local/experimental/src, /usr/bullpen/development/etc, /usr/production/bin。
人々がこのような投稿に回答しないことを選択する理由が明らかになりつつあると思いますが、おそらくこの演習は、さまざまな理由で多くの人々に役立つ可能性があります.
デフォルトとは何かというと、それがデフォルトです。他のものを使用していない場合は、デフォルトを使用していることがわかります。実際、彼は「configure default を使用する場合」とあなたに言ったので、デフォルトが何であるかを教えてくれました。/usr/localつまり、configure defaultPREFIXは/usr/localです。他に何も使用しない場合、それはあなたがタイプすることを意味します
$>./configure
それよりも
$>./configure --prefix=/home/veryambitious/local
そして、あなたのベルトの下でいくつかの成功したビルドがあれば、あなたが引用する指示は泥のように明確になります. sysrootの場合、sysrootはmypathの場所を決定しますつまり、コンパイラをビルドし、インストールして実行する場所を気にするだけで済みます。先に述べたように、そうしたいというあなたの目的は (単に最新のものを入手すること以外に: それを達成し、最新のバグ修正を入手するためのもっと簡単な方法があります)。あなたの目標が最新のネイティブ コンパイラを使用することだけである場合、システム ルート (階層の最上位または呼び出す予定のマウント ポイント) でそれを実行する理由が思いつきません。システムルート。CMake（GNU autotoolsの潜在的な競合相手ですが、GNU製品、特にgccではそうではありません）でビルドすると、デフォルトのインストールディレクトリが次のように指定されますC:\Program Files\somewhere-それは誰かにとって「事実上の」標準であると確信しています.
ソースがマシンのどこに配置されるかは、入手方法によって異なります。パスに「trunk」が含まれる 1 つのバージョンは、Subversion CMS リポジトリから取得される svn-gcc です。何らかのバージョンの tarball を取得した場合、ツリーは異なる可能性があります。Subversion ツリーには、環境用に既にセットアップされているビルド ツリーのような「ターゲット tarball」では得られない多くのものが含まれます。ただし、ソフトウェア構成管理のために維持されているため、最新の変更で頻繁に維持される予定です。ツールビルダーは、特定の典型的な環境の結果を複製するために、個別の「作業スナップショット」を追加することがあります。
シンボリック リンクに関して言えば、Windows 7 の化身で NT 4.0 に変換されるかさえわからない、シンボリック リンクの本当に良い名前です。シンボリック リンクは、inode またはファイル システム エンティティの定義において強力な役割を果たさないという点で、ハード リンクではありません。シンボリック リンクは、元のファイルに実際に影響を与えずに削除および変更できる軽量のリンクです。*x86_64-w64-mingw32* サブツリーへのリンクを使用して gcc をビルドすることについて著者が言っていることは、ビルドで使用するファイルには、それらをソースするためだけに完全に異なるサブツリーをビルドすることなく、一般的なエイリアスを与えることができるということです。
あなたの構成エラーは、何も言わずに必要なもののほとんどが欠けていることを理解するのではなく、何かを伝えるより一般的なバニラエラーメッセージの 1 つです。つまり、「何が問題だったのかはわかりませんが、ファイルの読み取りと生成を開始するために必要なものが何も見つかりません。読み取りまたは書き込みを行う場所がどこにもないため、これは奇妙な環境に違いありません。ヘッダー ファイルを見落としている可能性があります。それらを適切な場所に置いていますか?そうでない場合は、マシン、オペレーティング システム、または環境が定義されていない可能性があります。" あるマシンでクロスコンパイラを構築し、それを別のマシンでホストするため、これは実際に起こります。または、別のマシンでホストされるコードの場合。これらの場合、追加する必要がありますconfigureオプション --build=mybuild (場所は聞かないでください) および --host=myhost。
通常、それはあなたがすべて間違ったことをしていることを意味するだけであり、構成全体に一致する gcc を構築するための指示に従う必要があります。それを行うには多くの方法があります-あなたはMINGWに言及しましたが、それがすべてではありません. Windows API からの内部関数が必要です。Cygwin DLLにはこれらが多数含まれていました。 MSYSも同様のアプローチを使用していますが、完全な cygwin セットは提供していません。UNIX システム ルーチンがないため、代わりのものが必要です。これは、Windows よりも Linux の方が簡単に提供できます。
ターゲットは、MSVCRT (Microsoft Visual C ランタイム) の助けを借りて実行される実行可能ファイルを生成します。これは、標準的な結果のもう 1 つの欠点です。最新の GCC を使用していても、MSVCRT がまだ追いついていない場合があります。場合によっては、標準を無視することを選択することもあります。たとえば、フォーマット変換文字列のサイズ パラメータなどです。ストリームをカスタマイズする必要があると考えているのかもしれません。
これをコミュニティ投稿としてマークしておくことにします。これは、非常にばかげたものを入力できた可能性が高いと確信しているからです。Windows で GCC をコンパイルすることが、「箱から出してすぐに使える」努力にならないことを説明できたことを願っています。すべてを網羅することはできないので、このページにヒントを散りばめただけです。