元スレCygwin + MinGW + GCC 相談室 Part 6

gcc覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

501 = :

>>500
よく見たら、書いてありました。すいません。
http://toro.2ch.net/test/read.cgi/unix/1268282846/14

502 = :

MinGW側でmallocしたポインタをVC++側でfreeしたり
FILE*を受け渡したりできるんでしょうか？
できないと思うんだけど、msvcrtを使っているというのはできるという意味でしょうか？

503 = :

ためだろ
解放用の関数なり自作スマポなりで対応しろ
クラスならコンストラクタデストラクタをprivateにしてstaticメソッドかfriendしてる関数からしか生成、破棄できないようにするのもあり

506 = :

>>502
例えばMinGWのgccでコンパイルしたobjをMSVCのclでコンパイルしたobjにリンク
した場合は、可能だよ
（ただし、コンパイラサポート用の特殊なobjやlibを別途リンクする必要が
しばしば生じるし、C++の場合は両者のABIにそもそも互換性がないのでダメだ）

そうではなくて、MinGWで作ったDLLをMSVCで作ったexeから利用するシナリオを
考えているのなら、ダメ

MSVCに閉じた世界であっても、msvcrt.dll, msvcr70.dll, .... msvcr100.dllや
そのデバグ変種はすべて互換性がなく、exeとDLLが同じランタイムDLLを
利用しているのでない限り、そういうことは出来ない（それぞれ別のCランタイムを
ロードしてメモリに保持する形になる）
今のMSVCはデフォではmsvcrt.dllとリンクするようになっていないので
自動的にダメということになるよ

507 = :

ちなみにC++が不要なら、MSVCでmsvcrt.dllとリンクするようにすることは一応可能
WDKを入れて、そちらのincludeとlibを使うといい
ただ色々落とし穴もあるし、事実上（少なくともモダンな）C++は使えない
ネットで検索すると色々情報が得られるはず

508 = :

>>506
objも互換性があるのか。
DLLにしないとVC++側から使えないと思っていました。
ちなみにC++は不要でCだけでいいです。
>>507
逆にMinGW側でmsvcrt80などにリンクするようにビルドすることもできるらしいのですが
MSVC側のCRTのバージョンが上がっていきそうなので、
mallocしたポインタを返してこっちでfreeすることを要求してくるMinGW側のライブラリ(DLL)があって
僕が作っているわけではないオープンソースのライブラリなのでできればコードには触りたくないけど
MSVCから使いたい場合は、
MinGWのDLLをビルドしたのと同じバージョンのfreeを単体のDLLにしてその関数でfreeするのがいい方法でしょうか。

509 = :

たぶんそれで大丈夫だけど、試したことはないな

そのオープンソースのライブラリが一応Windowsをサポートしているんなら
DLL boundaryを超えた場合の問題について開発者に説明して
libfoo_free()のような関数を入れてもらうのが本来は望ましいんじゃないの

objは互換性あるよ、少なくとも32bitでは
gccもwin32ターゲットの場合はCOFFを吐くし、fopenやmallocみたいな関数への
参照はどっちでコンパイルしたとしても最終的にリンク時に解決されるので
そのタイミングでリンクされるCランタイムが使われることになるわけだ

x64だとどうだったかな……x64のABIは確か結構ややこしいことになってるんだよな

510 = :

>>509
今そうしているので動いてはいるんだけど
もっと普通の方法がないのかなと思ったのです。
どうもです。

511 = :

LoadLibraryしてGetProcAddress(msvcrtdll, "free")では？

514 = :

DLLが使っているfreeのアドレスをなんらか判定して取れれば一番いい気がしますけど

515 = :

この手の解決策はハックなので、ライブラリの実装を直してもらえるなら
直してもらったほうがいいのは間違いないわな
ライブラリがリソース解放用の関数を提供していれば、それがMinGWでビルド
されていようが、MSVCでビルドされていようが、問題ないわけで

516 = :

>>514
そのDLLのインポートセクションを見れば一応わかるはず
APIフックなどでは使われる手法だけど、ハックだな

518 = :

個別に直してもらえれば一番いいのはそうですけど
いろいろあるのと今後もまたあるかもしれないので
相手の対応に依存せず自分側だけで対応できる汎用的な方法も持っておきたいというのがあるんですよね。
FILE*の受け渡しなんかはインターフェースの定義だから多分変えてもらえないので
同じバージョンのfopenが使いたいとかもあるし。

