問題タブ [tdm-gcc]

信じがたいかもしれませんが、ビルド環境とは何かを完全に理解するにはまだ苦労しています。私は何年にもわたって、それがディレクトリ ツリーであり、コンパイラがプロジェクトをビルドするために必要なすべてのヘッダーとlibファイルを見つけることができることを収集してきました。

TDM-GCC 64 ビット コンパイラ、MSYS、Windows 7 64 ビットを使用しています。

プロジェクトで使用するライブラリをビルドすると、ヘッダーと lib ファイルがすべて C:\mingw ディレクトリに配置されます。つまり、C**:\mingw\include & C:\mingw\lib**

私がzlibを構築しているとしましょう。zlib ディレクトリには lib ヘッダーとインクルード ヘッダーの両方が含まれ、私のルート c:\mingw ディレクトリには zlib ヘッダーと lib ファイルも含まれます。

そのため、依存関係として zlib を必要とする他のライブラリをビルドするときは、最初に以下のコマンドを使用しました: ./configure --prefix = c:\mingwそして、' make ' コマンド (すべて MSYS 内) を使用してビルドすると、私の新しいライブラリは、 c:\mingw\include & c:\mingw\lib ディレクトリにあるすべての依存関係を見つけることができます。 私はこれを正しく行いましたか？

ここで私は混乱します。 同じコンパイラ TDM-GCC 64bit を使用する CodeBlocks IDE でプロジェクトを作成する場合、検索ディレクトリを c:\mingw\include & c:\mingw\lib ディレクトリに設定しますか、それとも zlib ディレクトリを使用しますか? c:\zlib\include と c:\zlib\lib ディレクトリ?

または... ファイルパスが次のようになるように、zlibディレクトリ全体を c:\mingw ディレクトリ内に配置する必要があります:
c:\mingw\zlib\include & c:\mingw\zlib\lib ディレクトリ。

上記のすべてについて間違っている場合、Windows で堅牢なビルド環境をセットアップするにはどうすればよいですか?

また....私の知識のこのギャップを補うために、この種のことをうまく説明している本/教科書はありますか?

私は今のところ cygwin を使用しないことに決めました。

たくさんの質問 ;)

ありがとう、長文すみません。

********以下、後期追記************

テスト ファイルを c:\ming に配置し、コマンド ラインを使用してコマンド gcc -v test.hを呼び出しました (test.h は、コンパイラの検索パスをテストするためにルート ディレクトリに配置したテスト ファイルです。出力：

ご覧のとおり、--prefix を使用すると、 C:/mingw/lib/gcc/x86_64-w64-mingw32/5.1.0/includeにある他のインクルード ディレクトリ が無視されます。なぜmingwコンパイラがこれを行ったのか疑問に思っています。

コンパイラに検索させるのに問題があるファイル (math.h) は、インクルード ディレクトリにもありません。

現在、TDM-GCC 64 ビット コンパイラを使用しており、このコンパイラを使用してすべてのライブラリ (他のライブラリの依存関係) とプロジェクトを最初にビルドし、64 ビット バイナリを作成しました (これが必要です)。

最近、math.h を含む Fast Light Tool Kit (gui ツールキット) プロジェクトをビルドしているときに、いくつかのビルドの問題に遭遇しました。ここで、最初のビルドの問題に遭遇し、おそらくビルド環境を正しく設定していないことに気づきました。すべてが MSYS を使用して構築されました。

私のルート ディレクトリは C:\mingw なので、各プロジェクトを構成するときに次のコマンドを使用しました。 & c:\mingw\lib)。

