Cygwin + MinGW + GCC 相談室 Part 8

**デフォルトの名無しさん** · 2014/09/23(火) 00:20:11.40

Windows上で動作するフリーの開発環境 CygwinとMinGWに関する相談スレッドです。

過去スレ:
Cygwin + MinGW + GCC 相談室 Part 7
http://peace.2ch.net/test/read.cgi/tech/1357019230/
Cygwin + MinGW + GCC 相談室 Part 6
http://toro.2ch.net/test/read.cgi/tech/1304609116/
Cygwin + MinGW + GCC 相談室 Part 5
http://hibari.2ch.net/test/read.cgi/tech/1269400706/
Cygwin + MinGW + GCC 相談室 Part 4
http://pc12.2ch.net/test/read.cgi/tech/1221233882/
cygwin + mingwn + gcc 相談室 Part3
http://pc11.2ch.net/test/read.cgi/tech/1177944767/
cygwin + mingwn + gcc 相談室 Part2
http://pc11.2ch.net/test/read.cgi/tech/1126103347/
cygwin + mingwn + gcc 相談室
http://pc8.2ch.net/test/read.cgi/tech/1058134693/

関連サイト:
Cygwin http://www.cygwin.com/
MinGW http://www.mingw.org/

関連スレッド:
GCCについて part10
http://toro.2ch.net/test/read.cgi/tech/1315026784/

**デフォルトの名無しさん** · 2019/03/23(土) 18:17:20.21

ダミーで ./c/hoge -> /c/hoge みたいなリンク作って path に追加したら？

**デフォルトの名無しさん** · 2019/04/10(水) 07:27:34.52

Windows 8.1 64bit 上で

>set | findstr PATH > c:\tmp\PATH.txt
>set | findstr Path > c:\tmp\Path.txt

したらファイル１つしか残らなかっただ…。
LFN でも大文字小文字区別せんのか…
Windows10 だと違うのか

**デフォルトの名無しさん** · 2019/04/10(水) 07:35:50.12

chcp 65001

するのって常識？？？

**デフォルトの名無しさん** · 2019/04/10(水) 10:38:27.98

chcp 65001 はバグだらけだから今はしないのが常識

**デフォルトの名無しさん** · 2019/04/10(水) 11:57:36.05

