私はGNU g ++でコマンドラインプログラムをビルドしコンパイルしました。これは主に深い継承、たくさんのオブジェクトが作成されたなどの理由でスタックを "オーバーフロー"させます。リンクする際はMac OS X上でこの問題を回避するには、問題を解決するために：gnu g ++を使ったウィンドウのスタック制限の回避策
-Wl,-stack_size,0x10000000,-stack_addr,0xc0000000
は、Linuxの下で、私はちょうどulimit -s unlimitedを試してみました。このように、プログラムを実行すると、GNU G ++でWindows上でそれをコンパイルしようとすると、コンパイラが認識しない任意の
よりしかし、セグメンテーションフォールトを与えるものではありませんが、として使用することになり、他にどのようなオプション
-Wl,-stack_size,0x10000000,-stack_addr,0xc0000000
問題の回避策？事前に
おかげ
-Wl,--stack,somelargesizeはあなたが後にしているもののように見えます。しかし、大規模な割り当てのためにヒープを使用するようにコードをリファクタリングすることを強くお勧めします。アドレス空間は有限のリソースであり、あなたの「回避策」はかなり大きなチャンクを要求します。
ええと、ヒープはアドレス空間も使用しています... –
@Andy：しかし、そのサイズは固定2Mbにデフォルトではなく、彼のアプリケーションをフィットさせるために256Mbを前面に出す必要はありません。 Cライブラリは彼のために大きな割り当てを管理するのにはかなり良いです。 – moonshadow
This pageは（-fno-スタック限界を検索）次のコマンドラインオプションをしようとする場合がありますことを示唆している：
-fno-stack-limit
それは自分自身で失敗した場合は、this other pageも追加することを提案：
-fstack-check
こんにちは！ 私はIDE DEV-C++（流血から）でこれらのオプションを試しましたが、まだスタックオーバーフロー、ヒントがありますか？ – flow
この回答は間違っています。このオプションは、スタックが特定の値を超えて成長しないようにするコードを生成します。スタックが大きくなり過ぎるとプログラムが失敗するのをチェックするだけです。 –
「マンリーの深い遺産」がこの問題の一部となるかどうかはわかりません。 。 。 –