FLTK には、関連するインクルード ディレクトリで適切な math.h c++ ファイルを検索するようにコンパイラに指示する math.h ファイルが含まれていますが、問題は、それが見つからないということです (math.h: no such file or director等）。Windows7 64ビットを使用しています。

これは、ビルド環境をセットアップした方法が原因であると思います.TDM-GCCが32ビットと64ビットの両方のバイナリをコンパイルできるという事実を考慮していない可能性があるため、これがコンパイラの解釈に何らかの影響を与えています。私のc ++ math.hファイルは.

このリンクで Mingw64 を使用してライブラリを構築する方法の説明を見ました: ここにリンクの説明を入力してください。ただし、TDM-GCC は、この記事が解決するように設計されている問題のいくつかを処理していると思います。

すべてのディレクトリが検出されるように、TDM-GCC 64 ビット コンパイラ用にビルド環境を正しく設定するにはどうすればよいですか?

いくつかのインクルードディレクトリがあることに気付きました:

1. C:\mingw\x86_64-w64-mingw32\include

2. C:\mingw\lib\gcc\x86_64-w64-mingw32\5.1.0\include

さらに、プロジェクトのビルド時に作成された独自のディレクトリ

1. C:\mingw\include

ここで何が間違っていますか？最初の 2 つのディレクトリのいずれかをインクルード ディレクトリとして使用する必要がありましたか? 私はこれが私が物事を作り上げた場所だと思います。

ドキュメントでは、std::vector<bool>すべてのブール値が 1 ビットを占有するようにすることで、スペース効率が最適化されていることがわかります。ドキュメントから：

std::vector を空間効率的にする方法 (および最適化されているかどうか) は、実装によって定義されます。

これは、コンパイラの実装に依存するということですか? サポートしている場合、コンパイラがサポートしているかどうかはどこで確認できますか? なぜ彼らはそれをサポートしたくないのですか? 本当にシンプルで効率的な実装のようです。

そうでない場合、この最適化を実行したい場合、それは何を意味し、何を意味しますか?

TDM GCC ツールセットを使用しています。

コンパイラ: TDM-GCC-5.1.0 (SJLJ アンワインド)

で遊んでいてdeclval、それが機能するはずのコンテキストで使用できないことに気付きました: への引数としてtypeid()。

次のコードでは、declval主な使用例の 1 つである、インスタンスを介さずにメソッドの戻り値の型を取得するために使用します。私が得るエラーは の static_assert メッセージですが、この場合は引数を評価しないdeclvalため、それは不可能なはずです:typeid()

これは私のためにコンパイルされません（でコンパイルした場合-std=c++14）。私の唯一の推測は、コンパイラのバグを発見したか、明らかに間違ったことをしたのにそれが見えないかのどちらかです。後者でしたら、申し訳ありません。

編集：私を助けてくれたildjarnに感謝します。解決策はを使用することですdecltype。したがって、コードの最後の行は次のようになります。

これはうまく機能します。しかし、今私の質問は次のようになります。typeid()とはどちらdecltype()も未評価のコンテキストなので、違いがわかりません。

次のコマンドを使用してサンプル プログラムをコンパイルしています。

質問:

1. MMX、SSE4、および 3DNow を有効にするためのスイッチについて、GCC が不平を言わないのはなぜですか。選択したアーキテクチャ i386 と互換性がありませんか?
2. コンパイラは、i386 で実行できない実行可能ファイルを生成しますか?

プロジェクトに TDM-GCC-64 を使用しています。最小限のソース コードを次に示します (完全なソースには、Python モジュールの初期化用のコードが含まれています)。

そしてMakefile(元のルールはコードをファイルにコンパイルし.soます):

次に、実行すると次のmake testようになります。

も確認libpython35.dll.aしましたnmが、機能はあるようです。たとえば、次のテキストは の出力にありnmます。

では、どこに問題があるのでしょうか。ありがとう。

私は最近、netbeans を使用して c でプログラミングするようになりました。私は通常コードブロックを使用します。この目的のために、tdm-gcc と msys をインストールしました。

プログラムは正常にコンパイルされています。しかし、実行すると、ビルドに失敗しました（終了値2）が表示されます。

誰かが私が間違っていることを手伝ってくれますか?