INCLUDE_PATHにlibのpathって入れるんだっけ

>>651
gcc3系統とgcc4系統ではディレクトリ構成が変わっていて，gcc4系統の場合はlibの奥にもヘッダファイルが
あるので，入れる必要があります。

MinGW使うなら、PATH以外の環境変数は設定いらなくね？

友達がプログラミング勉強したいっていってるんだけどやっぱ

進める環境としてはdev c++ とmingwがいいかな

VC2008EEじゃねーのか？

>>654
単にプログラミングの勉強ならば、
WindowsでVisualBasicが面倒なくて鉄板でしょ。
Unixの世界は、環境構築とツールの使用法の習得だけで
挫折する人がいるくらいのカオスな世界だから、
できれば知らない方が幸せよ。

>>656
> 単にプログラミングの勉強

変ったジャンルですね。

>>656

僕的にはdev c++のほうがインストールが早いし、設定、認証が要らないから
こっちのほうが簡単だと思うんですけどね。やっぱVCとかVBですかね

Dev-C++はTDM-MinGWと組み合わせて俺もインストールしてあるけど
何と言ってもメニューが全部英語なのと、gccそのものがオプションが複雑で
決して初心者向けではないという事情を考えてVCを推している

でも自分でその壁を乗り越えられる人であればgccの方が標準準拠度は
高い

お勉強ならLL言語でいいでしょ。
CUIベースでC, C++なんてやってもイベント丼の概念が理解できなくなる。

つまり Tcl/Tk やっとけということだな

>>659
日本語化されたのが、確か2つくらいあったはず。ｓけいし氏のヤツは割りと有名
かと思ってたんだがそうでもないのか。
一時VC2003と交互で使ってたけど、x64環境に移行してからはVC2008しかｔ

これ以上はスレチだな。

Dev-c++ と一緒に入ってくる gcc3.4.2 を
TDM-MinGW gcc4.4.1 に入れ替えたのですが、
gcc3.4.2
・iostreamをincludeするだけで、EXIT_SUCCESSマクロもatof()関数も使用できた
・iostreamをincludeするだけで、clock()関数が使用できた
gcc4.4.1
・cstdlibをincludeしないと、EXIT_SUCCESSマクロもatof()も使用できない
・ctimeをincludeしないと、clock()関数が使用できない

という挙動になります。
どっちが正しいんですか？

>>663
4.4.1 の方がより規格に沿っていると言える。

MinGWで日本語を表示するにはどうすればいいんですかー？(>_<)

>>665
-finput-charset=cp932 -fexec-charset=cp932
をコンパイル時に付ける
するとEUCに変換してからコンパイルしてくれるのでダメ文字の問題は起きない

UTF-8

>>666
それ、本家MinGWのgcc4系だと効かない。cc1.exe、cc1plus.exeにやlibiconvがリンクされてないんだそうだ。
gcc3.4.5のcc1とcc1plusで上書きすればOKという情報もあるけど、俺のところじゃダメだった。

TDM's MinGW gcc4.4.1なら大丈夫。

>>667
もちろんそれでもOK。ただ、これまでに書きためた大量のSHIFT_JISのソースを使ったり、
3rd Partyのヘッダーファイル（例えば何等かのIOボードにボードに付いてくるライブラリの
ヘッダーファイル）を使ったり、他のコンパイラと共用するソースファイルを使ったり
する場合にはそうも行かない場合もある。

665ですが、IDEの起動オプションをUTF-8にしたら表示されました。
お騒がせしました。

>>668
Windowsのシステムロケールを日本語から英語に変更するといい

>>668
既にバイナリの gcc 4 がある状況なら
gcc 4 をビルドするのはたやすい。
libiconv 有効にしてビルドしれ

>>670
レスサンクスなんだが．．．

> Windowsのシステムロケールを日本語から英語に変更するといい

これは >>668 に書いたうちの、どのことについて言ってるの？


>>671

> 既にバイナリの gcc 4 がある状況なら
> gcc 4 をビルドするのはたやすい。
> libiconv 有効にしてビルドしれ

