Cygwin + MinGW + GCC 相談室 Part 8
cygwin に apt-cyg find R したら Rがあった(長らくこれはなかった)
感動的だ
ようやくWindowsの上でもスタート地点に立った いまから C++ (and qt) をゼロから習得するなら
基本的には C++17 レベル？？？
https://cpprefjp.github.io/implementation-status.html みたかんじ
殆ど実装されてるっぽい？？？ ものすごい今さらな質問なんだが・・・
Cygwin て何て発音するんだ？サイウイン？
まわりに使ってるやつ1人もいないから実際に発音することがなくて困る >>510
ttps://ja.wikipedia.org/wiki/Cygwin cygnusはキグナスだった？
mingwがむしろ困るよな cygnusは英語では、「シグナス」です。
むかし、Cygnusと云う商標で、「キグナス石油」という会社が
あったので、Cygnusを英語読みで[シグナス」ということを
知らないで、、「キグナス」と読んだりするみたいです。
ちょっと、きになったら、『英和辞典」を引いてみるとよいでしょう。 ジョアンとフアンとジョンとジャンと…
カルロスとチャールズとシャルルと…
ジョージとホルヘとゲオルクと… ペーターピーターピョートル
シーメンスジーメンス
ジャーマンゲルマンドイツドイチュ 英語読みにこだわるなら
Linux は「らいなくす」か フランス語は
cygne
で、cygnusとは違います。
ラテン語は、英語と同じ
cygnus
です。 Cognac
Tough
Lamborghini
を思い出す >>526
MinGW-W64 project のやつは滞ってるけど、
MSYS2 project のやつ(pacmanで入れるやつ)は滞ってないよ(9.1.0)。 clang で良いんじゃないの？ Google もGCC からclang に切り替えたし。 > warning: hoge.hpp.gch/fuga.gch: had text segment at different address
9.2でこんなエラーが出るようになってPCHが効かない。ビルド時間が３倍に。
> cc1plus.exe: warning: '-Werror=' argument '-Werror=hoge-fuga' is not valid for C++
あとこんな警告が大量に出るようになって邪魔。 MinGWで作ったバイナリ、コマンドプロンプトで実行するとすごい遅い
一回実行するとキャッシュでもされるのかそれ以降の実行はわりと速い
ひどいときはプロセス間通信を使ってるバイナリで実行から終了まで7秒とかかかったりする
Gitとかはコマンドプロンプトで実行してもすぐに実行されるんだけど、何が違うんだろう
ウィルスソフトのリアルタイムスキャンに時間がかかってるのかと思って、問題のバイナリの除外設定とかしてみたけど、効果なかった
問題のバイナリはプロセス間通信を使ってるから、このプロセス間通信がボトルネックになってるのかなぁ
WindowsのCreateProcessはLinuxのforkに比べるとめちゃくちゃ遅いらしいし cmd からじゃなくて mintty から実行しても遅いか？ mkpasswdとかmkgroupとかやっとかないとあかんのじゃなかったっけ >>539
mintty, MSYSでは動作が速かったです
cmd特有の「初回起動だけ遅い」というのはありませんでした
powershellでも試してみます
>>541
cmdでも実行は出来てるんですが、なんか初回実行だけ遅いんです
初回以降は速くて、しばらく放置してまた実行すると遅くなってます キャッシュしてるとしたら socks の dll かな 雑な事いえばminttyやMSYSを起動すると、起動した時点でMinGWのdllが
読み込まれるのでコマンド起動遅くならないのでは dllの読み込みに時間かかってるってことですか
なるほど
ということはMinGWでコンパイルしたバイナリ全般に現れる問題っぽいですね コマンドプロンプトで実行するようなプログラムは
Windowsネイティブアプリにしろよw MinGWで作ったら余程変態技を使わない限りWindowsネイティブアプリ >>548
最初はLinuxで開発してて、それからWindows用に移植したんですよ
で、MinGWが手軽だったからMinGW使ってたんだけど >>553
おお、ありがとう
ダウンロードしてみる TDM-GCCでビルドしたら遅いの無くなったかもしれない(*´Д｀)！！！
>>551
>>553
もう少し様子見るけど、まじでありがとう
>>555
これはMinGWとは違うの？ staticになってるだけというオチだったらわろす ただ単に -static -O3 -mtune=skylake を指定していないだけ
じゃねえだろうな？ staticオプションは特に指定しませんが……
dllの読み込みが原因だとしたらstaticにすれば解決という話ですか
そういう発想はなかった
>>558
--mtune=skylakeってなんですか？ >>559
-O3はコードの最適化を3レベル(あるいはタイプ3)で行う
実際に何を行っているかはコンパイランの説明を読まないと分からない
-mtune=skylakeはコードをIntel CPUのSkyLakeアーキテクチャで最適な形にする
どちらも記述したコードを実行形式にするときに最適化を行うオプションなので、
非常に大きなコードを書いた際や似たような処理を繰り返すコードを書いている際に
指定すると早くなる事もある(ライブラリに含まれるコードは最適化されない)
>>560
都市伝説ってこともない
関数A、B、C、Dが含まれるライブラリlibhogeが存在する場合、自分のプログラムで
関数BとDだけを使っていると、ダイナミックリンクの場合自分のプログラムの実行
コードに加えてすべての関数が含まれるlibhoge.dll全体を読み込む必要がある
スタックリンクの場合には自分のプログラムの実行コードに加えてlibhoge.aから抽出した
関数BとDのコードを読み込むだけなので関数AとCのコードを読み込まない分ロードが
早くなる可能性は高くなる
ただし、実際問題としてはdllを一回読み込めばキャッシュからなくならない限り読み込む
必要がない+Windowsのプログラミングで使用するライブラリで基本的なものは通常
システムを起動した時点でキャッシュされていることに加えて、Windowsでプログラムを
動かすために必要な関数郡はかなりの量になる事が多いのでスタティックにリンクすると
すでにキャッシュされている関数郡を使わずに、必要な関数郡を含んだ大きなコードを
読み込む必要があるのでスタティックリンクの方が起動が遅くなるって本末転倒な事態が
発生することもある
MinGWの場合にはWindows一般では使わないライブラリを使用するので1回目の
起動時には必要なdllを読み込むよりは、必要な関数のみをリンクしたスタティックな
状態の方が早い場合があるかもってこと >>561
ということは--static -O3 -mtune=skylakeでビルドすれば起動が早くなるかもということですか
時間があるときに試したいと思いますm(_ _)m やっぱり名前解決の問題が大きいんすよ
ライブラリの読み込みだけでは説明できない >スタックリンクの場合には自分のプログラムの実行コードに加えてlibhoge.aから抽出した
>関数BとDのコードを読み込むだけなので関数AとCのコードを読み込まない分ロードが
これ関数単位でソース分けてあって
一関数が一objになってる場合だけだよな >スタックリンクの場合には自分のプログラムの実行コードに加えてlibhoge.aから抽出した
>関数BとDのコードを読み込むだけなので関数AとCのコードを読み込まない分ロードが
これ関数単位でソース分けてあって
一関数が一objになってる場合だけだよな dll読み込みってそんなに重いかな？
なんか別のところで時間がかかっていそうな感じ。 >>565-566
MinGWの場合はそうかな。確かMinGWでは--gc-sectionsが効かなかったかと。
LTOで未使用関数が除去されるかもしれないけどバグが多いので試してない。 >>563
でビルドしてみました
様子見します
-O3は、前にビルドしたときにプログラムがうまく動作しないことがあったんですよね
-O0にすると正常に動作したんですけど -O3と-O0で挙動が違うのは、不定の値を使っているとか、
未規定の動作に依存しているとか、そういう系だぞ
まれにコンパイラのバグということもあるが大抵てめーが悪い VCで造られたdllをmingwのgccで使いたいです
hoge.dll と hoge.lib は有るのですが
libhoge.a がありません
あと hoge.c とかのソースファイルもありません
hoge.def は hoge.dll から作れるのですが
hoge.lib から libhoge.a を作るのはどうすればよかったか思い出せません https://stackoverflow.com/questions/8683046/compatibility-of-dll-a-lib-def-between-visualstudio-and-gcc
dlltool.exe -m i386:x86-64 -d libhoge.def -D hoge.dll -l libhoge.a
dlltool.exe -m i386 -d libhoge.def -D hoge.dll -l libhoge.a
しらんけど 実際parallelstlをコンパイルするのはVCの方が楽だしな
これを.aに変換したいと思っていたのでありがたいです 9.2.0 Rev2 でPCHのエラーが出なくなった。 本物のWInネイティブアプリの起動はもっと速いのかもしれません。
MinGW+MSYS2がCygwinより速い理由が釈然としませんが、
forkがCygwinのものまんまよりは多少軽量だったりするんだろうか
https://twitter.com/nullpo_head/status/905032098506915840
https://twitter.com/5chan_nel (5ch newer account) cygwin の fork = native じゃなくて emu
mingw の fork = あるんか？ MinGW+MSYS2がCygwinより速い理由は
Cygwinはたとえ遅くなろうとも完璧なエミュレートを目指してるのに対して
MinGW+MSYS2は目指してないから MSYS2は、Windowsネイティブアプリを作るための環境です。
Windowsネイティブアプリを作りましょう。 GMPって真面目にソースtarからビルドするしかないの？ ビルド済みのバイナリですぐ使えるのがあれば欲しいんだけどcygwinのインストーラでチェック入れてもダメで、なんじゃこりゃってなってるんだけど。 >>589
どうでもいいことだが Stack Overflow のURLは削れる。
build - Are there any recent GMP Windows binary distributions? - Stack Overflow
https://stackoverflow.com/questions/19192963 msys2のpacmanでfdupesがないんですけど、どっからか手に入りますか？ 長期間更新がありませんが何か支障があるのでしょうか・・ Cygwin って /cygdrive上ではディレクトリまたげないんだけど、これってそんなもんだったっけ？
かなり久しぶりにCygwinを使おうとしているのだが困っている。
ディレクトリ構成 D:\DEV\debug で
下のディレクトリから上のディレクトリのファイルをコピーする、以下のコマンドが通らない。
MyMachine@MyName /cygdrive/d/dev/debug
$ cp ../some_file .
ディレクトリまたげないんだけど、こんなんだったっけ？
なお / をバックスラッシュにしても駄目。
なお/home以下のディレクトリならこれらのコマンドは通る。あまり試していないが、おそらく、/cygdrive以下だけ駄目。
何か設定がおかしい？それともこんなものだったっけ？
なお今のところディレクトリをまたげないだけでカレントについてはコマンドは通る。 >>600
すまぬ自己解決した。
debugがシンボリックリンクだったorz >>602
それはそうだが普段シンボリックリンクである事なんて意識しないからな。
いまだにcygwinではNTFSのシンボリックリンクを辿れないのはしょぼいと思うが。
なお32bit版。bashはversion4.4.12(3)、cygwin1.dll はversion 3001.2.0.0
（昨日の時点でsetup.exeを使いBestに更新）
64bit版なら行けるのかも？誰か動作報告よろしく。 