DLLと関数を指定して、それがインポートされているDLL名を取得して>>511ってのを試そうと思います。

519 = :

http://bugs.ruby-lang.org/issues/3296
これとかまさに>>516なコードだよな

iconvとかどこでも使われてるのに、エラー通知がerrnoなために
DLL-safeでないってのが終わってる
POSIXだから今更インタフェース変えられるわけもねーし

520 = :

この手の問題ってメモリの処理はどうなってんだろ？
一つのプログラムが二つ以上の標準ライブラリとリンクしてしまった場合ヒープは適切に管理されるのかな

521 = :

少なくとも今のCRTだとmalloc()は大して自分じゃ仕事してねーというか
HeapAlloc()に丸投げなので、CRTのバージョンが違ってもOSの側が
矛盾のないように仕事をしてくれるはず
ただし、それぞれがHeapCreate()で自分専用のプールみたいなもんをこしらえて、
そっからHeapAlloc()していく

OSの同じAPIに仕事させてる以上、それらは衝突はしないんだけれども
プールAから確保したメモリをプールBのものとして開放することはもちろんできない
HeapFree()の関数インタフェース見ればわかると思うけど

malloc()やfree()という関数インタフェースからはプールが見えないんだけど裏では
それぞれ専用のプールが使われるわけで、そこが要注意なわけだ

522 = :

なるほど。低レベルではHeapAllocを使っているならきっと拡張可能で作っていると思うんだが
2つヒープができてしまった場合効率的に使えるのかな？変に制限されるんじゃないかと思ったので

525 = :

ありがとうございます。
あるとわかってよかったです。

528 = :

http://blog.majide.com/2009/03/usage-of-gprof/
http://d.hatena.ne.jp/ousttrue/20091017/1255754733

529 = :

tdm64-gcc-4.6.1をインストールして
gcc -o a.exe a.cpp
ってやると
undefined reference to 'operator new(unsigned long long)'
みたいなエラーがでるので解決策教えてください。
ソースは
int main(){
new int *a=new a;
}
です。

531 = :

g++

532 = :

gccをg++に変えればできるんですか？

533 = :

すみません、よろしくお願がいします。
これはみんながなる症状なんでしょうか？
本当に困ってます。お願いします。

534 = :

>>532
何故それを試さん

535 = :

すみません、インストールしたパソコンではないので
今すぐ出来ません。
許してください。

536 = :

じゃあ、試してから結果を報告してください
それまでお待ちしています

537 = :

はい、また何日か後くらいにきます。
そのときはよろしくお願いします。

538 = :

いま別のパソコンで試したけど同じ症状でした。
しかしg++にしたらちゃんとコンパイルとリンクできました。
有難うございます。
これは何が原因なんですか？
とても気になるのでおしえてください。

539 = :

え、今時の学生は基本的なことも知らないでやるの？

540 = :

もしかしてgccはgnu c コンパイラーの略ってことですか？
gnuコンパイラーコレクションの略で好きな言語をコンパイル出来る
フロントエンドだと勝手に勘違いしてました。
大事なことをおしえてくれて有難うございます。

541 = :

>>540
コンパイルは出来るよ。
言語ごとのライブラリを勝手にリンクしないだけ

543 = :

なんでもはコンパイルできないわよ。知ってる言語だけ。

544 = :

じゃあ539の勘違いということでFAですね。

547 = :

つかえないです

548 = :

ありがとうございます。
msysを手動でインストールする方法とか知ってますか？
知らないなら自分で考えます。

549 = :

インストール出来る環境でインストールしたら、それを全部アーカイブしてよそへ持ってく。
例えばC:\MinGWにインストールしたらそのディレクトリごと。
コンソールへのショートカットはC:\MinGW\msys\1.0\msys.batを自前で作ればオッケー
だと思う。
時分の使い方の場合は問題でなかった。

あ、双方の環境でログイン名が違う場合は、ホームディレクトリをリネームするか
必要な設定ファイル群をコピーしてね。

550 = :

ありがとうございます。
参考にします。

前へ 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 5 (981) - [97%] - 2011/4/6 2:32
• Cygwin + MinGW + GCC 相談室 Part 4 (1001) - [97%] - 2010/3/23 18:31 ☆
• Cygwin + MinGW + GCC 相談室 Part 3 (1001) - [97%] - 2008/9/12 0:04 ★
• 【激遅】AppleGCC【絶望】 (111) - [1%] - 2010/1/15 10:31