>>479
grep -ir "abc" ./*

grep でも使えば？

i は、大文字小文字を区別しない。
r は、ディレクトリを再帰的にたどる

**デフォルトの名無しさん** · 2019/04/12(金) 02:01:09.38

test

**デフォルトの名無しさん** · 2019/04/12(金) 02:02:22.10

cp932でgcc-8.2.0がコンソールを深紅に染めない環境はありますか

**デフォルトの名無しさん** · 2019/04/12(金) 02:03:18.43

findstr /I
で case insensitive 処理が出来るようですね

**デフォルトの名無しさん** · 2019/04/12(金) 02:03:48.55

いずれも環境はWindows8.1 64bitです

**デフォルトの名無しさん** · 2019/04/17(水) 09:23:22.24

mingw-w64-x86_64- が頭についてるGUIソフトってXなしで動くのですか？

また、これが頭についていないパッケージってなんのために存在するのですか？

**デフォルトの名無しさん** · 2019/04/17(水) 09:52:22.56

名前はなんでもいいが、mingwをつかって直接windows api呼んでりゃXなしでうごく。あとQtとか使ってるのもあるじゃろう。
公式のパッケージは全部同じ命名なんじゃないか？なんか管理用のファイルとか？

**デフォルトの名無しさん** · 2019/04/17(水) 10:10:51.07

qt-5.12.2ならMinGWのgcc-7.3.0を入れられる
g++ & qtで書ける

**デフォルトの名無しさん** · 2019/04/17(水) 10:14:46.50

＜私見＞
qt charts ブチ込んでも、qt-5.12.2なら問題はリバースエンジニアリング関連にとどまる
なぜなら、qt chartsをインストール対象としてチェックしたうえでインストーラを進めても、
ライセンスとしてLGPLが選択可能で、GPLv3が要求する "displays an appropriate copyright notice" を満たさずGPLv3の適用を主張できないから
＜／私見＞

正確なところは弁理士または弁護士に確認されたし
IPAの逐条訳が参考になるかも

**デフォルトの名無しさん** · 2019/04/17(水) 10:35:09.65

>>488
例えばEmacsは両方あります

**デフォルトの名無しさん** · 2019/04/17(水) 21:22:11.34

msys用でしょ

**デフォルトの名無しさん** · 2019/04/18(木) 17:45:20.57

>>488
最初は意味が分からなかったんだけど、unix(っていうかLinux系かな)と同じGUIツールは
X11なしでも動くのなんでかなって話かな
これは>>488が書いているようにGUIの表示にX11を使っていなくてWindowsで表示可能な
GUIシステム(例えばmingw用のQｔとか)で組まれているならば当然X11は必要ない
逆にX11ベースのxtermコマンド(あるならば)はX11サーバがないと表示できない

「mingw-w64-x86_64-」っていうのはマルチプラットフォーム/マルチアーキテクチャに
対応しているアプリケーションでプラットフォームやアーキテクチャをを表している
例えば「gcc」は「mingw」や「linux」といった複数のプラットフォームで「x86」や「arm」など
複数のアーキテクチャに対応している
なのでこの「gcc」は「64bit Windows」の「mingw」で「x86」系のCPUで動く「64bit」CPUで
動くよって意味で「mingw-w64-x86_64-」という接頭語みたいなのが付けられている

ただし接頭語が付いたままだと使うときにユーザーが一々プラットフォームとアーキ
テクチャを意識しなければならないし、configureみたいにその辺を自分で解決できる
スクリプトとかアプリケーションでないと一般的なコマンドとして使用出来ないので接頭語
なしのコマンドが用意されている

Linuxの場合には複数バイナリを用意するのは無駄なので接頭語つきのコマンドに
シンボリックリンクされた接頭語なしコマンド名が作られているけど「MSYS」みたいな
Windows上で動作する環境の場合シンボリックリンクに対応していないので同じバイナリが
2つあるような感じで実装されてたりするって感じかな

**デフォルトの名無しさん** · 2019/04/19(金) 16:30:35.71

>>493
違います

**デフォルトの名無しさん** · 2019/04/19(金) 17:02:11.09

emacsはX Window System必須ではなかったような気もするし今は違うのかも知れないし何とも

**デフォルトの名無しさん** · 2019/04/19(金) 17:21:27.71

windowsではcygwinのやつ使っとるよ。
msys2/mingwはいまいち信用できん。
なんにせよXは不要だよ

**デフォルトの名無しさん** · 2019/04/19(金) 20:44:01.33

cygwinのはXlibリンクしてるんじゃない？

**デフォルトの名無しさん** · 2019/04/22(月) 22:01:05.02

>>497
嘘はよくない

**デフォルトの名無しさん** · 2019/04/23(火) 00:42:18.05

emacs-X11とemacs-w32があるから嘘でもない

**デフォルトの名無しさん** · 2019/04/23(火) 01:02:36.94

まだastec-xとか売ってるんですね

**デフォルトの名無しさん** · 2019/05/02(木) 21:24:20.65

valgrind みたいにアクセス違反検出する仕組で msys2 上で使えるものってあります？

**デフォルトの名無しさん** · 2019/05/08(水) 17:58:41.57

>>501
ないですね

**デフォルトの名無しさん** · 2019/05/21(火) 22:53:35.55

>>501
ありますよ

**デフォルトの名無しさん** · 2019/05/22(水) 01:15:47.82

Windows 上で g++ & qt ってどのくらいメジャーなのかな

とりあえず「オレオレコード」書くなら C++11 とかかいな
GCの仕組みとか全く知らんけど
「適切なC++11の教科書などない！」という話もあるけど

Python 使え？

**デフォルトの名無しさん** · 2019/05/22(水) 11:00:03.94

C++11 なんてオワコンだからやめとけ

**デフォルトの名無しさん** · 2019/05/22(水) 17:17:32.49

>>504
話もあるけどね

**デフォルトの名無しさん** · 2019/06/03(月) 06:28:27.40

ふう😎

**デフォルトの名無しさん** · 2019/06/13(木) 16:59:54.42

cygwin に apt-cyg find R したら Rがあった(長らくこれはなかった)
感動的だ

ようやくWindowsの上でもスタート地点に立った

**デフォルトの名無しさん** · 2019/06/13(木) 19:08:21.05

いまから C++ (and qt) をゼロから習得するなら
基本的には C++17 レベル？？？

https://cpprefjp.github.io/implementation-status.html みたかんじ
殆ど実装されてるっぽい？？？

**デフォルトの名無しさん** · 2019/06/13(木) 22:37:36.09

ものすごい今さらな質問なんだが・・・
Cygwin て何て発音するんだ？サイウイン？
まわりに使ってるやつ1人もいないから実際に発音することがなくて困る

**デフォルトの名無しさん** · 2019/06/13(木) 22:43:02.73

>>510
ttps://ja.wikipedia.org/wiki/Cygwin

**デフォルトの名無しさん** · 2019/06/13(木) 23:07:55.81

まじかよ・・人前で発音してなくてよかった

**デフォルトの名無しさん** · 2019/06/14(金) 00:04:54.99

cygnusはキグナスだった？
mingwがむしろ困るよな

**デフォルトの名無しさん** · 2019/06/14(金) 11:01:55.94

みんじーだぶる

**デフォルトの名無しさん** · 2019/06/14(金) 11:06:24.98

みんぐうじゃないのか

**デフォルトの名無しさん** · 2019/06/14(金) 12:20:34.75

cygnusは英語では、「シグナス」です。

むかし、Cygnusと云う商標で、「キグナス石油」という会社が
あったので、Cygnusを英語読みで[シグナス」ということを
知らないで、、「キグナス」と読んだりするみたいです。

ちょっと、きになったら、『英和辞典」を引いてみるとよいでしょう。

**デフォルトの名無しさん** · 2019/06/14(金) 12:26:57.67

ジョアンとフアンとジョンとジャンと…

カルロスとチャールズとシャルルと…

ジョージとホルヘとゲオルクと…

**デフォルトの名無しさん** · 2019/06/14(金) 12:28:33.37

>>516
英語しかできないってこと？

**デフォルトの名無しさん** · 2019/06/14(金) 12:47:10.03

ペーターピーターピョートル
シーメンスジーメンス
ジャーマンゲルマンドイツドイチュ

**デフォルトの名無しさん** · 2019/06/14(金) 19:09:25.40

英語読みにこだわるなら
Linux は「らいなくす」か

**デフォルトの名無しさん** · 2019/06/14(金) 23:28:44.92

フランス語は
cygne
で、cygnusとは違います。
ラテン語は、英語と同じ
cygnus
です。

**デフォルトの名無しさん** · 2019/06/15(土) 00:44:39.57

>>516
https://ja.forvo.com/word/cygnus/#la

こうか

**デフォルトの名無しさん** · 2019/06/15(土) 11:12:22.87

Cognac
Tough
Lamborghini
を思い出す

**デフォルトの名無しさん** · 2019/06/20(木) 22:49:09.67

クンタッシ

**デフォルトの名無しさん** · 2019/06/22(土) 19:12:03.45

>>523
ぶぁーか

**デフォルトの名無しさん** · 2019/06/23(日) 05:49:44.99

MinGW更新が滞っています

**デフォルトの名無しさん** · 2019/06/24(月) 05:27:39.62

>>526
MinGW-W64 project のやつは滞ってるけど、
MSYS2 project のやつ(pacmanで入れるやつ)は滞ってないよ(9.1.0)。

**デフォルトの名無しさん** · 2019/06/24(月) 12:32:30.26

msys2もWSL2で役目終了かな

**デフォルトの名無しさん** · 2019/06/24(月) 16:47:30.43

そして焼け野原

**デフォルトの名無しさん** · 2019/06/25(火) 20:17:15.80

>>529
一言余計なんだよカス

**デフォルトの名無しさん** · 2019/06/25(火) 20:43:23.33

効いてるw

**デフォルトの名無しさん** · 2019/06/25(火) 21:35:27.64

https://gcc-mcf.lhmouse.com/?C=M&;O=D

ここちゃんとチェックしてるか？9.1.1まで出てるぞ

**デフォルトの名無しさん** · 2019/06/26(水) 01:21:30.62

>>532
普通チェックしないし使わない

**デフォルトの名無しさん** · 2019/07/02(火) 16:03:24.73

>>533
効いてるw

**デフォルトの名無しさん** · 2019/08/05(月) 11:53:08.29

clang で良いんじゃないの？ Google もGCC からclang に切り替えたし。

**デフォルトの名無しさん** · 2019/08/13(火) 11:23:23.39

gcc-9.2

**デフォルトの名無しさん** · 2019/08/14(水) 15:59:31.43

> 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++
あとこんな警告が大量に出るようになって邪魔。

**デフォルトの名無しさん** · 2019/08/20(火) 15:18:40.97

MinGWで作ったバイナリ、コマンドプロンプトで実行するとすごい遅い
一回実行するとキャッシュでもされるのかそれ以降の実行はわりと速い
ひどいときはプロセス間通信を使ってるバイナリで実行から終了まで7秒とかかかったりする

Gitとかはコマンドプロンプトで実行してもすぐに実行されるんだけど、何が違うんだろう
ウィルスソフトのリアルタイムスキャンに時間がかかってるのかと思って、問題のバイナリの除外設定とかしてみたけど、効果なかった

問題のバイナリはプロセス間通信を使ってるから、このプロセス間通信がボトルネックになってるのかなぁ
WindowsのCreateProcessはLinuxのforkに比べるとめちゃくちゃ遅いらしいし

**デフォルトの名無しさん** · 2019/08/20(火) 15:20:15.93

cmd からじゃなくて mintty から実行しても遅いか？

**デフォルトの名無しさん** · 2019/08/20(火) 15:35:04.29

>>539
試してないけど試してみます

**デフォルトの名無しさん** · 2019/08/20(火) 15:50:21.30

mkpasswdとかmkgroupとかやっとかないとあかんのじゃなかったっけ

**デフォルトの名無しさん** · 2019/08/20(火) 17:27:25.95

>>539
mintty, MSYSでは動作が速かったです
cmd特有の「初回起動だけ遅い」というのはありませんでした
powershellでも試してみます

>>541
cmdでも実行は出来てるんですが、なんか初回実行だけ遅いんです
初回以降は速くて、しばらく放置してまた実行すると遅くなってます

**デフォルトの名無しさん** · 2019/08/20(火) 17:37:17.04

キャッシュしてるとしたら socks の dll かな

**デフォルトの名無しさん** · 2019/08/20(火) 17:51:30.05

ログ吐かせてどこにネックがあるのかみてみないと

**デフォルトの名無しさん** · 2019/08/21(水) 17:19:04.83

雑な事いえばminttyやMSYSを起動すると、起動した時点でMinGWのdllが
読み込まれるのでコマンド起動遅くならないのでは

**デフォルトの名無しさん** · 2019/08/21(水) 17:33:03.25

それならそれで解決とするか

**デフォルトの名無しさん** · 2019/08/21(水) 23:34:12.77

dllの読み込みに時間かかってるってことですか
なるほど
ということはMinGWでコンパイルしたバイナリ全般に現れる問題っぽいですね

**デフォルトの名無しさん** · 2019/08/22(木) 04:38:34.97

コマンドプロンプトで実行するようなプログラムは
Windowsネイティブアプリにしろよw

**デフォルトの名無しさん** · 2019/08/22(木) 05:37:28.68

MinGWで作ったら余程変態技を使わない限りWindowsネイティブアプリ

**デフォルトの名無しさん** · 2019/08/22(木) 06:10:29.02

>>548
最初はLinuxで開発してて、それからWindows用に移植したんですよ
で、MinGWが手軽だったからMinGW使ってたんだけど

**デフォルトの名無しさん** · 2019/08/22(木) 10:15:45.06

そんな用途には tdmgcc64 おすすめ

**デフォルトの名無しさん** · 2019/08/23(金) 03:35:27.20

ググっても一件しか出なかった
gccなのはわかる

**デフォルトの名無しさん** · 2019/08/23(金) 15:09:01.75

これやろ
https://ja.wikipedia.org/wiki/TDM-GCC
http://tdm-gcc.tdragon.net/download

**デフォルトの名無しさん** · 2019/08/23(金) 18:17:23.56

>>553
おお、ありがとう
ダウンロードしてみる

**デフォルトの名無しさん** · 2019/08/23(金) 18:24:15.33

今はこっちが良くね
https://text.baldanders.info/remark/2018/03/mingw-w64/

**デフォルトの名無しさん** · 2019/08/24(土) 06:55:34.51

TDM-GCCでビルドしたら遅いの無くなったかもしれない(*´Д｀)！！！
>>551
>>553
もう少し様子見るけど、まじでありがとう

>>555
これはMinGWとは違うの？

**デフォルトの名無しさん** · 2019/08/24(土) 09:36:31.35

staticになってるだけというオチだったらわろす

**デフォルトの名無しさん** · 2019/08/24(土) 14:59:08.43

ただ単に -static -O3 -mtune=skylake を指定していないだけ
じゃねえだろうな？

**デフォルトの名無しさん** · 2019/08/24(土) 17:29:38.98

staticオプションは特に指定しませんが……
dllの読み込みが原因だとしたらstaticにすれば解決という話ですか
そういう発想はなかった

>>558
--mtune=skylakeってなんですか？

**デフォルトの名無しさん** · 2019/08/24(土) 17:48:35.57

DLLよりstaticが速いとか都市伝説

**デフォルトの名無しさん** · 2019/08/25(日) 16:54:37.16

>>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を読み込むよりは、必要な関数のみをリンクしたスタティックな
状態の方が早い場合があるかもってこと

**デフォルトの名無しさん** · 2019/08/25(日) 19:02:38.36

もっと短く

**デフォルトの名無しさん** · 2019/08/25(日) 23:51:01.48

>>561
ということは--static -O3 -mtune=skylakeでビルドすれば起動が早くなるかもということですか
時間があるときに試したいと思いますm(_ _)m

**デフォルトの名無しさん** · 2019/08/26(月) 01:28:47.93

やっぱり名前解決の問題が大きいんすよ
ライブラリの読み込みだけでは説明できない

**デフォルトの名無しさん** · 2019/08/26(月) 14:11:24.03

>スタックリンクの場合には自分のプログラムの実行コードに加えてlibhoge.aから抽出した
>関数BとDのコードを読み込むだけなので関数AとCのコードを読み込まない分ロードが

これ関数単位でソース分けてあって
一関数が一objになってる場合だけだよな

**デフォルトの名無しさん** · 2019/08/26(月) 14:11:24.09

>スタックリンクの場合には自分のプログラムの実行コードに加えてlibhoge.aから抽出した
>関数BとDのコードを読み込むだけなので関数AとCのコードを読み込まない分ロードが

これ関数単位でソース分けてあって
一関数が一objになってる場合だけだよな

**デフォルトの名無しさん** · 2019/08/26(月) 17:43:39.53

dll読み込みってそんなに重いかな？
なんか別のところで時間がかかっていそうな感じ。

**デフォルトの名無しさん** · 2019/08/26(月) 21:44:29.54

>>565-566
MinGWの場合はそうかな。確かMinGWでは--gc-sectionsが効かなかったかと。
LTOで未使用関数が除去されるかもしれないけどバグが多いので試してない。

**デフォルトの名無しさん** · 2019/08/27(火) 05:30:30.81

>>563
でビルドしてみました
様子見します
-O3は、前にビルドしたときにプログラムがうまく動作しないことがあったんですよね
-O0にすると正常に動作したんですけど

**デフォルトの名無しさん** · 2019/08/27(火) 09:41:49.02

-O3に完璧を求める方が可笑しい

**デフォルトの名無しさん** · 2019/08/27(火) 11:08:45.95

そこで-Ofastですよ

**デフォルトの名無しさん** · 2019/08/27(火) 12:32:02.21

-O3と-O0で挙動が違うのは、不定の値を使っているとか、
未規定の動作に依存しているとか、そういう系だぞ

まれにコンパイラのバグということもあるが大抵てめーが悪い

**デフォルトの名無しさん** · 2019/08/28(水) 17:10:08.53

VCで造られたdllをmingwのgccで使いたいです
hoge.dll と hoge.lib は有るのですが
libhoge.a がありません
あと hoge.c とかのソースファイルもありません
hoge.def は hoge.dll から作れるのですが
hoge.lib から libhoge.a を作るのはどうすればよかったか思い出せません

**デフォルトの名無しさん** · 2019/08/28(水) 17:25:07.66

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

しらんけど

**デフォルトの名無しさん** · 2019/08/28(水) 17:45:16.06

実際parallelstlをコンパイルするのはVCの方が楽だしな
これを.aに変換したいと思っていたのでありがたいです

**デフォルトの名無しさん** · 2019/09/03(火) 16:24:26.27

9.2.0 Rev2 でPCHのエラーが出なくなった。

**デフォルトの名無しさん** · 2019/09/13(金) 12:46:20.65

本物のWInネイティブアプリの起動はもっと速いのかもしれません。
MinGW+MSYS2がCygwinより速い理由が釈然としませんが、
forkがCygwinのものまんまよりは多少軽量だったりするんだろうか
https://twitter.com/nullpo_head/status/905032098506915840
https://twitter.com/5chan_nel (5ch newer account)