私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレCygwin + MinGW + GCC 相談室 Part 4
gcc スレッド一覧へ / gcc とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ☆
レスフィルター : (試験中)
シンボリックリンクできるけど、mklinkがcmdの内部コマンド?なのか、
cygwinやmsysじゃ使えないんだよね。
わざわざcmd起動してリンク作ってるけど。
cygwinやmsysじゃ使えないんだよね。
わざわざcmd起動してリンク作ってるけど。
>>157
使っているライブラリによって異なる。
たとえばGCC自身はprintf()の実装は提供してない。UNIX上で使っている
ならそのOSのマニュアルだし、MingwだったらMicrosoftのサイトを見る
べき。
使っているライブラリによって異なる。
たとえばGCC自身はprintf()の実装は提供してない。UNIX上で使っている
ならそのOSのマニュアルだし、MingwだったらMicrosoftのサイトを見る
べき。
XPで使ってたCygwin+MinGWの環境をそのままWin7に持ってきたんですが
gitとかpatchとかコマンドが全然動きません。
どうしたらいいんですかこれ…
gitとかpatchとかコマンドが全然動きません。
どうしたらいいんですかこれ…
>>163
なんかエラーが出るの?
なんかエラーが出るの?
どうしたらいいかと言えば、自分の作業に問題が無いか見直し、それでもだめだと確信できるなら、
問題を切り分けて、Windows 7 βのフィードバックを入れるか、
CygwinかMinGWにバグ報告を送りつけるかに決まっているだろう。
問題を切り分けて、Windows 7 βのフィードバックを入れるか、
CygwinかMinGWにバグ報告を送りつけるかに決まっているだろう。
http://bitwalk.hp.infoseek.co.jp/
を参考にLinux(Fedora10)にMinGWのビルド環境を構築しているのですが
gcc(configure --target=i386-mingw32)のmakeに失敗します
binutilsは2.19、gccは3.4.6です
Linux上でMinGWのクロスコンパイル環境の構築に成功している人はいますか?
他に何か必要な物とかあったら教えてください。よろしくお願いします
を参考にLinux(Fedora10)にMinGWのビルド環境を構築しているのですが
gcc(configure --target=i386-mingw32)のmakeに失敗します
binutilsは2.19、gccは3.4.6です
Linux上でMinGWのクロスコンパイル環境の構築に成功している人はいますか?
他に何か必要な物とかあったら教えてください。よろしくお願いします
>>168
F10なら、mingw32のパッケージがyumでインストール出来るよ。
F10なら、mingw32のパッケージがyumでインストール出来るよ。
>>170
基本的にはmsysでsourceからbuildするものだけど、pathやバージョン古くて通らないのも沢山ある。
そういう時は、cygwinか、coLinux等でcross compile環境を作ってbuildする。
MSYS-bashのpath周りをもっと柔軟にすれば、通りやすくなるのかもねえ
基本的にはmsysでsourceからbuildするものだけど、pathやバージョン古くて通らないのも沢山ある。
そういう時は、cygwinか、coLinux等でcross compile環境を作ってbuildする。
MSYS-bashのpath周りをもっと柔軟にすれば、通りやすくなるのかもねえ
g++ (GCC) 3.4.5 (mingw-vista special r3)
new が argc 直前のアドレス取りやがるんですが
私はどんな壊し方をしたのでしょう?
new が argc 直前のアドレス取りやがるんですが
私はどんな壊し方をしたのでしょう?
×argc → ○argv 直前のアドレス
main (int argc,char **argv){
int* buf = new int [100];
↓ が何故か
int* buf =new ( argv - 1) int [100];
int* buf = new int [100];
↓ が何故か
int* buf =new ( argv - 1) int [100];
>>176
「が何故か」ってそれをどうやって確認したの?
「が何故か」ってそれをどうやって確認したの?
無料なのでMinGWでウィンドウズのアプリを作るのを勉強しようとしたら説明してるサイトが見つからない。
これはどうしてなのでしょうか?
MinGWのインストールやコンパイルを説明してるサイトは沢山あります。
MinGWはインストールして他人のソースをコンパイルして満足するだけのもののような感じを受けます。
これはどうしてなのでしょうか?
MinGWのインストールやコンパイルを説明してるサイトは沢山あります。
MinGWはインストールして他人のソースをコンパイルして満足するだけのもののような感じを受けます。
なぜならMinGWでもVisual C++でもBorand C++でもWindowsアプリの作り方は同じだから。
MinGWの解説をしているとこは、MinGW特有の部分の解説に徹しているだけのこと。
MinGWの解説をしているとこは、MinGW特有の部分の解説に徹しているだけのこと。
倍精度の浮動小数点演算を多用する、レイトレーサの一種を書いてます。
VC++ 2008 Express Edition と icc 9.0 では問題なく動作するのに、
MinGW の GCC だと計算結果がおかしくなります(レイが想定外の場所に
飛んでいってしまう)。GCC の3つのバージョンを試しましたが変化なし。
gcc version 3.2.3 (mingw special 20030504-1)
gcc version 3.4.5 (mingw-vista special r3)
gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC)
実行環境は XP SP3 です。何かちょっとしたことを忘れている気がするん
ですが、アドバイスをいただけませんか。よろしくお願いいたします。
>>178
基本的に VC++ やなんかと同じ要領で Win32 API を使ってアプリからでは。
Win32 API を使ったプログラミングは情報がたくさんありますよね。
Unix 環境のつもりでプログラムを書き始めるとライブラリ関数があれも
これも無くて泣きを見ます。例えば
・GUI は Win32 API で手書きするか Win32 環境で使えるツールキットを使う。
・gettimeofday() が無いので計時には Win32 の QueryPerformanceFrequency(),
QueryPerformanceCounter() を使う。
・共有ライブラリの動的リンクは dlopen() ではなく LoadLibrary() でやる。
・OpenGL を使うには Win32 固有の wgl 関数群を用いる。
・Win32 に移植された pthread ライブラリを使うのでなければ
pthread_create(), pthread_mutex_init(), pthread_mutex_lock() ではなく
CreateThread(), CreateMutex(), WaitForSingleObject() を使わないといけない。
といった具合です。Win32 環境のつもりで情報を集めるとよろしいかと。
VC++ 2008 Express Edition と icc 9.0 では問題なく動作するのに、
MinGW の GCC だと計算結果がおかしくなります(レイが想定外の場所に
飛んでいってしまう)。GCC の3つのバージョンを試しましたが変化なし。
gcc version 3.2.3 (mingw special 20030504-1)
gcc version 3.4.5 (mingw-vista special r3)
gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC)
実行環境は XP SP3 です。何かちょっとしたことを忘れている気がするん
ですが、アドバイスをいただけませんか。よろしくお願いいたします。
>>178
基本的に VC++ やなんかと同じ要領で Win32 API を使ってアプリからでは。
Win32 API を使ったプログラミングは情報がたくさんありますよね。
Unix 環境のつもりでプログラムを書き始めるとライブラリ関数があれも
これも無くて泣きを見ます。例えば
・GUI は Win32 API で手書きするか Win32 環境で使えるツールキットを使う。
・gettimeofday() が無いので計時には Win32 の QueryPerformanceFrequency(),
QueryPerformanceCounter() を使う。
・共有ライブラリの動的リンクは dlopen() ではなく LoadLibrary() でやる。
・OpenGL を使うには Win32 固有の wgl 関数群を用いる。
・Win32 に移植された pthread ライブラリを使うのでなければ
pthread_create(), pthread_mutex_init(), pthread_mutex_lock() ではなく
CreateThread(), CreateMutex(), WaitForSingleObject() を使わないといけない。
といった具合です。Win32 環境のつもりで情報を集めるとよろしいかと。
>>183
レスありがとうございます。
このスレの Part 3 で _controlfp のことを教えていただいたのは私です。
カキコの直後まで失念しておりました。
_controlfp(_PC_64, _MCW_PC) だと GCC と ICC では NG、VC++ では OK で
_controlfp(_PC_53, _MCW_PC) だと3つのコンパイラすべてで OK でした。
また髪の毛が減ってしまいました。本当にありがとうございました。
レスありがとうございます。
このスレの Part 3 で _controlfp のことを教えていただいたのは私です。
カキコの直後まで失念しておりました。
_controlfp(_PC_64, _MCW_PC) だと GCC と ICC では NG、VC++ では OK で
_controlfp(_PC_53, _MCW_PC) だと3つのコンパイラすべてで OK でした。
また髪の毛が減ってしまいました。本当にありがとうございました。
個人的な感想ですけどVC2008EEはなかなか良かったよ。
この茨の道を突き進むよりも初心者はVCのほうがいいと思われ。
この茨の道を突き進むよりも初心者はVCのほうがいいと思われ。
>>184
あの思うですけど、そこまでしてネイティブ・コンパイラにこだわる意味はあるんですか?
たぶん良くあるプログラミングの落とし穴だと思うんですが、
計算のロジック部分はジャバやCシャープにして、描画やレンダリングのところだけネイティブ(Cコンパイラ)にすれば、髪の毛もフサフサのままですよ。
もしCやフォートランしか知らないというなら、あなたの勉強不足が原因なので自業自得なんですけど。
あの思うですけど、そこまでしてネイティブ・コンパイラにこだわる意味はあるんですか?
たぶん良くあるプログラミングの落とし穴だと思うんですが、
計算のロジック部分はジャバやCシャープにして、描画やレンダリングのところだけネイティブ(Cコンパイラ)にすれば、髪の毛もフサフサのままですよ。
もしCやフォートランしか知らないというなら、あなたの勉強不足が原因なので自業自得なんですけど。
>>187
だよなぁ俺も逆だと思うよ
だよなぁ俺も逆だと思うよ
そうか?
ウェブアプリとかビジネスロジックといわれる部分は、ハード特有じゃないのでジャバとかのほうが向いてると思うんだが・・
逆にダイレクトXとかネットワーク・メッセージ機構の言語外(ハード部分)はMSとかジャバでもいいけど、例えばジャバに「ウインドウのハンドルを取得するAPI」が用意されてないと結局ネイティブAPIを使うから、ネイティブ向けのコンパイラが必要になってくる。
というか、そこまで計算のロジック(アルゴリズム)を速くしてこだわってるなら、一つのコンパイラに徹するべきであって、GCC使ってみたりBCCやICC使って浮気する必要はないと思うんだけどなあ。
やってみれば分かると思うけど、結局早くて効率的なロジックをフォートランとかICCで実装したところで、ウインドウズならDLL呼び出し関数呼び出しのコストで相殺されるからあまり関係なくなるんだけど。
どういうの作ってるかわからないけど、PC並に複雑な機構のOSだと、そもそもロジックが速いとか、プリミティブ型(double)の演算誤差がどうとかあまり関係ないんじゃない?
ウェブアプリとかビジネスロジックといわれる部分は、ハード特有じゃないのでジャバとかのほうが向いてると思うんだが・・
逆にダイレクトXとかネットワーク・メッセージ機構の言語外(ハード部分)はMSとかジャバでもいいけど、例えばジャバに「ウインドウのハンドルを取得するAPI」が用意されてないと結局ネイティブAPIを使うから、ネイティブ向けのコンパイラが必要になってくる。
というか、そこまで計算のロジック(アルゴリズム)を速くしてこだわってるなら、一つのコンパイラに徹するべきであって、GCC使ってみたりBCCやICC使って浮気する必要はないと思うんだけどなあ。
やってみれば分かると思うけど、結局早くて効率的なロジックをフォートランとかICCで実装したところで、ウインドウズならDLL呼び出し関数呼び出しのコストで相殺されるからあまり関係なくなるんだけど。
どういうの作ってるかわからないけど、PC並に複雑な機構のOSだと、そもそもロジックが速いとか、プリミティブ型(double)の演算誤差がどうとかあまり関係ないんじゃない?
レイトレを書いてるらしいから、数値計算メインで
DLL呼び出し関数呼び出しのコストはほとんど無いような
思いっきりネイティブ向けの希ガス
DLL呼び出し関数呼び出しのコストはほとんど無いような
思いっきりネイティブ向けの希ガス
レイトレはやったことないけど、そのロジックをストリーミング用のプログラミング手法(GPUとかCELL)に持ち込めれば、100倍ぐらい速くなるんじゃないか?
昔のままネイティブAPI(OSコール)てんこもりでソースもforとifだらけってのでも別にいいけど、画像解析じゃなくてただのレンダリングだし、そういうプログラミング・スタイルはもう流行らないと思う。
どっちにしてもネイティブ・コンパイラ使ってるくせに気軽に浮気するような素人じゃろくなもんじゃないだろうけど。
昔のままネイティブAPI(OSコール)てんこもりでソースもforとifだらけってのでも別にいいけど、画像解析じゃなくてただのレンダリングだし、そういうプログラミング・スタイルはもう流行らないと思う。
どっちにしてもネイティブ・コンパイラ使ってるくせに気軽に浮気するような素人じゃろくなもんじゃないだろうけど。
ここ10スレ位の書き込みは酷いな。
複数のコンパイラを通すのは、移植性やソースをクリーニングする為の超基本。
限られた精度の計算とloopが主なレイトレで、javaとかfortranて何のネタ?
borlandは1番parserの出来が良いので、初心者の多い2ちゃんではお薦め。
windowsのgccにもgettimeofdayはある。ぐぐって出てくるし、
unofficialな自宅の4.3.3でも通った。
iccは知らないけど、VCってdefaultでSSE使って無かったっけ?
俺なら計算結果をファイル出力してdiffするけど。
ところでsjljなgccでレイトレって凄く遅くない?Dwarf2も試そうよ。
libraryコンパイルし直すのに少し苦労するけど。
複数のコンパイラを通すのは、移植性やソースをクリーニングする為の超基本。
限られた精度の計算とloopが主なレイトレで、javaとかfortranて何のネタ?
borlandは1番parserの出来が良いので、初心者の多い2ちゃんではお薦め。
windowsのgccにもgettimeofdayはある。ぐぐって出てくるし、
unofficialな自宅の4.3.3でも通った。
iccは知らないけど、VCってdefaultでSSE使って無かったっけ?
俺なら計算結果をファイル出力してdiffするけど。
ところでsjljなgccでレイトレって凄く遅くない?Dwarf2も試そうよ。
libraryコンパイルし直すのに少し苦労するけど。
ISO-Cに準拠したいのか、よりネイティブ向けに特化したプログラムを作って速度や効率を稼ぎたいのか、君は何をやりたいのか意味不明。
超基本は、ISO-Cに準拠して君の満足であるかどうかではなくて、仕様や要求を満たしたプログラムであるかどうかじゃないか?
それこそ計算部分のロジックとネイティブのハード部分を分離するような設計(使用)をすることのほうが基本だと思うが、どうだろう。
昔から構造化プログラム(モジュール化)やオブジェクト指向など方法論があるわけで、
君の主張するプログラミングスタイル(複数のコンパイラを通すだと?!)はまったく流行らないと思うが?
君のような宗教観では、どうでもいいところに神経使ってばかりで、さらに髪の毛をなくしていくんだろうけどw
超基本は、ISO-Cに準拠して君の満足であるかどうかではなくて、仕様や要求を満たしたプログラムであるかどうかじゃないか?
それこそ計算部分のロジックとネイティブのハード部分を分離するような設計(使用)をすることのほうが基本だと思うが、どうだろう。
昔から構造化プログラム(モジュール化)やオブジェクト指向など方法論があるわけで、
君の主張するプログラミングスタイル(複数のコンパイラを通すだと?!)はまったく流行らないと思うが?
君のような宗教観では、どうでもいいところに神経使ってばかりで、さらに髪の毛をなくしていくんだろうけどw
>>193
ソースで配布するんですか?
windowsだとハードが常に進化するんで、そのときのハードにあったAPI(DirectXなど)を使い、
そのプログラムに一番最適なコンパイラ(Cに限らない)を使ってDLLなどのバイナリで配布する方式の方が受けると思うんですけど・・・
ソースで配布するんですか?
windowsだとハードが常に進化するんで、そのときのハードにあったAPI(DirectXなど)を使い、
そのプログラムに一番最適なコンパイラ(Cに限らない)を使ってDLLなどのバイナリで配布する方式の方が受けると思うんですけど・・・
>>193
もしかして「Javaは遅い」とかを信じちゃってるJIT以前のオジサン?w
もしかして「Javaは遅い」とかを信じちゃってるJIT以前のオジサン?w
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 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
トップメニューへ / →のくす牧場書庫について