Cygwin + MinGW + GCC 相談室 Part 8
レス数が900を超えています。1000を超えると表示できなくなるよ。
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 の規定に逆らって独自の仕様にしたってかまわないんだけど、
やりとりがややこしくなっちゃうだけで得なことはないからね。 じゃあこの挙動で問題ないんですね。ありがとうございました。 mingw64でglibとgstreamerに動的リンクしたバイナリ作ったんだけど、glibは関数呼べるけどgstreamerは関数呼べない
なぜかgstreamerの関数を書くとプログラムの起動がコケて関数をコメントアウトするとちゃんと起動する
リンクがおかしいのかもと調べてみたけどちゃんと動的ライブラリはリンクしてるっぽい
あと考えられるのは動的ライブラリの破損ぐらいなんだけど、お前ら何か考えつくことある? VC6時代のソースをビルドしてlddで見ると以下のようになった
ntdll.dll
KERNEL32.DLL
KERNELBASE.dll
msvcrt.dll
VC22は以下
ntdll.dll
KERNEL32.DLL
KERNELBASE.dll
ucrtbase.dll
VCRUNTIME140.dll
上のmsvcrt.dllの代わりに下のucrtbase.dllとVCRUNTIME140.dllでビルドできないか
ファイルサイズがstripしてもVC22の10倍になってしまいmsvcrt.dllを疑っている
バージョンは
gcc version 11.2.0 (Rev6, Built by MSYS2 project) レス数が900を超えています。1000を超えると表示できなくなるよ。