あぁそれでいいのか。アリガト。
ただ最近ビルドしてばかりしていてチト疲れた。

本家MinGWの最新バイナリインストーラー(5.1.6)のgccは4.4.0でなかったり、
libiconvがリンクされていない抜けがあったり、更新が遅かったりで、
TDM版の方が信頼できると感じてる。

TDM版の最初の4.4.1でCPU利用率が100%近くになってしまう問題が発覚した
時もHPの上の方に「Warning!」としてちゃんと説明が書いてあったし、修正の
対応も比較的早かったしね。

それと試してないんだけど、>>556の問題も気になる（TDM版固有の問題なのか、
gccのバージョンの問題なのか） 。

とりあえずTDM版4.4.1で問題ないので、俺は当面これで行こうと思う。

>>672
インストーラが 4.4.0 を入れないのは怠慢ではなくて、そういう選択をしたのだと思う。
まだ実績が不充分ってこともあるし、互換性の問題もある。
エンドユーザーにはなるべく枯れたバージョンを提供する方がいいという考え方はあり得る。

libiconv のリンクも、世界全体から見れば案外少ない状況でしか必要としないし、
そもそもソースコードにマルチバイト文字列をハードコーディングするのは悪いスタイルだよ。

よがりごえ

>>673
本家擁護も結構だが、

> インストーラが 4.4.0 を入れないのは怠慢ではなくて、そういう選択をしたのだと思う。
> まだ実績が不充分ってこともあるし、互換性の問題もある。

そんなに4.4.0に不安があるのなら、gccだけ独立して正式リリースにしなければいいのに。

そもそも本家はgcc3系とgcc4系でバイナリの互換性がなくなってしまった。
ディレクトリ構成も大きく変更してしまった。

これって良いことなのか？

> エンドユーザーにはなるべく枯れたバージョンを提供する方がいいという考え方はあり得る。

エンドユーザーが自分で選択できるようにすればよいだけの話し。

> libiconv のリンクも、世界全体から見れば案外少ない状況でしか必要としないし、

そう。そういう少数派への配慮が足りない所が問題。

> そもそもソースコードにマルチバイト文字列をハードコーディングするのは悪いスタイルだよ。

余計なお世話。そんなのは状況次第。
日本人の工場オペレーターしか使わないことがわかっているソフトだったら。
ハードコーディングしてしまった方が、短い工数で作れる。

多国語対応する必要があるソフトなら、リソースDLL使うとか、独自のライブラリで言語設定に
あわせてファイルから文字列を読込むとかしてる。

>>675

> そんなに4.4.0に不安があるのなら、gccだけ独立して正式リリースにしなければいいのに。

> エンドユーザーが自分で選択できるようにすればよいだけの話し。

大半のユーザーはとりあえずバージョンナンバーが大きい方を選択してしまうよ。
エンドユーザーってのはそんなもんだろうが。

> そもそも本家はgcc3系とgcc4系でバイナリの互換性がなくなってしまった。
> ディレクトリ構成も大きく変更してしまった。

バイナリ互換性が維持されればそれに越したことはないんだけど、
これは根本的な設計から大幅に変わってしまったので、仕方ないとしか…

> そう。そういう少数派への配慮が足りない所が問題。

> 余計なお世話。そんなのは状況次第。

配慮したらその分だけファイルサイズも増える。
少数派に配慮したら多数派に多少なりとも不便を強いるじゃないか。
ファイルサイズ程度なら些細な問題だけど、依存ライブラリが増えると管理が面倒なんじゃね？
これは開発リソースの割り振りの問題だろう。
それに意見する方が余計なお世話ってもんだろ。
開発状況は libiconv をリンクしたくない状況だったんだろ。

>>676
> 大半のユーザーはとりあえずバージョンナンバーが大きい方を選択してしまうよ。
> エンドユーザーってのはそんなもんだろうが。

何が言いたいのかわからん、俺には>>673に書いてあることと矛盾してるようにしか
受け取れない。悪いがちゃんと説明してくれないか？

