Cygwin + MinGW + GCC 相談室 Part 8
レス数が900を超えています。1000を超えると表示できなくなるよ。
え!?WSLってそのままでは音流せないんですか!? gnupgってGPGだろ
GNU製のPGP暗号化と復号プログラム >>671
PulseAudio使えばいいだけじゃね? ではWSLは、デフォルトでは音すら流せない杜撰な造りをしていると認めるんですか? 単にサウンドデバイスを実装してないだけだよ
設計は良く出来てるので実装しようと思えば出来るだろうが
利用者が求めてない機能なので優先度が低い
WSLの利用者は開発者だからね。開発者が欲しい機能が最優先 あ、もしWSLが開発者向けの機能を優先してるのを知った上で
WSLは駄目だって印象を与えようとした書き込みだったらごめん、邪魔したね
そうでないなら音ならWindowsで鳴らせばいいと気づければOKだよ
音を鳴らす程度のためにWSLは不要だからね >>653
wslはwslのコマンドラインからlinuxバイナリもwindowsバイナリも動く優れものなんだよ >>677
そうそう。だからbashのシェルスクリプトで
Windowsのコマンドを実行してOSの設定を変更するとかできちゃう Windowsのコマンドプロンプト側からWSLのディレクトリに入っていけるの? >>679
それはコマンドプロンプト自体の問題で、こいつは古いアプリなのでUNCパスに対応していない
UNCパス(\\ではじまるネットワークフォルダのパス)を扱えるツールを使う必要がある
WSLのディレクトリに対応してるかというよりも
ネットワークフォルダに対応しているかという話に近い
PowerShellはUNCパスに対応しているからWSLのディレクトリにも入れる
コマンドプロンプトから実行するコマンドもUNCパスに対応していれば参照できる
またネットワークフォルダはドライブに割り当てることが出来るので
ドライブに割り当てればコマンドコマンドからWSLのディレクトリに入ることも出来る ちなみにcdの代わりにpushdを使えば
コマンドコマンドからUNCパスに移動できる
一時的にドライブを割り当てているだけだが 詳しい情報サンクス!
これなら皆がWSLへl移行するのもわかる気がする windowsのSSHサーバ立ち上げてwslをシェルにできるのは便利
PowerShell極めてるひとなら不要かもしれんけどね マジレスするとmsys使ってて問題無ければwsl要らない >>684
共存できる。msys2はただのアプリでしかないから
>>685
msysの問題はUbuntuと同じようなメンテナンス力を期待できないところかな
WSLは本物のUbuntuのディストリのパッケージが使われてるので
Ubuntuとほぼ同等にメンテナンスされてると思っていい
だけどmsysは(Ubuntuと比べたら小さな)開発者が対応してるパッケージしか使えない
しかもLinuxと完全互換じゃないからmsysでソースコードからコンパイルしようとしても
動くとは限らない。WSLを使えばそういった煩わしさから開放される。
msysはWSLを入れてない人のためのWindows用アプリを作るためのものだよ
開発者がLinuxの代わりとして使うものじゃない >>687
シンボリックリンクでホームディレクトリ以下から
アクセスしやすくするのがおすすめ
色々と混ざらないし複数のディストリでも共有できる 色々と混ぜたいからホームディレクトリを一緒にするんだろ
そうじゃなければ最初から分けとけばいいだけの話だ >>689
「色々」と混ぜたいならその「色々」だめを混ぜればいいじゃん
全部混ぜる必要はない 「色々」と混ぜたいならその「色々」だけを混ぜればいいじゃん Microsoft Store に WSL Ubuntu 20.04 LTS 出てるけど、まだ入れない方がいいんですか 早くても、8月以降に、20.04.1 とか修正版が出た後。
1年後でも良い
Ruby のirb では、MSYS2/MinGW で、日本語入力でバグるから、
WSL の方が、互換性が高い
日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv で、
色々なバージョンも入れられる
VSCode も、Remote WSL 拡張機能で、Linux 側へアクセスできる >>679
コマンドプロンプト・PowerShell で、wsl と入力すれば、WSLが起動する
最も良いのは、Linux 側のフォルダのショートカットをデスクトップにでも作って、
そのフォルダの右クリックメニューから、VSCode を起動する
これで、WSLを起動して、Linux側のプロジェクトを開ける wsl, opensuse leapにmingw64入れてクロスビルドしてる。
configure作って--hostでmingw指定すれば楽勝すぎて屁が出そう 自分が使っているWSLが1なのか2なのか知る方法は? openSUSE Leap 15.1用のmingw配布消えとるやん
くそがー そもそもWSL2はエンスー向けか
普通の人は1が入ってるのか MinGWっていうかGitBash環境なんだけど
WSL1より2倍ぐらいシェルスクリプトが遅いんだよね
どこが原因かわからんけどこんなもん?
なにか大きな差がでるポイントでもあるんかね? WSL1 (bash 4.4.20) だと
$ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done'
real 0m6.317s
user 0m6.313s
sys 0m0.000s
MinGW64 (bash 4.4.23) だと
$ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done'
real 0m15.053s
user 0m15.000s
sys 0m0.030s
Cygwin (bash 4.4.12) だと
$ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done'
real 0m13.897s
user 0m13.858s
sys 0m0.046s
うーん、こんな単純なコードで2倍の差がでてるから
もうこれはどうしようもないのか? 比較とか計算が遅いのかと思ってやってみたけど
この比率は変わらない
WSL1
$ time bash -c 'for i in $(seq 1000000); do :; done'
real 0m2.159s
user 0m1.828s
sys 0m0.359s
Cygwin
$ time bash -c 'for i in $(seq 1000000); do :; done'
real 0m4.222s
user 0m3.889s
sys 0m0.341s
MinGW64
$ time bash -c 'for i in $(seq 1000000); do :; done'
real 0m4.821s
user 0m4.342s
sys 0m0.436s
WSL1 → Cygwin(2倍ぐらい遅い)→MinGW(さらに10%遅い)
こんな傾向がある。ファイルシステムは関係ないはず
やってるのはCPUの処理だけなはずなんだけどなぁ 調べるとradeonのドライバを切れとか書いてあるけど… radeonの話は画面に出力が絡むなら
関係ありそうな気もするけど、それ以外でも発生するんだろうかね
あとHOMEは MinGWは /c/Users/myname
Cygwinは/home/mynameだ よく見ると大きな差があるのはuser空間だから
コンパイルオプションが違ってるとかなのかな? seq使うんじゃなくて{1..1000000}の方がいいかもね >>707
つってもわずか一回だからなぁ。やってみてもいいけど
WSL1
$ time bash -c 'for i in {1..1000000}; do :; done'
real 0m1.710s
user 0m1.547s
sys 0m0.156s
Cygwin
$ time bash -c 'for i in {1..1000000}; do :; done'
real 0m4.854s
user 0m4.811s
sys 0m0.108s
MinGW64
$ time bash -c 'for i in {1..1000000}; do :; done'
real 0m4.934s
user 0m4.843s
sys 0m0.109s
あとあれから少しわかったのはMinGWは何回か繰り返せば
Cygwinに迫るのでファイル読み込み?とかも少し関連してるんだと思う
が2倍以上かかることに変わりはない
cygwin.dll?とかが遅いのかもな。MinGWでも使ってるんじゃなかったっけ? >>708
を、WSL1, Ubuntu 18.04 で、3回やった。
8GB メモリ、CPU-i3・エコモード
real 0m4.680s
user 0m4.234s
sys 0m0.453s ちなみに俺のはCPUはi7な
Cygwin、MinGWを実行したら
それの2倍かかるはず cygwinはforkがヘボいから遅い
MinGWといいつつmsysのbashやろ
これもforkがcygwinゆずりだから遅い。
wslもfork遅いと思うけど。
virtual boxにwindowsファイルを共有させたものの方が実は速い。
純粋にwindowsとLinuxの環境を同居させたきゃ仮想PC
Linuxでwindows binaryをクロスビルド、テストまでしたけりゃwsl まあ名前解決のところと passwd/group の設定はしといた方がいいね >>712
forkが遅いのはわかってるけど、
このコードでforkなんて大量にはしないだろ?
time bash -c 'for i in {1..1000000}; do :; done' 元々、bash が、ループ向きではないから、dash などを使う
for は遅いから、while などを使う。
実行時間中のほとんどが、フォークの時間
ループは、awk, perl, ruby などでは、0.1 秒も掛からない。
単一プロセス中の処理だから あ、dashの結果書くの忘れてた。dashは速いから数を10倍にしてる
傾向は一緒。ただのループなのに2倍ぐらいの差が出てしまう
WSL1
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m4.480s
user 0m2.875s
sys 0m2.047s
Cygwin
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m7.598s
user 0m6.531s
sys 0m1.296s
MinGW64
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m7.905s
user 0m6.905s
sys 0m1.155s awkは更に速いから、更に10倍にしてる。これなら理解できるな。
CygwinとMinGW64がWSL1より少し遅いのは起動時のパフォーマンスの差だろう
ってことはシェルスクリプトだと、なにか遅くなる処理をやってるってことか
整数型じゃないとか?
WSL1
$ time awk 'BEGIN{i=0;for(i=0;i<100000000;i++);}'
real 0m4.121s
user 0m4.109s
sys 0m0.016s
Cygwin
time awk 'BEGIN{i=0;for(i=0;i<100000000;i++);}'
real 0m4.978s
user 0m4.875s
sys 0m0.031s
MinGW64
$ time awk 'BEGIN{i=0;for(i=0;i<100000000;i++);}'
real 0m4.586s
user 0m4.562s
sys 0m0.015s for がコマンドだから、フォークされるのだろ。
だから、シェルスクリプトでは、while を使えと言われる
bash よりも、dash を使う。
それ以上は、awk, perl, ruby whileを使うと遅いからforに変えたのですが?
forを使った>>716とループ回数は同じ
WSL1
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m4.480s
user 0m2.875s
sys 0m2.047s
$ time dash -c 'i=0; while [ $i -lt 10000000 ]; do i=$((i+1)); done'
real 0m15.811s
user 0m15.766s
sys 0m0.016s
Cygwin
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m7.598s
user 0m6.531s
sys 0m1.296s
$ time dash -c 'i=0; while [ $i -lt 10000000 ]; do i=$((i+1)); done'
real 0m26.173s
user 0m26.109s
sys 0m0.031s
MinGWはCygwinと大差ないので省略 8年前のシェルスクリプトの本には、
10万行の処理で、
for : 9分
while : 5秒
awk/perl : 0.1秒 $((i+1)) という部分が、コマンドだから遅いのだろう
ほとんどが、そのフォーク時間 せいぜいbashのサブコマンドで、forkしとらん気がする
ただマルチスレッドは使ってるかも知れんし、その際のメモリ操作はなんか性能の問題があった気はする $(())内でiを更新できることから分かるようにforkしていないし、少なくともbashとdashはシングルスレッド
linux上で
ltrace -f bash -c 'for i in {1..1000000}; do :; done'
したら、mallocを何度も呼んでいるようだから、ヒープ操作関係が遅い可能性はある
実際、linux上でもmallocの実装をglibcのからjemallocに切り替えたら上のループが2割近く速くなった wsl2は仮想マシンになるのか
windowsバイナリ実行できるのかな 以下のパッケージ、入れようとすると対象が見つからないと出るんだけど・・・
dlfcn
libpng
tools-git
jq
clang WSL, Ubuntu 18.04 には、jq もあるけど
apt-cache show jq
メンテナー : 陳昌倬 >>727
ないんだろ?Cygwinは独自のディストリ
Windowsに移植できたもの、自分が関心があるパッケージしか
登録されていない MSYS2でWin32アプリ作ってみようとチャレンジ中 msys2をサイレントインストールするにはどうしたら良いですか? WSL2で 9PFs 経由でWin32側のファイルを読み込むの、なんでこんな遅いの? 仮想マシン経由だからでは?
だからWSL1も引き続き開発してるわけで 同意。mingwは存在意義があるけど、cygwinは役割を終えた。 mingwは「Git For Windows」のバンドルモジュールとしてしぶとく生き残る。
cygwinはdll依存をなくしてmingwに統合されていくでしょ。 それを言ったらGit Bashはmsys2のbashだが、bashがmingwに移植されるとは思えんな gcc -staticがデフォじゃないのがよくわからん
じゃあMinGWの立ち位置って何よって bash使いたいならbusybox-w32を使えばいいじゃない MinGWの立ち位置?
Win32アプリをビルドできるGCC環境 ReactOS Build Environment (RosBE)という選択肢もアリます。 MSVC に依存したくないので、mingw をお手軽に維持できる cygwin 環境はありがたいですね… WineHQとかRosBEとかはLinuxでも使えるクロスコンパイラを用意している。まあ、やる人は少ないが。 別にlinuxからでもクロスコンパイルできるんやろ? XPでも動くプログラムが作れるってのが味噌。MSYS2はVista+に移行した。 移行したと言うか、互換性の点でbashの方が良かったが
bashのライセンスがGPL3に変わって受け入れられなかったから
仕方なくzshにしたってだけだろ
古いbash 3系よりは、zshの方がまだましという消極的な理由 >>752
>>754
tdmgcc で cygwin から解放されました
ほんとうにありがとうございました tdmgcc は wikipedia では開発が止まった事になってるな。 今時mingwはmsys2のを使っときゃいいんだよ SourceForgeのMinGWページを隅から隅まで探せば書いてあるじゃん 隅から隅まで探さないといけないやつを検索すらできないのかっていうのはなんか違わない?????
僕そもそもなぜかCygwinの話だと思ってたからそれ以前の問題なんですけど こまけーことは気にせずにmsys2使っときゃええんやで
cygwinはなあ…gccの更新いつも遅いから Git for Windows にバンドルされてるbash使えばいい。
ビルド環境はStrawberry Perlにバンドルされてるのを使えばいい。 ライブラリをストリップしたらあかんのではないかな
gccのオプションにexceptionのなんかがあった気がする Visual Studioに入ってるdumpbinに相当するコマンドある?
DLLのエクスポートテーブルを覗きたいんだけど digitalmars_com /ctg/implib.html
wiki_dlang_org /Win32_DLLs_in_D
www_kmonos_net /alang/d/dll.html fork: retry: resource temporarily unavailable とかでて直せない。
rebaseallとかやっても効果ないみたいだし
もうcygwin、msysのテストやめようかな MSYS2には、lscpuコマンドはないのかな?
CentOSなんかだとutil-linuxパッケージに入ってるけど、MSYS2のには入ってないもよう。。。 /proc/cpuinfo
/proc/meminfo
/usr/bin/free
はあるんだけど、lscpuはないんだよな。。。 Windows 10, WSL2, Ubuntu 18.04 には、
/usr/bin/lscpu
がある コロナもどんどん変異種がでてきとるしな
もう人類は無理だろ
さよなら人類 g++ (Rev6, Built by MSYS2 project) 10.2.0
Microsoft Windows [Version 10.0.18363.1316]
なんだけど、filesystem::hard_link_countが1しか返さないのはギャグ?
Microsoft(R) C/C++ Optimizing Compiler Version 19.28.29336 for x86
ちな、こいつはちゃんと2以上も返す MSYS2でアップデートしたらmintty周りの設定が飛んだみたい
もうWSL2にしろってことか int a [100];
for_each(par,a,a+100,[](auto){while(true);});
g++ a.cpp -std=c++17 -O3 -mavx512f -mtune=znver2
a.exe
resmonで見るとどうもシングルスレッド
のようなんだが、なんで?
ちな、vsだとちゃんとマルチで動く WSL2とどっちが強い?
まあうちは8.1なんだけど まあWSL2は本物だからなあ
WSL2よりもcygwinよりもWSLの方が好きだな WSL2は内弁慶。
Cygwinは厚化粧。
MSYS2は八方美人。 mingwとMSYSの使い分けがいまだによく分からん
MSYSのdllを使うコマンドか否か、みたいなのは分からなくはないが、
それはユーザが意識せにゃならんのかいなと
結局、エクスプローラのsendtoとかで別にあるLinuxサーバに送って、
TeraTermでそのディレクトリでシェルを起動して、grepとかawkとかってやっちゃうわ mingwはgccとその周辺では
結果的にいろいろついてくるけど >>823
MSYSはmingwを含む擬似Linux環境で、mingwはLinux(POSIXではないのかな)のAPI
ゲートウェイみたいな感じ?
Linux上と同じ結果になる補償は無いけどMSYSのバイナリは直接Windowsで動作する
ものなので、MSYSの「usr/bin」にパス通しておけば直接コマンドプロンプトで使えるけど
ダメかな? だからmingwは開発ツールで、gccとその仲間達
MSYSはPOSIX的なコンピュータ操作環境 Strawberry Perl と Git for Windowsで事足りる >>828
そういうものを使うのなら、いっそMSYS2にしたほうがええけどなあ。
とくにGitのほう。 MSYS2 はネイティブ実行ファイルを作る開発環境で、
POSIX 互換レイヤはあくまでも開発環境 (GNU ツールチェインなど) を動かすための最小限度というのがコンセプト。
POSIX 互換の実行環境として全体の面倒をみる Cygwin とはコンセプトが違う。
(Cygwin でも posix 互換レイヤを通さない実行ファイルを作れはするけど基礎理念の話ね。)
MSYS2 をインストールしたときに
・ MSYS2 MinGW 32-bit
・ MSYS2 MinGW 64-bit
・ MSYS2 MSYS
の三種類の環境が用意されるけど、
MSYS2 MSYS は開発環境の保守として使うだけに留めて
普段の開発には MSYS2 MinGW を使うのが標準的な運用形態。
そういう理念を実現するにあたって結果としては msys-2.0.dll に依存するかどうかの差
になって現れるのは確かだけど、そこだけで区別すると意味わからんよ。 argv[0] にフルパスが入るのは保証された動作なの? いやそんなことはない
プログラム名だけどそれがファイル名とは限らない execlp(ファイル名,arg0,arg1,...(char*)0); minttyでおすすめのフォント設定を教えてください
メニューで出て来る選択肢の中で一番マシなEPSON 太丸ゴシック体Bで、今は誤魔化してます
$ mintty.exe --version
mintty 3.4.4 (x86_64-pc-msys)
c 2013/2020 Andy Koppe / Thomas Wolff
License GPLv3+: GNU GPL version 3 or later
There is no warranty, to the extent permitted by law.
という環境で、git for windows同梱のものをWindows 8.1 64bit上で使っています Font=欧文フォント
FontChoice=CJK:1
Font1=日本語フォント
みたいにして欧文と日本語で別のフォントを指定してる 御教示ありがとうございました
.minttyrcでのFontChoiceの設定ふくめ、色々調整してみます 個人的には VL Gothic だが、そういうのは好みの幅が大きいから意見を貰ってもあまり参考にはならなさそう。 このスレを読んでいるとMinGWよりもWSLの方が高速だという話ですが本当でしょうか?
WSLは何となく遅そうなイメージがありましたが、あれはWindowsと同じレベルで動いているのですか? >>846
WSL はあくまでも Linux が動いている。
Windows よりも速い部分もあれば遅い部分もある。
ただ、 Windows の側とのやりとりが発生する部分、
特にファイルの入出力にボトルネックがあるというのはよく指摘される部分だと思う。
I./O が多く発生するような場合には WSL は遅くなりがち。
それと、 WSL を使うということは Windows と Linux の両方が起動して
コンピューターの中に共存している状態。
単純にメモリ消費量が多い。
充分な物理メモリが載ってないときついということはあるかも。
単純に速いとか遅いとかとは評価できないので特性を理解してっていう話だし、
具体的な条件が決まっているなら測定してみるのがてっとりばやいよ。 wsl2はlinuxが動いてるんだけどwslはABI互換でwindowsでlinuxのバイナリを動かしてる感じ
速度はなんとも言えない
なおcygwinはとにかくIOが遅い やることにもよるけどWSLが十分に機敏に動作する環境jなら、Linuxが動いている
だけのWSLの方が処理は早いことが多いかも
ただWSLは所詮Linux部分はLinuxでWindowsとは無関係に動いているような構造
なので、MinGWとかCygwinみたいにコマンドプロンプトとかでLinuxのコマンド使い
たいみたいなことは出来ないし、まだCUI部分しか動作しないとかも考えると
LinuxはWSlじゃなくてVMWareみたいなエミュレータの方が良いかなって思う でもwslってwindowsのexe動くからね
無理矢理感あって俺は好きだよ
まあ正確な動作ということならwsl2だよね WSL2 は、Microsoft が作っている、Linux カーネルを使うから、
毎月カーネルが自動更新されるので便利
Cent と同じで、無料サポートみたいなもの
Amazon Linux みたいなもの。
Amazonが自動更新する。
ユーザーがOS を管理しない、サーバーレス なんかMinGWのダウンロードサイト死んでるように見えるんだけどこれってなんか理由あんの? ffmpegのコンパイルが24時間経っても終わらない前は2時間ぐらいで終わったのに
MinGWでGWが終わる Minimum Golden Weekの略だからな 使ってるといつの間にかC:\msys64\mingw64\libとC:\msys64\usr\lib
に同じパッケ入っているのが、モヤッとする MSYS2 には、pacman -g みたいな、ミラーの最適化ある? >>866
-gオプション自体がない
ざっと見た感じ同じような機能をもつオプションも見当たらなかった gdbでデバッグする場合は、
gdb を起動。
「run コマンドライン」でターゲットをデバッグ起動。
止まったところで「backtrace」する。
「quit」で終了。
これで呼び出し履歴が取得できるぞ。 msys2のpacmanが6.0.0になってからパッケージデータベースの
シグネチャファイルをダウンロードしなくなったな。
~.db.sigってやつ。 早く整備してくれ
ぐちゃになってからずいぶん経つぞ Makefileからcmd.exeでバッチファイル動かす方法ある?
cmd -c hogehoge.bat じゃうまくいかない 漏れは、デスクトップにショートカットを作っているけど、そのリンク先は、
コマンドプロンプトを起動して、Ruby スクリプトを実行する
C:\Windows\System32\cmd@.exe /k "ruby C:/Users/Owner/Documents/Ruby/a.rb"
注意。書き込めないので、cmd@.exeと、間に@を入れました >>875
こういう感じ
D:\learn\make\bat>make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-msys
D:\learn\make\bat>type makefile
all:
cmd -c test.bat
D:\learn\make\bat>type test.bat
echo %date% %time%
D:\learn\make\bat>make && echo meow
cmd -c test.bat
Microsoft Windows [Version 10.0.19041.1110]
(c) Microsoft Corporation. All rights reserved.
D:\learn\make\bat>exit
meow
D:\learn\make\bat>
ただcmd.exeが起動するだけでtest.batが動いてない
そしてcmd.exeが常駐するようで、これを手動でexitすると
&& の右側が実行されてにゃあと鳴く バージョン古いせいかなと思ってやってみたけど
D:\learn\make\bat>make --version
GNU Make 4.3
Built for x86_64-pc-msys
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
D:\learn\make\bat>make && echo meow
cmd -c test.bat
Microsoft Windows [Version 10.0.19041.1110]
(c) Microsoft Corporation. All rights reserved.
D:\learn\make\bat>exit
meow
D:\learn\make\bat>where make
c:\msys64\usr\bin\make.exe
D:\learn\make\bat>
どうやら症状は変わらないみたい cmd からのコマンド引数を/cではなく-cで渡すのは何か理由があるの? お、できた!
makeって/を「ルート」と読んでしまうから-にしてたんだけど、まさかこれだったとは・・・
dx >>881 cmd.exeに限らずWindows付属のCUIコマンドはーをオプションとは見なしません いまどきの Windows には curl や tar が入ってるんだぞ。 kmtar ははいっていますか?taz が使えて便利だったんですが… msys2やcygwinはもう終わりだけど、linux上でmingw-64はwslの波に乗っただろう
wsl/gcc+wsl/mingw-64+win/mingw-64の3重コンパイルでクロス開発が捗る > linux上でmingw
シュールすぎるんだけどw 開発環境がlinuxで、windowsポート考えるならベストチョイスじゃないの
というかそれしかなくね?
linux版がwin版ほどメンテされてないというのは確かに事実で、両OSのmingwで吐かれるwinバイナリが同じという保証は乏しい
wsl使えるなら両方試して齟齬がないか検証すべきでは まあ、やって損はない事と思うよ
makefileに一行加えるだけの手間だし 開発マシンがliunxでもwineみたいなwinエミュレータ使えばwin機なくてもテストは可能かもしれないけど
wineってかなり挙動不審だしな…
windows/wsl環境+mingw for linuxなら本物のwindows環境でテストが完結できるだろ MinGWのGCCやClangてなんかコンパイル遅い気がするんだけど
WSL上のlinuxだとちょっと早かったりする? https://github.com/zhlynn/zsign
これをビルドするのにMSYS2を入れて、git clone git@github.com:witwall/mman-win32とやったのですが、Permission deniedとなってしまいcloneできません。
MSYS2はmsys2-x86_64-20220603で以下のコマンドでコアとパッケージシステムを更新、インストールしています
pacman -Syu
pacman -Su
pacman -S base-devel
pacman -S msys2-devel
pacman -S mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain >>897
Permission deniedでますね git clone github.com:witwall/mman-win32
マルチすんな >>899
過疎スレで誰も見てないなと思ってついやっちゃってごめんね >>900
このスレ以外のxxスレでも同じ質問しています
と全部のスレに描いて置くだけでもはるかにマシだと思うが >>903
どこのスレで聞く予定か決まってないとできないことだね
どっかのスレで聞いて有効回答が得られなかったから他をあたるときは無理
そこでもう諦めろという資格はあんたにはない
せっかく回答しても一言多い人はイヤミなやつと思われる
fjにもいたよ、やなやつ系の人 >>905 他のスレで質問するときに先に質問してたスレを挙げるのはできるだろ。 >>906
その時点でもうクロスじゃねえだろ
しつけえな > どこのスレで聞く予定か決まってないとできないことだね
> どっかのスレで聞いて有効回答が得られなかったから他をあたるときは無理
ここの「できない」「無理」を否定しているだけで、クロスじゃねえかどうかは関係ないよ。 自分が個人的に気に入らないってだけで
他人にああしろこうしろ言う図々しいやつ >>905
>どこのスレで聞く予定か決まってないとできないこと
ちなみにクロスもどこのスレで聞く予定か決まってないとできないことだぞ マルチすんなというバグった骨董品に5chにクロスの機能がないのに無茶ぬかすなと指摘したんだよ
それへの返事()が>>903のような頓珍漢な内容だったんで
端っから破綻している話をおちょくっただけだが文句あんのか?
マニュアルトークばっかりで中身のないハリボテ野郎がw >>902
./configure に、そんなオプションが存在しないのでは?
>No rule to make target 'config.mak'
「ffmpeg config.mak」などで検索すれば? opensslをビルドしたけど、これって成功してる?失敗してる?
make depend && make _build_sw
make[1]: Entering directory '/home/XXX/openssl'
make[1]: Leaving directory '/home/XXX/openssl'
make[1]: Entering directory '/home/XXX/openssl'
x86_64-w64-mingw32gcc -I. -Iinclude -Iapps/include -m64 -Wall -O3 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib64/engines-3\"" -DMODULESDIR="\"/usr/local/lib64/ossl-modules\"" -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -c -o apps/lib/libapps-lib-app_libctx.obj apps/lib/app_libctx.c
/bin/sh: line 1: x86_64-w64-mingw32gcc: command not found
make[1]: *** [Makefile:2624: apps/lib/libapps-lib-app_libctx.obj] Error 127
make[1]: Leaving directory '/home/XXX/openssl'
make: *** [Makefile:1554: build_sw] Error 2 失敗している
直前に実行したコマンドが成功したかどうかは
$ echo $?
で確認する
0 が表示されれば成功
それ以外は失敗 >>913
ちなみに原因は x86_64-w64-mingw32gcc を起動したこと
正しくは x86_64-w64-mingw32-gcc
prefixに指定すべきは
x86_64-w64-mingw32 ではなく
x86_64-w64-mingw32- ということだと推測される >/bin/sh: line 1: x86_64-w64-mingw32gcc: command not found
そういうコマンドが存在しないのじゃ?
コマンドが存在すれば、
which python3
/usr/bin/python3
which x86_64-w64-mingw32gcc
と入力してみれば? opensslをビルドしようとすると
cc1.exe: fatal error: md2test.c: No such file or directory
compilation terminated.
make[1]: *** [<builtin>: md2test.o] Error 1
make[1]: Leaving directory '/home/hoge/openssl/test'
make: *** [Makefile:296: build_tests] Error 1
と出る・・・ コマンドは以下の通り
cd /root/openssl
git checkout OpenSSL_1_0_2s
./Configure --cross-compile-prefix=x86_64-w64-mingw32- mingw64 >>917
>cc1.exe: fatal error: md2test.c: No such file or directory
test/md2test.c があるかをまずは確認 ちなみにLinux上のクロス環境だけど普通にビルドできたよ
$ wget https://github.com/openssl/openssl/archive/refs/heads/OpenSSL_1_0_2-stable.zip
$ unzip OpenSSL_1_0_2-stable.zip
$ cd openssl-OpenSSL_1_0_2-stable/
$ ./Configure --cross-compile-prefix=x86_64-w64-mingw32- mingw64
$ make
$ echo $?
0 どうせ ./configure で間違えたか失敗したんだろうな どうもcheckout時にtest/md2test.cがなくなったっぽい >>920
ほぼ同じことをやったけど、やっぱ>>917と同じ事が起きた
OpenSSL_1_0_2sでもtest/md2test.cがないとコケる If you want to just get on with it, do:
$ ./config
$ make
$ make test
$ make install
とINSTALLにあるけど 実はこれをビルドしてるんです
https://github.com/zhlynn/zsign/issues/158
>>924を参考に
cd openssl
git checkout OpenSSL_1_0_2s
./Configure --cross-compile-prefix=x86_64-w64-mingw32- mingw64
make
make test
とやったんだけど、やはりmd2test.c絡みエラーが出た INSTALL.W64
You will need Perl.
You will need Microsoft Platform SDK
To build for Win64/x64:
> perl Configure VC-WIN64A --prefix=c:\some\openssl\dir
> ms\do_win64a
> nmake -f ms\ntdll.mak
> cd out32dll
> ..\ms\test
とあるね あとConfigureとconfigがあってconfigを使えってことじゃないの linuxでビルドしてみたけどopenssl-OpenSSL_1_0_2-stableだとlibssl.soができないから失敗してるぽい
openssl-OpenSSL_1_1_1の方はmake testまで通った
$ @bash ~/build/openssl-OpenSSL_1_0_2-stable
$ find "." -type f | perl -ne '/libssl/ and print'
./libssl.pc
./libssl.a
$ @bash ~/build/openssl-OpenSSL_1_1_1q
$ find "." -type f | perl -ne '/libssl/ and print'
./util/libssl.num
./linux/libssl.map
./linux/libssl.pc
./linux/libssl.a
./linux/libssl.so.1.1 msys2と違ってtdm-gccはgccのバージョンが選べる代わりに
更新がむちゃ遅いやんけ〜
多分、人手が足りないんやなぁ gcc 自体にはバージョンを混在させる仕組みはある。
クロスコンパイル用の環境を構築したいとかよくあることだし。
MSYS2 でもできなくはないけど、
今だと Docker を使うとかしたほうが簡単なのかなぁ……。 MSYS2 MinGW64 の環境でSDL2を使ってゲームを作っています。
作ったゲームは将来的には配布する予定です。
それでDLLを動的リンクにするためにパッケージに含めたいと思っています。
今のところ起動に必要なDLLが
libgcc_s_seh-1.dll
libstdc++-6.dll
libwinpthread-1.dll
他、SDL2のdll
です。
C++とpthreadのdllは何となくわかるのですがlibgcc_s_seh-1というのは何でしょうか?
MinGW固有のgccのdllですか? >>932
$ pexports libgcc_s_seh-1.dll sizeof(long double) == 16になったのは、いつから? >>930
Mingw-builds じゃダメなのか?
俺も最初は TDM-GCC 使ってたけど、何時までも更新されないから Mingw-builds の 12.2.0 に乗り換えた
俺が使っている wxWidgets 3.2.2.1 も普通にビルドできたし、若干コンパイル速度も上がった気がする
(気のせいレベルかもしれませんが・・・) Windows7 64bitにMSYS2インストールしたら
The MSYS2 project no longer supports Windows 7 and 8.0.
For more information visit https://www.msys2.org/docs/windows_support
って黄色い字で表示されるようになった
とりあえずコンパイルとかはできてる そういやswingを低速言うてるけど
JavaFXのほうが初期化しめちゃめちゃ時間かかってもっさりしてるんだけど…
そしてmacでは未だにスレッド競合解決してない
swnigよりオワコンな気がする 質問です。
・ OS は windows10 で、最近 MinGW-w64 を導入した。
・ 下記の test.cpp ファイルに対して g++ -m64 -o test5 test.cpp と実行。
test.cpp
#include <stdio.h>
#include <stdint.h>
int main(){ printf("%d %x %zu", sizeof(long), sizeof(long), sizeof(long)); getchar(); return 0; }
・ 出力された test5.exe を実行してみると、なぜか「4 4 4」と表示されてしまい、
「8」が1個もない。64ビット環境では、sizeof(long) は「8」なのでは?
・ test5.exe を右クリックして互換モードの欄を見てみると、
Vista 以降のものしか表示されないので、
ちゃんと64ビット版の実行ファイルになっている
(他にも色々な確認方法があるが、いずれも64ビット版に合致する)。
・ それなのに「8」と表示されないのはなぜ? >>944
> 64ビット環境では、sizeof(long) は「8」なのでは?
単にその認識が誤り。
64ビット版の Windows の ABI では long は 4 バイトと規定してる。
https://learn.microsoft.com/ja-jp/cpp/build/x64-software-conventions?view=msvc-170#scalar-types
コンパイラが OS の規定に逆らって独自の仕様にしたってかまわないんだけど、
やりとりがややこしくなっちゃうだけで得なことはないからね。 じゃあこの挙動で問題ないんですね。ありがとうございました。 レス数が900を超えています。1000を超えると表示できなくなるよ。