Cygwin + MinGW + GCC 相談室 Part 8
リーナス君もタネンバウム先生も
作ったのは完全オリジナルOSだろ MSYS2 のスレって無いみたいだけど、
このスレで話題にしてもいいかな？ >>439
デスクトップ2台使っている。
旧機はUbuntu。新機はWindows 10 Pro。
Windows上でUNIXライクなコマンドを使いたいことが多々ある。 みなWSL(Windows Subsystem for Linux)に行ってしまったのさ・・・ >>448
Git BashかWSLかあきらめてPowerShellを極める minttyのためだけにcygwin入れてた時期があったけど
それもももうcygwin気にせず使えるようになったし
cygwinはお役御免 cygwin + msys -> msys2だと思ってた pcre2のpcre2_match_*() がクラッシュするんだけど、cygwinでしか起きないので調査する意欲がわいてこない。 >>449
win7 な私に wsl の恩恵はないのでしょうか？ Git for Windows v2.21.0 Release Notes
Latest update: February 26th 2019
https://gitforwindows.org/ random_deviceがクソすぎ
D:\learn\random>type test1.cpp
#include <random>
#include <iostream>
using namespace std;
int main()
{
random_device d;
cout << d() << endl;
cout << d() << endl;
cout << d() << endl;
}
D:\learn\random>g++ test1.cpp
D:\learn\random>a
3499211612
581869302
3890346734
D:\learn\random>a
3499211612
581869302
3890346734 >>457
MinGWはmt19937を使うと書いてあるぞ。 それじゃ意味ねえだろって話
mt19937のseedを作るのにmt19937を使ったらアホだろうが >>461
でも規格上実装依存ってことになっていて、実装が疑似乱数だと明示しているのだから、避けるのは利用者側の義務になるのでは。 seedはプロセスid と スレッドid の組み合わせのほうがよくない？ どうせmt使うんだからseedさえ適当に変更掛かるものなら何でもいいっしょ >>457
std::random_device::entropy()を表示させてみ
これで 0.0 が帰る場合は毎回同じ値が帰るから
VCはプロセスIDをうまく使ってrandom_deviceを実現してるようだな
MinGWは駄目だよ え、VCってCryptGenRandomを使ってないの？ rand_s()、rtl_gen_random() とかいうAPIでしょ。 Cでgets_sコンパイルするとエラーになるんだけど
通す方法ってないすか >>472
gets_s は C11 から導入されたので C11 を有効にするオプション (-std=c11) を付ければいいんじゃね？ >>473
わたしはぜひそれをしたいと思っていますがBasic Setupのツリーからその項目を見つけることができません
どこにあるのでしょう＞＜ >>473
あ、もしかしてそれってターミナルでコンパイルするときに
gcc -std=11 hoge.cとやれということでしょか？だとしたら死にたい… MSYS2 環境 (32bit) で Guile を実行するとライブラリのプリコンパイルが
始まってなかなか終わらないし、終わってから再度実行するとまた最初
から始まってしまう。
パス変換の考慮ミスで既にあるプリコンパイル済みライブラリを見つけらない (?) っぽい
報告もあるんだけど、これってどうにもならない？ ダミーで ./c/hoge -> /c/hoge みたいなリンク作って path に追加したら？ Windows 8.1 64bit 上で
>set | findstr PATH > c:\tmp\PATH.txt
>set | findstr Path > c:\tmp\Path.txt
したらファイル１つしか残らなかっただ…。
LFN でも大文字小文字区別せんのか…
Windows10 だと違うのか chcp 65001 はバグだらけだから今はしないのが常識 >>479
grep -ir "abc" ./*
grep でも使えば？
i は、大文字小文字を区別しない。
r は、ディレクトリを再帰的にたどる cp932でgcc-8.2.0がコンソールを深紅に染めない環境はありますか findstr /I
で case insensitive 処理が出来るようですね いずれも環境はWindows8.1 64bitです mingw-w64-x86_64- が頭についてるGUIソフトってXなしで動くのですか？
また、これが頭についていないパッケージってなんのために存在するのですか？ 名前はなんでもいいが、mingwをつかって直接windows api呼んでりゃXなしでうごく。あとQtとか使ってるのもあるじゃろう。
公式のパッケージは全部同じ命名なんじゃないか？なんか管理用のファイルとか？ qt-5.12.2ならMinGWのgcc-7.3.0を入れられる
g++ & qtで書ける ＜私見＞
qt charts ブチ込んでも、qt-5.12.2なら問題はリバースエンジニアリング関連にとどまる
なぜなら、qt chartsをインストール対象としてチェックしたうえでインストーラを進めても、
ライセンスとしてLGPLが選択可能で、GPLv3が要求する "displays an appropriate copyright notice" を満たさずGPLv3の適用を主張できないから
＜／私見＞
正確なところは弁理士または弁護士に確認されたし
IPAの逐条訳が参考になるかも >>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つあるような感じで実装されてたりするって感じかな emacsはX Window System必須ではなかったような気もするし今は違うのかも知れないし何とも windowsではcygwinのやつ使っとるよ。
msys2/mingwはいまいち信用できん。
なんにせよXは不要だよ emacs-X11とemacs-w32があるから嘘でもない valgrind みたいにアクセス違反検出する仕組で msys2 上で使えるものってあります？ Windows 上で g++ & qt ってどのくらいメジャーなのかな
とりあえず「オレオレコード」書くなら C++11 とかかいな
GCの仕組みとか全く知らんけど
「適切なC++11の教科書などない！」という話もあるけど
Python 使え？ 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 から実行しても遅いか？ 