> バイナリ互換性が維持されればそれに越したことはないんだけど、
> これは根本的な設計から大幅に変わってしまったので、仕方ないとしか…

TDM版gcc4.4.1は本家のgcc3.4.5とバイナリレベルの互換性を保ってるよ。

> これは開発リソースの割り振りの問題だろう。
> それに意見する方が余計なお世話ってもんだろ。
> 開発状況は libiconv をリンクしたくない状況だったんだろ。

ファイルサイズの話はかなり無理矢理感があるなあぁ。
で。本家のgcc4.4.0の説明書き(gcc-4.4.0-mingw32-notes.txt)には、必要ファイルだけ
分割してダウンロードする場合、

> libiconv Runtime [REQUIRED]
> libiconv-1.13-mingw32-dll-2.tar.gz

と書いてあるんだが（つまり必須と言うこと）。リンクを怠ったか、ドキュメントの修正を
怠ったかのどっちかだとしか思えない。どっちみち瑕疵であることに変わりはない。
で、TDM氏のHPには、

> TDM-GCC is not formally affiliated with or endorsed by the MinGW project
> (although several MinGW team members make use of it)

なんて書いてある。それなら性格がきっちりしていそうなTDM氏に本家のチームに
加わってもらえば、もっと良くなると思うんだが．．．

>>677
> 何が言いたいのかわからん、俺には>>673に書いてあることと矛盾してるようにしか
> 受け取れない。悪いがちゃんと説明してくれないか？

問題点を認識せずにとりあえず最新版を入れてしまうユーザーもいるから
インストーラは 4 を選ばせないようにしたんじゃね？ と言いたかった。

> TDM版 gcc4.4.1 は本家のgcc3.4.5とバイナリレベルの互換性を保ってるよ。

んなわけねーだろ。 何が出来ることをもってバイナリ互換性って呼んでるの？

> ファイルサイズの話はかなり無理矢理感があるなあぁ。

そりゃそーだ。 だから些細なことって書いてるだろ。
結論は開発リソースの割り振りだ。
どっかには問題が残ることもあるだろうさ。
リソースは有限だし、どの問題をどこまで解決するか、
時には手抜きするのもひとつの選択だということだ。

TDM 版だって致命的な問題があったものを警告を書くだけで出したわけだろう？
本家じゃやっちゃいけないことだけど、 TDM 版はそれでも出すという選択をしたわけだ。

一応誤解が無いようにいっとくけど、俺は本家を擁護したいわけじゃないよ。
どこを重要視するかが違うだけのことであって、どっちが良いとか言えるものじゃないというのが俺の主張。

もちろん、本家がよりよくなってくれるのが最も望ましい。

>>678
> 問題点を認識せずにとりあえず最新版を入れてしまうユーザーもいるから
> インストーラは 4 を選ばせないようにしたんじゃね？ と言いたかった。

了解。ただ、インストーラーでgcc3.4.5をインストールした後でgcc4を入れようと思うと簡単じゃない
（ディレクトリ構成が変わっているから戸惑う）。そういう点で問題だと俺は言いたい。

> んなわけねーだろ。 何が出来ることをもってバイナリ互換性って呼んでるの？

GUIツールキットQt 4.5のMinGW用のバイナリインストーラーでインストールされるライブラリは本家の
gcc3.4.5でビルドされたものだが、TDM gcc4.4.1でビルドしたアプリからちゃんと使えた。

ところがQt 4.6のbeta-1には、本家のgcc3.4.5でビルドされたライブラリの他に、本家のgcc4.4.0（Qtライブラリ
ではなくてコンパイラそのもの）もバンドルされてきた。ところがこの4.４.0でアプリをビルドすると、エラーが
出てしまう（3.4.5でビルドされたライブラリと互換性がない）。

Qt 4.6 RCになって、ライブラリも本家のgcc4.4.0でビルドされたものに変わった。そうしたら今度はアプリを
TDM gcc4.4.1でビルドするとエラーが出る。仕方なくQt 4.6 RCのソースからTDM gcc4.4.1でQtをビルドしたら
うまく行った。これでわかるだろ？

