元スレCygwin + MinGW + GCC 相談室 Part 4
gcc覧 / PC版 / みんなの評価 : ☆
前へ
251 = :
だから知らないならレスしないでください
252 = :
ほかに誰か知ってる人はいませんか？
253 = :
>>251, 252
くだらない悪ふざけはν速にでも行ってやれや。
254 = :
質問： どちらが新しいんですか？
答え： サイズが違うと何か問題ある？
頭おかしいの？
256 = :
>>254
とっとと失せろ、ゴミクズ
257 = :
ニートタイムに喚くなよ
見苦しいな
258 = :
で？
けっきょく、どれが新しいかわからないんだろ？
知らないならレスすんなよ。
あんたに質問したんじゃねーーーーーーーよｗ
259 = :
ファイルの日付も読めない奴に使える訳もないな
260 = :
>>258
瞬時にリリースバージョンくらいわかりますが、何か？
バージョンを読みとってるからこそ>>248なのだが。
お前は、自分が書いたものと248をみてもまだ理解できないわけだろ？
だから>>250の安定版を入れろと言うことなんだが。
Technological Previewってのは人柱用なんだぜ。
なぜあえてこれを入れたいんだ？
バカだからか？
261 = :
わかったわかった。俺が悪かった。ここはひとつ、俺がオトナになろう。
で、リリースバージョンの見方をおしえてください。おねがいします。
262 = :
事情を説明いたしますと、
安定版が安定しないから、試しに全部新しいのにしてみようと思っただけです。
それで安定するか、しないか、検証してみるだけです。
「問題の切り分け」 を死体のです。
263 = :
>>261
逆に煽り返されたりして、出来もしないくせに下手なことしないほうがいいよなぁ
264 = :
>>262
おとなしくVC++いっとけ
265 = :
ぜんぶ 1.0.11 なので、どれが新しいのかわかりません。
でも確実に、中身が違うんです。
267 = :
なんか迷宮に迷い込んでいるような気がするなぁ・・・
問題の切り分けをするのであれば、安定版のどの部分が安定
しないのか切り分けるのが先では無いだろうか。
全部最新版に差し替えて安定したところで、どの部分が問題
だったかは結局分からないのでは。
268 = :
パッケージとバラを同じ項目においておきながら、
バラの方が古いなんてアホな管理をするやつがいるとも思えんが。
269 = :
つーかさ、不安定があるのなら、どういう不安定なのか書けよな～
他のユーザーのためにもなる。
270 = :
俺は MSYS のデバッグしてんじゃねぇぞ。
どの部分が問題だったかは結局分からなくても
安定して使えさえすればＯＫなんだよ。
271 = :
>>270
だからよぉ、他人にもどう不安定か情報出せよ。
自分だけ情報を得られたらそれで桶かよ。
マサにカスだな
272 = :
>>270
問題の切り分けをしたいとか言いながらちゃぶ台ひっくり返すし、
ここまでMSYSが問題なんだとは一言も話をしていないし、
しかも大人のふりしたと思ったらまた退行しているし。
273 = :
>>271-272
ゴミの相手するなよ
274 = :
新しいのと古いのと見分け方を聞きたかっただけなんだが・・・
275 = :
もったいぶらずに教エロ
276 = :
もったいぶらずに着エロ
277 = :
>>276
ありがとうございます。おかげさまで解ケツしました。
278 = :
g++ってワイド文字列環境はまともになってる？
g++ (GCC) 3.4.5だと、
std::wcoutって何だか分かりません見たことも聞いたこともありません
的なコンパイルエラーがでちゃうんだよね。
279 = :
>>278
今は無理。まともにサポートできる見通しが立たないから宣言自体が無効化されてる。
今公開テスト中の Cygwin 1.7 には wchar_t 関連の C 標準関数がひととおり実装されてるんで、
その上で動く g++ なら使えるようになるかもしれない。
280 = :
>>278
この4.3.3使え
http://www.tdragon.net/
281 = :
そもそも何でMinGWって最新のGCCを同梱してないの？
>>279
ふーん、まだダメダメなのか。残念だ。
>>280
TDM/MinGW Installer
1.902.0
Released 2009-02-28 Bundled Installer: [tdm-mingw-1.902.0-f1.exe] (23.8 MB)
Includes C and C++ SJLJ packages from GCC 4.3.3 TDM-1, plus binutils (2.19.1), mingw-runtime (3.15.2),
w32api (3.13), mingw32-make (3.81-20080326-3) and gdb (6.8-mingw-3).
ってやつか？すげぇなコレ。
いわゆる人柱版ってことかな？
283 = :
>282
質問の答えじゃないが、fork するんなら pipe(2) 使えばループで待つ必要もないんじゃないの？
285 = :
質問の答えじゃないが、popen()で事は足りないのかな?
286 = :
ファイルを先頭から順次読み込むプログラムで，
以下のようなものを書いたのですが，ファイルの途中なのにもかかわらずループを抜けてしまいます．
(どうも0x1Aを読み込んだときにbreakがかかるようです．)
for ( ; ; ){
c = fgetc(fp);
if (c == EOF)
break;
/*
省略
*/
}
Linux上のgcc(2.95.3)でコンパイルした場合は正常に動くのですが，
MinGW(5.1.4)だと前述したように，正常に動きません．(fgetcの仕様が違うのでしょうか)
とてもくだらない質問に思えて恐縮なのですが，解る方がいたら教えてください．
287 = :
fopenでtext modeでファイルを開くと、0x1aをEOF(=CP/Mの)と見なすから。
http://www.google.co.jp/search?q=fopen+EOF+0x1a
288 = :
mingwのライブラリはVC仕様なので
バイナリモードで開いてみては
fp = fopen( path, "rb" ); // こんな感じ?
# たしか Windows/DOS ではテキストモードで開くと 0x1a を
# EOF として扱う仕様だったような気がする
# unixはテキストモードはなし
289 = :
>>287-288
素早い返答ありがとうございます．
ご指摘のとおり，fopenのモード指定の問題でした．
VC系だとテキスト/バイナリの区別がある，というのを初めて知りました．
googleにもスバリ書いてあることだったようで，お恥ずかしい限りです．
291 = :
gccのバージョンによって、gmonのフォーマットが途中で変わってるので、
gccかgprofのバージョンを変えてみると良いらしい。MinGWもgcc3.4.5と
手元のgprofとの組み合わせではダメで、gcc4.3.2や4.3.3では取れるなあ。
これは古いgprofを試さないといけないのかな。
292 = :
>>291
CygWin/g++でgprof以外にﾌﾟﾛﾌｧｲﾙ取るすべあるでししょうか？
最近の人はどうやってプロファイル取ってるの？
293 = :
>>291
横レスだけど情報ありがとう。
古い MinGW の gcc 3.2.3 + gprof 2.13.90 だと OK で
比較的新しい gcc 3.4.5 + gprof 2.18.50 だと NG なんで困っていた。
MinGW の binutils-2.18.50 にはバグがあって gprof が正常に動作しないらしい。
http://www.nabble.com/gprof-time-accumulation-problem-td19125108.html
binutils-2.17.50 だと問題ないということなのでダウングレードして
gcc 3.4.5 と一緒に試したところ、正しく統計情報が取れるようになった。
294 = :
すっかり忘れてたけど、次の日動かしてみたら、MinGW 3.4.5とgprof 2.19、2.19.1での動作を確認した。
だから前回書いたことは、全くの見当違いでgprof 2.18.50だけの問題みたい。ごめんね
>>292
おそらくだけど、プロファイラ自体を使ってる人が少なく、使ってる人も自前で
gprofをbuildか、バージョンダウンしてる。
295 = :
まあ、わざわざMinGWでgprof使おうと思う人は少ないだろうなぁ。
298 = :
質問です。PC-98のMS-DOS上でDJGPPとNASMとBorland C++ 3.1Jでプログラムを
組んでますが、たとえばHello, World!を作ってもDJGPP(GCC v4.3.2)では異常に
実行ファイルのサイズが肥大化します。動作もBCCでコンパイルしたものより
重いです。
DJGPPのFAQによると、「DJGPP(DOS版GCC)はメモリモデルにflatを用いており、
プロテクトモードで4GBまでのメモリを扱えるようにしています」とのことなんですが、
これが原因ですか？ちなみにHELLO.EXEを実行するにしても、DPMIサーバ(cwsdpmi.exe)が
必要という糞仕様です。開発マシンはPC-9801DA2(80386 20MHz + Cyrix 387コプロ;
RAM 13.6MB; SCSI HDD 4.3GB; 緑電子SCSI-2ボード; NEC版MS-DOS 6.2)です。
HELLO.EXEのファイルサイズとコンパイル時間は
BCC = 6.6KB ; コンパイル時間 = 5秒
DJGPP = 44KB ; コンパイル時間 = 2分近く
NASM = 22Bytes ; コンパイル時間 = 3秒
(コンパイルオプションは、
A:\>bcc -ms -O2 hello.c
A:\>gcc -Wall -O2 -s -fomit-frame-pointer -o hello.exe hello.c
A:\>nasm -fbin -o hello.com hello.asm
です)
異常な事態です。これはDJGPP(GCC)の仕様なんでしょうか！ご教示ください。
ちなみに同機能をDOSファンクションコールAH=09Hでフルアッセンブル実装した
HELLO.COMはわずか22バイトですOrz K6-2 550MHz/64MB/18GBのX-Mateがあるんですが、
それでやっても処理系の差異は変わらないですよね？
300 = :
× X-Mate
○ X-MATE
どうしてもDJGPP(GCC4.3.2)だと44KB近くなってしまうようで、
三秒のウェイトを置くdelay機能も、GCCとBCCで同等のものがありますが、
BCC版は8KB程度、GCC版は48KBほどになり、気違いじみています。
やはりDOSファンクションコール AH=2CHでフルアッセンブル実装した
DELAY3K.COMは、ファイルサイズが22バイトでCPU負担も全くありません
(HELLO.COMは28バイトでしたすいません)。
Borland C++ v3.1Jは中古でオクで競って7千円で買ったので製品とはこういうものだと
いわれればそれまでですが、ちゃんとstripもしてるのに、これ以上はGCCは無理ですか！？
みんなの評価 : ☆
gcc一覧へ類似してるかもしれないスレッド
- Cygwin + MinGW + GCC 相談室 Part 8 (938) - [97%] - 2022/10/28 8:00
- Cygwin + MinGW + GCC 相談室 Part 7 (996) - [97%] - 2014/9/21 2:15
- Cygwin + MinGW + GCC 相談室 Part 6 (981) - [97%] - 2012/12/30 23:15
- Cygwin + MinGW + GCC 相談室 Part 5 (981) - [97%] - 2011/4/6 2:32
- Cygwin + MinGW + GCC 相談室 Part 3 (1001) - [97%] - 2008/9/12 0:04 ★
- 【激遅】AppleGCC【絶望】 (111) - [1%] - 2010/1/15 10:31
トップメニューへ / →のくす牧場書庫について