> TDM 版だって致命的な問題があったものを警告を書くだけで出したわけだろう？
> 本家じゃやっちゃいけないことだけど、 TDM 版はそれでも出すという選択をしたわけだ。

出した後から発覚したんで、緊急で警告を書いたんだよ。だから「修正するまで、一つ前の4.3.3を使ってくれ」
って書いてあった。テストが足りなかったのは確かだが、やるべきことを迅速にやっている。
本家はlibiconvがリンクされていなくても、アナウンス一つしてないんじゃないか？3系と4系でバイナリ互換性
がないというアナウンスも何処かにある？

> もちろん、本家がよりよくなってくれるのが最も望ましい。

俺だって本家を貶すのが目的じゃない。ただ、もっとしっかりしてくれと言いたい。
現状だとTDM版の方が良い選択だと言わざるを得ない状況だ。

>>679
> 了解。ただ、インストーラーで gcc3.4.5 をインストールした後で gcc4 を入れようと思うと簡単じゃない
> （ディレクトリ構成が変わっているから戸惑う）。そういう点で問題だと俺は言いたい。

単に展開するだけだし、俺はディレクトリ構成が変わっていることに気づいてさえいなかったぜ!!
(後から気付いたけど。 これは俺がいいかげんなだけかもしれん。)

> GUIツールキットQt 4.5のMinGW用のバイナリインストーラーでインストールされるライブラリは本家の
> gcc3.4.5でビルドされたものだが、TDM gcc4.4.1でビルドしたアプリからちゃんと使えた。

TDM がどうとかいう以前に gcc の変更だ。 実験してみた結果がどうあれ偶然。
何が起こってもおかしくない。 鼻から悪魔。

> ところがQt 4.6のbeta-1には、本家のgcc3.4.5でビルドされたライブラリの他に、本家のgcc4.4.0（Qtライブラリ
> ではなくてコンパイラそのもの）もバンドルされてきた。ところがこの4.４.0でアプリをビルドすると、エラーが
> 出てしまう（3.4.5でビルドされたライブラリと互換性がない）。

エラーの内容が気になる。
エラーが単なる undefined reference の場合、環境構成上のしょーもないことである場合がある。

> テストが足りなかったのは確かだが、やるべきことを迅速にやっている。

迅速だけどテストが足りなかったんだろ。 だからそれは単にスタンスの違いなんだって。

> 本家はlibiconvがリンクされていなくても、アナウンス一つしてないんじゃないか？

required の記述が間違っとるが、どれどれをリンクしたなんていちいち書くかよ。

> 3系と4系でバイナリ互換性がないというアナウンスも何処かにある？

これは常識だと思ってたから疑わなかったけど、一見さんにわかる形では無いかも。
GCC のサイトの方にも目立つようには書いてない。

きめえ話してんじゃねーよ
オープンソースなんだから好きにやれや

>>681
まったくそのとおりだ。 だから好きに議論する。

便宜上「本家」なんていってるがそれほど絶対的なものではない。
それぞれのスタンスがあるのは当然。

と、言うわけで >>679 が主張するように「TDM 版の方が良い選択」
とする主張を否定するわけじゃないし、その主張が正しいと言える状況はあるんだろう。
でも、そうじゃない状況もある。 それだけの話。

話長いw

>>680

> 単に展開するだけだし、俺はディレクトリ構成が変わっていることに気づいてさえいなかったぜ!!
> (後から気付いたけど。 これは俺がいいかげんなだけかもしれん。)

環境変数変えなきゃダメだろ？本当に動かしてみたんかね？
少なくともC_INCLUDE_PATHやCPLUS_INCLUDE_PATH、LIBRARY_PATHは変更する必要がある。もしかして単に
展開しただけで環境変数変えてないから、gcc4.4.0使ってるつもりで実は3..4.5のままだったりしてｗ

> TDM がどうとかいう以前に gcc の変更だ。 実験してみた結果がどうあれ偶然。
> 何が起こってもおかしくない。 鼻から悪魔。
（中略）
> > 3系と4系でバイナリ互換性がないというアナウンスも何処かにある？
>
> これは常識だと思ってたから疑わなかったけど、一見さんにわかる形では無いかも。
> GCC のサイトの方にも目立つようには書いてない。

そんないい加減な情報じゃなくて、しっかり「ここに書いてある」って示して欲しい。そうじゃないと、アンタに「偶然」
だの「鼻から悪魔」なんて書く資格はない。単に実験のレベルじゃないよ。暫く使ってるが、何の問題もない。

> > テストが足りなかったのは確かだが、やるべきことを迅速にやっている。
>
> 迅速だけどテストが足りなかったんだろ。 だからそれは単にスタンスの違いなんだって。

違う。本家はアナウンスすべきことをアナウンスしていない。例えば、MinGW5.1.6のgccは4.4.0じゃなくて3.4.5だって
ことはどこに書いてある？要するにいい加減すぎるんだよ。「スタンスの違い」ってのが「ユーザー重視」と「ユーザー
軽視」の違いってのなら納得できるが。

例えば、ttp://www.mingw.org/wiki/GCCStatus は2009-04-20 以降更新されておらず、現状と合ってない。
SourceForgeのファイルツリーを見ても、「Automated MinGW Installer」のところにリリースノートすら置いてない。

MinGW、いったいいつになったら
gcc4採用するんだよ・・・

goはbuildできますか？

出来ません。

>>685
TDM-MinGWはとうにgcc4.4.1なんだが・・・

>>686
http://d.hatena.ne.jp/iasija/

>>685
本家MinGWだってMinGW5.1.6に含まれていないだけで、gcc 4.4.0は単独で「current release」になってるよ。
TDM版については>>688の言うとおり。

長い話で悪かったが、そのことでずっと>>680とやりあってたんだ。

そろそろ長話を止めてくれ

cygwinをアンインストールしたいんだがどうしても削除できないフォルダとファイルがある（Windows7）
usr\sbin\sendmailとvar\cron\tabs
アクセス許可云々と出てフォルダが削除できない
所有者が長ったらしい変な名前だったのでアクセス権を自分にしてもできない
コマンドプロンプトや強制削除ソフトとか使っても無理
（あと一つ同じようなフォルダがあったがなぜか削除できた）
どなたか知恵をおかしくだ足

msysでcoreを吐かせるにはどうすればいい？
ulimit -a でみてもunlimitedになってるんだが・・・

>>692
どこかのプロセスのカレントフォルダや
オープンしているファイルなどが、そこのフォルダにあると
消せないみたいだよ。

そこにアクセスしているプロセスを終了すればいいと思うけど、
たぶんわからないのだろうから、一回ログオフするか再起動すれば消えるはず。

今TDM版MinDW gcc4.4.1-2のテストを行っています
今までは日本語入出力の問題があってgcc3.4.2を使っていました
あるプログラムを-O3でコンパイルしてみると両方とも10分程度で終わるのですが
3.4.2のほうが20％ほど早くなりました
途中のlogと結果を見るとどちらも-O0の時と同じように動いているように見えます

実際にはこれからプログラムを書き直して10倍100倍の計算をさせたいと思っているのですが
書き方がよくなればTDMの方が早くなるようなものなのでしょうか？

ぶっちゃけ状況による。
3 と 4 はかなり根本から変わってしまってて、
最適化フェイズの構成からして違う。
どちらが速くなるかは実測するべし。

>>696
レスありがとうございます
インストールがめんどくさいですが、
両方でコンパイルしてみて試して見ることにします

え？例えばc:/gcc4/とc:/gcc3/に解凍して
環境変数を使い分ければいいだけの話でないの

mingwのgcc4は

for(i=0;i<10;i++){
for(j=0;j<10;j++){
int a = i;
}
}
みたいなことをしたときに、２重ループ内のiが未初期化だったことがあったのでgcc3に落とした。

それはないだろう