Cygwin + MinGW + GCC 相談室 Part 8
レス数が900を超えています。1000を超えると表示できなくなるよ。
MinGW のgccを起動するとPentium MMX環境では不正な処理で落ちます
i586では動かないのでしょうか？
だとしたらどうしたらいいですか？
Windows 2000 SP4 Mergedoc 2004/09/26 出てた
というかこのトップページいつもユーザーが1300人以上いるんだけど攻撃でも受けてんの？
http://mergedoc.sourceforge.jp/ cygwinの64bit gccではLP64のせいか、MS-C向けのDLLがリンクできない。
そこでLLP64のx86_64-w64-mingw32-gccをcygwin上で使っています。
コンパイルしたものを実行するために、/usr/x86_64-w64-mingw32/sys-root/mingw/bin等の専用DLLのある場所にパスを通す必要がありますが、
他の普通にcygwinでコンパイルしたものを実行する際の邪魔になるのでパスは通したくない。
-staticつければいいけどバイナリがデカすぎる。
なにか、dllのパス名を埋めこむオプションないですかね。
-Rはないと言われるし。 >>6
専用DLLが必要なやつは、バッチファイルから起動するとか。
(バッチファイルの中でだけPATHを通す) バイナリでかくても
結局実行するとそれだけメモリ食うんだろ？ >>8
shared library全否定やな、それ >>7
それすると、パイプで繋ぐような使い方ができないんで。 >>10
bat／cmdファイルってそんな制限があったのか
だったらシェルスクリプトはどうかな >>9
そうなんだけど
質問読んでると
同時実行してるとも思えなかったもんで まともなOSのメモリマッピングならデマンドページングするだろ MinGW
> objcopy -h
> libintl-8.dll がねーぞｺﾞﾙｧ！
よそから持ってこなきゃだめなん（ ﾟдﾟ）？ しばらく前にMinGW更新したら、同じようにそのDLLでエラーになったな。
古いアーカイブファイルから復帰させたけどどうやるのが正しいのやら。 なんかgitに入ってたからそこからコピったら動いた。
>>16
よくわかんないよね そんなことよりもお前らmsys2 + pacmanは使ったか？
あれはいいものだ ディレクトリを選択して右クリックの 送る から cygterm+putty を開くにはどうすればいいのでしょうか？ cygwinでは npm init がエラーになるんだな
ちょくちょく独特なトラブルが起こるからいまいち使いにくい msysはなんか一時期まともにインスコできない時期があったので、
cygwin64にcygwin, cygwin32, mingw32, mingw64のコンパイラ入れまくりに落ち着きつつある。
結局windwosネイティブのdll使うにはmingwじゃないとダメだしクロスコンパイルしまくりでやはり面倒ではある。 x265をコンパイルできるFFmpegをビルドするためにMinGW + MSYSを以下のサイトからダウンロードして
Windows7に入れました。
http://xhmikosr.1f0.de/tools/msys/
MSYS_MinGW-w64_GCC_492_x86-x64_Full.7z
早速x265のコンパイルをしようと以下のサイトを参考にしたのですが、
http://qiita.com/pb_tmz08/items/29165f4c3ef9bc4285ab
hg, cmakeが必要とのことです。（Linuxには疎いのでhgやcmakeがどういうプログラムなのかいまいち分かりませんが）
デフォルトのMinGW + MSYSにはhgやcmakeは含まれていないようです。
hgやcmakeを使えるようにするにはどうしたらいいでしょうか？ ありがとうございました。おかげさまでhg, cmake, ついでにgitまで使えるようになりました。
> MinGWはこっちの方がよくね？
MSYSを別途導入する必要があるようだったので>>23のMSYS_MinGW-w64_GCC_492_x86-x64_Full.7zを使うことにしました。
ところでffmepgのコンパイルをしていて些細な疑問を持ったのですが、
http://d.hatena.ne.jp/kamedo2/20130619/1371662769
のサイトを参考に音声コーデックのfdk-aacをffmpegにマージしてみました。
サイトに書かれていたとおり、
/FFmpeg/fdk-aac-0.1.1/
に移動して
./configure --prefix=/mingw/i686-w64-mingw32
make && make insutall
を実行し、そのあとffmpegのコンパイルをするべく
cd ../ffmpeg-HEAD-4110828
でffmpegフォルダに移動し
./configure --enable-gpl --enable-version3 --enable-nonfree --enable-libfdk-aac
--extra-ldflags=-static --extra-cflags='-march=native -mfpmath=sse' --optflags=-O2
を実行したところ問題無くconfigureは通りました。 調子に乗って「fdk-aacだけでなく最近はやりのOpusという音声コーデックもマージしよう」と
http://downloads.xiph.org/releases/opus/opus-1.1.tar.gz
をダウンロード＆展開し、
./configure --prefix=/mingw/i686-w64-mingw32
make && make insutall
を実行。その後ffmpegフォルダに移動して、
./configure --enable-gpl --enable-version3 --enable-nonfree --enable-libfdk-aac --enable-libopus
--extra-ldflags=-static --extra-cflags='-march=native -mfpmath=sse' --optflags=-O2
を実行してみたところ
ERROR: opus not found using pkg-config
Note: When building a static binary, add --pkg-config-flags="--static".
とエラーが返されました。fdk-aacはよくてopusは何でダメなの？訳が分からずググッてみると
ffmpegのconfigureを実行する前に
export PKG_CONFIG_PATH="/mingw/i686-w64-mingw32/lib/pkgconfig"
のおまじないを唱えると問題無くconfigureが通ることが分かりました。
http://qiita.com/tukiyo3/items/ac36375d426d39f203fb
fdk-aacはPKG_CONFIG_PATHをエクスポートせずとも良くて
OpusはPKG_CONFIG_PATHをエクスポートしないとconfigureが通らないのはなぜでしょうか？ Wikipediaに書いてあるじゃん
http://ja.wikipedia.org/wiki/Pkg-config
まあ要するにコンパイルフラグをいじらなくて済むという話では MSYS2 Avira で TR/Crypt.XPACK.Gen2 連発するから困る >>26
pkg-configにコンパイル時のフラグを調べるためのデータを置く場所を教えるため。
てか、そこまで出来てるくせに勘が悪いな >>27
>>29
コンパイル時のフラグの格納場所でしたか。
不思議なのはfdk-aacはPKG_CONFIG_PATHの場所を教えなくても問題無く進み、
Opusのときはきちんと提示してやらないと進まなかった点です。
二つは仕組みが違うんでしょうか？ >>30
デフオルトの場所にあれば教えんでも工工わな >>31
fdk-aacもOpusも共に
./configure --prefix=/mingw/i686-w64-mingw32
とｃonfiguraしています。だから同じ /mingw/i686-w64-mingw32 にライブラリは格納されてるはずなんです・・・
Opusだけどっかイレギュラーな場所にライブラリをコピーしちゃってるんでしょうかね？ >>30 >>32
疑問を持った時点でffmpegのconfigureの中身を見なさいな。(以下抜粋
> enabled libfdk_aac && require libfdk_aac fdk-aac/aacenc_lib.h aacEncOpen -lfdk-aac
> enabled libopus && require_pkg_config opus opus_multistream.h opus_multistream_decoder_create
ライブラリ有無のチェックに、libopusはpkg-configを用いて判定してるってだけ。
なので PKG_CONFIG_PATH を設定する必要がある。 >>33
そういうことでしたか・・・
そういうの詳しい人が身近にいてくれると助かるんですが・・・ cygwin64上で作業をやっとります。
故あって32bitコードを書かねばならないのですが、
i686-w64-mingw32-gcc, i686-pc-cygwin-gcc共にfopenでPOSIXパスを渡すと、
errno=2, No such file or directory
ということで開けません。
windowsパスにすると開けます
ダメ fopen("/home/foo/bar.txt", "r");
OK fopen("c:/cygwin64/home/foo/bar.txt", "r");
mingwでは仕方ないかとは思いますが、cygwin32までPOSIXパスを否定されると辛い。
objdumpで見ても、fopenはcygwin1.dllのものを使用している模様。
PATHは/usr/i686-pc-cygwin/sys-root/usr/binを通してあります。
POSIXパスを認識させる良い方法がありましたら御指南願います。 >>35
これはコンパイラでなく、OSの仕様。
windows OSの仕様を変更させるか、コンパイラ改造するしかないんでは?
認識できるわけではないが、簡単なのは自作ラッパーを挟む。 >>35
Cygwinの32bitと64bitだとルートディレクトリが違うからじゃね？
32bitコード書くならCygwin32上で作業した方がいいのでは。 >>37
windows8でcygwin32使うとfork errorでまくりでコンパイルが進まないorz >>36
いやいや、cygwin64環境、cygwin32環境でネイティブのgccを使うとPOSIXパス使えるんだわ。
ところが、cygwin64環境でcygwin32(i686-pc-cygwin)だと使えないわけで。
32bit版cygwin1.dllがルートパスをどこと認識してるか、ってところなのかな。 >>38
rebaseallやってもforkエラー出まくりなんだとしたらしゃーないな。
cygwin1.dllがあるディレクトリの1つ上がルートディレクトリになってるはず。
単にUnix形式になってさえいればいいのなら /cygdrive/c/cygwin64/home/foo/bar.txt で
開けばいいし、それだとダメならfstabをいじるか >>40
windows7ではrebaseで治るんだけどなぁ。8.1はどうやっても連発で。
cygwin1.dllの一つ上がルートディレクトリはいい話を聞きましたわ。
マウントかリンクでなか胡麻化せるかも >>40
ファイル回りを/cygdrive形式で徹底することでなんとか胡麻化しできました
有難うございました。 >>40
/usr/i686-pc-cygwin/sys-root/usr
がcxgwin32のルートになるわけやね。
cygwin64の/homeや/optを/cygdpgve/c/cygwin64/homeの形式で
/usr/i686-pc-cygwin/sys-root/usr/homeとしてシンボリックリンク張ったらあらかた違和感なく32bit, 64bit混在できるようになった。 OpenMPをお使いの方、おらっしゃられるでござるか？ あるプログラムをmakeしてるんですが、
./configureで
"Can't find pthread library"
って出ます。
どうすればpthread libraryをインストールできますか? g++で関数に一時オブジェクトを渡した場合の警告を抑制するにはどうしたらよいですか？
function( &HOGE() )
taking address of temporary
いったん変数に受けて回避していますが、その変数を作るのがめんどうくさいです。 MinGWでlibmysql.dllを使いたくて
http://blog.livedoor.jp/dq_school/archives/1256405.html
を参考にして
> reimp libmysql.lib
> gcc -I"/C/Program Files/MySQL/MySQL Connector C 6.1/include" -o tester.cgi tester.c
"/C/Program Files/MySQL/MySQL Connector C 6.1/lib/liblibmysql.a"
とか
> reimp -c -d libmysql.lib
> dlltool -k -d libmysql.def -l libmysql.a
とかやってみたんだけど相変わらず
「undefined reference to mysql_init@4'」
とかのエラーが出やがります。
誰か助けてください。
defファイルを覗いてみたら「@n」のついてる関数名が１つも無いのが気になったけど、
http://tsubaki.hatenablog.com/entry/20121020/1350734844
の
＞defファイルの中を見ると関数名の後ろに@8だの@12だの色々な数字がついているのが分かります。
との記述と食い違うのが気になります。 mingwはvc++用のライブラリをそのまま食えるだろ 解凍したら、gccが出てくるのでは
7zだから解凍できないとか？ MinGW32がちょっとおかしい。TDM-GCC-32ではdbghelp.hが見つからない。
stddef.hが見つからない。何でやねん。 #define _CRT_SECURE_NO_WARNINGS
#define _CRT_NON_CONFORMING_SWPRINTFS
#undef __STRICT_ANSI__
#define __NO_INLINE__ // https://github.com/g-truc/glm/issues/300 Shit! gdbの使い方覚えないといけない。ややこしい！ Cygwinってwindows上でlinuxのsocketプログラムをコンパイル・実行して.outファイルを吐ける
って認識でおｋ？ UNIX系OSでは「a.out」というファイルが出来上がるので、それを実行します。
Windows＋Cygwinでは、「a.exe」というファイルが生成されます Mingwで/etc/fstabをいじらないとautotoolsが動かないなんて初めて知ったわ！
しかも/でlsしても表示されないとかわかりにくｗ よろしくお願いします。
(1) sizeof(long double)って環境依存だよな。
(2) struct A {
int *p; size_t s; int u;
};
なぜsizeof(struct A)が24になるのか理解できない。
20になると思ったのに。 いい加減msysからmsys2に移行しようとして導入したんだけど、なぜかprofileにインクルードパス
指定してconfigure走らせるとshがコアバンプ吐く。ライブラリパスは指定しても問題なし。
なのでconfigureの時にいちいちCFLAGSにパス書き込んでるんだけど、そういう仕様なのかなコレ msys2でconfigureは一回もやってないが、なんかファイル名補完がおかしいな
gcc -o test.exe test.cでコンパイルした./test.exeが./t<tab>で補完できない
./test.e<tab>でようやく補完できる
test.c があるとダメみたい。拡張子なしtestもダメ
test.txtがあってもおｋで.cppも.ccもダメだ。コンパイラで使う拡張子がダメ？
検索すると出てくる日記にある、実行権限どうこうとはまた話が違うようだ。
こっちが悪いのか設定でなんとかなるのかわかんない
回避策としては、_test.exeなどと先頭に_でもつければ./_<tab>2回でいいみたい。
そもそもいきなり<tab>で何もでないのは普通の挙動だっけ？まいっか ストレージ損傷に備えてのMinGWシステム丸ごとバックアップとリストアのノウハウ下さい はじめて､MinGW使ってるんだけど
テキストにプログラム書いて保存して､コマンド実行だろ?
簡略化できませんか？ >>68
ターミナルで3文字くらい打ち込んだらタブキーを押せ 適当なビルドツール、タスクランナー、それをテキストエディタから呼び出すための
プラグイン
これ以上はどの言語でどのエディタ使って作ってるかわからんからなんとも言えん まあたいていの場合保存、ビルド、実行まで連続でやってくれるプラグインを
作ってる人がいると思う だからそれを自動実行したいって話じゃないの？
最近ではmakeやautotoolsを包括したcmakeってのが使われてるみたいだけど
使ってないからまだよくわからんな
自分はvimにquickrunってプラグインいれてる
どの言語でも適切にビルドや実行のプロセス起動してくれてる 初心者です
MinGWのページいってダウンローダー取ってきてMinGW Installation Manger起動して
Basic Setupのそれっぽい4つほどチェックしてインストールしたら
MinGW\msys\1.0\binにmakeやbashとかはあるのにconfigureがないのはどうしたらいいでしょうか？
All Packageみてもそれらしいのが見つからない configureは作りたいプログラム毎に全部中身が違う
つまりあなたの責任でなんとかするしかない
あるいは小規模ならconfigureは無しにするという選択肢もある >>80
レス感謝
勘違いしてました
79の質問取り消します autotools使うならmsysの中にあるpostinstall忘れずに MinGWなのですが
ターミナルでfindコマンドを実行すると
日本語の表記が文字化けします
lsやdiffで表示される文字は化けないのですが
考えられる原因って何かありますか？ 具体的にどう実行するとどういうファイル名がどう化けるかを mingwは日本語対応じゃないから。
cygwinとminttyつかえ >>83
自分のところだと find は find -print0 だとなぜか漢字が表示される ちょっと前までcygwin使い辛い気がしてたんだけど
gnupackで随分導入しやすくなってたんだな >>87
同じくfind -print0だと表記は問題なくなりましたけど
改行されなくて見辛いですね・・・ ls -C | nkf -s
ls -C | iconv -f cp932 -t cp932
ls -C | nkf -w
ls -C | iconv -f cp932 -t UTF-8
とか面倒くさい >>89
find . -print0 | xargs -0 -n1 find "." -maxdepth 1 -exec echo \"\{\}\" \;
とか面倒くさい setup.exe落ちてこない。
setupもmirrorに撒けよな。 sourceforgeのmsysが怪しいらしいよ。ウイルス？ だれかはよmsysを検証してくれ。msysが怪しくて仕事にならん。 使ってるセキュリティソフトのメーカーに言え
それか別の所から落とせ MSYSにウイルス入ってるらしいよ。配布元がsourceforgeしかないから対処法なし。
http://devkitpro.org/viewtopic.php?f=2&;t=2223 MSYS2のmingw32でgcc -vを実行すると
--disable-sjlj-exceptions --with-dwarf2
になっていた。
MSYS2のmingw64だと、特に指定はないからsjljだろうな。 英語が読めないのはしょうがないとしてせめてニュースの日付くらいは理解できるようになってくれ msys2自体をpacmanでインストールしたら
エラーがいっぱい出たのでmsys2をフォルダーごと消去ましたでありんす ただの誤検知じゃないか！
少しは内容読んでから書き込め msys2で作ったプログラムはmsys2でしか動かないのでしょうか？
clang++でコンパイルしてみたらmsys2でしか動きませんでした G++でも同じ症状です
アプリケーションを正しく起動できませんでした(0x000007b)。とでます。
文字コードもutf8じゃなくなります
標準入力を、リダイレクトでファイルから入力しても
引数の数が１つのままで2になりません なぜかmsys64/binにあるclang++でwindowsのコマンドプロンプトで
コンパイルしたら実行できました
なぜmsys2でコンパイルすると実行できないんですか？ msys2でもmingw64/binに移動して./g++でmsys2上でコパイルしても
コマンドプロンプトで動きます /mingw64/bin/g++ a.cpp
と絶対パスを指定してもコマンドプロンプトで動きません
しかし/mingw64/binに移動してg++を実行すると動きます 出来たexeファイルをmingw64/binに移動したら動きました
このフォルダに実行するのに必要なファイルがあるのかもしれません libgcc_s_seh-1.dll
libstdc++-6.dll
libwinpthread-1.dll
を入れたら動きました
これなしで動くようには出来ないのでしょうか？ 検索したら解決しそうなのでもういいです
ありがとうございました まだ3つのうち２つの問題が解決してないですよ
リダイレクトの問題とutf8の問題です リダイレクトの問題はやり方自体間違っていました
それでもutf8がmainの引数から読み取れない問題が残っていますね
これは難しそうなので諦めます これを含めた11個の書き込みは
このスレッドに存在しないとみなしてください
そうしてこのスレッドへの書き込みの締めくくりとさせていただきました utf-8の問題はmsys2_shell.batで起動して
gccをインストールしたらutf8で読み込みました msys2_shell.batではclangが使えないのが問題ですね
どうやら解決策は無いみたいですね clangってマイナーなのでmsys2までサポートしてると考えにくい
msys2開発してる人数少ないはず MinGWは関係ありませんが質問よろしいでしょうか？
Cygwin32bit+gccの環境で、Cでhello worldを打って、
gccでコンパイルすると以下のようなエラーがでてコンパイルできません。clangやg++でやっても一緒でした。
だれか何か解決策を思い浮かびませんでしょうか？
お願いします。
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/ld: unrecognized option '-plugin'
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/ld: use the --help option for usage information
collect2: エラー: ld はステータス 1 で終了しました >>123-124
そもそもライセンス的に相性が悪い
他人はあてにできん 125です。自決しました。
Cygwin Setupを眺めているとDevelのbinutilというのSizeが?になってたので、アンインストールしたら治りました。
「GNU assember, linker」と書いていたのできっと二重インストールにでもなってたのかもしれません。
よかったです。 >>129
x64は移植が難しいらしい
特にsjijからsehが出るまで時間が掛かったろ
64bitWindows固有の問題っぽい
焦らず待て
フォルダが出来てるって事は遠からず出るはず SSOってほんとにCOWより速いんか？
信じられん。 >>130
俺もそう思ってWKTKしてたんだが、20日以上経つからな >>132
5.2.0RCはもう出来ていてValidation Testを行っている最中に重大なバグが発見されて
直してる最中じゃね？
じゃないとこれみよがしにフォルダ作ったりしないだろ DistroもTDMもまだ5.2.0が出てないから多分ここのソースを参考にしてるんだろうなあ
ただこいつらOpenMPに対応してないしなあ 今度こそ大丈夫でした
リンクは>>135と同じ
sjljなのでsehに比べると例外発生時ややスタックの巻き戻しが遅いけどとにかく5.2.0をMinGWで
動かしてみたい人はどうぞ pacmanがforkに失敗して自分自身を消しちゃって
pacman command not found
になってるんだが。。。 >>142
ふつーの fork() だったら返り値が-1でerrnoを参照することができると思うが‥なにが起こったの？ >>144
分からないからファイルを全部消して再インスコした >>147
昔々、パックマンというゲームとゲームのキャラクターがあった。
黄色い丸に大きな口がパカパカ開いて動くようなキャラだった。
スーパーマリオブラザーズが出てくると、それを真似て、手と足がついて横スクロールゲームになった。
「ゲーム パックマン」でググれ。 >>148
あれはマリオがパックランドをパクったんや そこらへんにころがっているpexports.exeには、
ウイルスがしこまれてるかもしれないから、気をつけて。 MSYS2でパッケージを更新するときは、update-coreコマンドを実行後、bashを再起動してから
pacman -Suするのが正しいやり方。 Cygwin g++ですが、5.2.0 だと string が使えないです。コンパイルはできるのに、文字が表示されません。
4.9.3だと正常に表示されます。なぜでしょう・・ １つのcygwinを２つのＯＳからアクセスするとエラーでる。
rebaseとかやれば直るけどまた他方でエラーになる wstringだとコアダンプしました・・・なんかstringの使い方がわかってないみたいです。出直します。。 1つのcygwinを2つのOSからアクセス？
意味がわからんが、どうでもいいやｗ どうでもいいと言う人は実はどうでも良くない
本当にどうでもいい人はレスしない >>159
その理屈だと「どうでもいい」という言葉を言えなくなるなｗ 訊ねられてもいないのに自分からどうでもいいという場合はまぁあれだな >>158は
「ちょっと心に引っかかったが、まあ解明をそんなに強くは望んでないよ
だからこの件に関して別に返事しなくていいからね」
って意思の表明だろうからここから発展する物は何も無い cygwinでバージョンを指定してpackageをインストールしたい場合は
どうしたらよいでしょうか。
たとえばpython3.1など setup.exeでは3.2と3.4があることを確認できましたが、3.1はありませんでした。
cygwin package searchにも3.3は出てこなかったのですが、これはcygwin用のパッケージが
無いと言うことでしょうか。 3.1なんて2.7より遺物、考えなくていい
使いたいならパッチを当ててビルドするしかない
https://github.com/cygwinports/python3 >>166
以前あったけど今見つからない、という趣旨だとすると
その通り、選択したミラーサーバに残ってないという理解でいいと思う MSYS2 で Windows API 関連のヘッダファイルは /mingw32/i686-w64-mingw32/include やその下のディレクトリにありますが、
デフォルトではここはサーチパスに入ってないですよね。
使いたければ -I オプションで陽に指定するのが妥当なんでしょうか？
なんか不格好な気がするんですが。 ん？MinGW-w64 Win32 Shellから起動すれば入ってるんじゃ？ シェル(bashやらzshやら)から起動しないと/から始まるパスが読めない minttyはputtyをベースにしてるからな。
良いのは当然。 cygwinをダウングレードもしくは古いバージョンを再インストールするにはどうしたらよいですか？ msys2のmakeでこの行が通らない
@CROSSCOMPILING_FALSE@ @(cd tests; $(MAKE) all quiet-test)
なぜだー C++11を古いウィンドウズ(Windows98)で動かしたいんだが、叶姉妹だろうか？ You should go to another thread, fuck. 口が十もある女は市にでてもその女は未だうれていない。 くらいのところかな。 make
でビルドするの時に、VSにあるような、MT MD に類するの設定はないのでしょうか？ >>184
LDFLAGS='-static' makeとか？ <iostream>使うと、EXEがメガバイト級にバカでかくなる。
-Os -sとstrip --strip-allを使ってもあまり小さくならない。 windows.h+crt+STLのウィンドウアプリで
MinGW-w64のMingw-buildsでg++4.8.5/4.9.3/5.3.0試してみたんだけど
エラーと警告の行番号が+1行ずれて表示される。ヒント行内容表示も同様
列はなぜかあってるので、エラー状態を次の行に持ち越したからじゃないと思う
ソースコードはShift_JISコメントありでCRLFもちろん-finput-charset=cp932付き
検索しても知恵袋が1個見つかる程度だった。英語情報はうまく検索ワード絞り込めない <iostream>を使うとsegmentation faultになるバグがあるようだ。 バグ追跡にイタズラをしてMinGWの開発を妨害している輩が居るようだ。 MSYS2使ってるのに配布元飛び越えていきなり本家に迷惑かけるな
しかもどうせおま環 mingw-w64-crtに ca451a7 の変更が取り込まれたバージョン(v5.0-rc1等)を使ってるなら原因はこれ。
https://github.com/Alexpux/MINGW-packages/issues/1104
mingw-w64のmasterブランチは 5981c02 でRevert済み。
[r4619-ca451a7]
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/ca451a7a45d4876065edc6755f8aab8095914b04/
[r4626-5981c02]
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/5981c0281b1f65b8f9b38b13f504f8af3f6ff209/
MSYS2-Packagesのmingw-w64-crtは該当バージョンのままなので、要更新な状態。(もしくは古い物を使う)
> msys mingw-w64-cross-crt-git 5.0.0.4624.4c13e3f-1
上記内容に該当してるのであれば、GCCへのバグレポートは取り下げて、
Alexpux氏にMSYS2-Packagesのcrtも更新する様伝える事。 $ pacman -Sy
$ pacman -Syu
したら直ったよ。最新版じゃなかったみたい。 MSYS-Packages内のPKGBUILDの内容を見るの忘れてた。。
crtは最新verではないけどPKGBUILDのパッチ処理でRevert済みだったわ。
>>193
githubでコメントしたみたいだけど、手間かけさせてスマン。 今の最新のmsys2にアップデートするとbinフォルダのupdate-core.exeが消えてしまうな
バックアップしといてアップデートが済んだら書き戻しといた方がいいようだ Cygwin終了のおしらせ
ttp://japan.zdnet.com/article/35080338/ >>197
Visual Studioが既にGitに依存してるからな >>195.196
pacman -Syuするとなんか二段階になっているけど前からだっけ?
update-coreいらなくなるなら進歩だね
:: Starting core system upgrade...
何も行うことがありません
:: システム全体の更新を開始... msys2をConEmuで使っているんですが
midnight commanderを使うと表示が崩れてしまいます
試しにmitterでやるとうまくできました
ConEmuでも正常に表示させる方法はあるでしょうか
よろしくお願いします 200です
mitter・・・x
mintty・・・o
いつも使っていなかったので間違えました
すいません 過疎っているけど・・・質問させてください
Windows10Pro 64bit上にMSYS2をインストールしてMINGW64を主にシェルとして使っているのだけど
Linux上では正常に動いてMINGW64上ではSegmentation Faultになるプログラムが有るのです
どうもグローバル変数の宣言がうまく処理できていないようなんだけどコンパイルオプションとかで対処できないでしょうか？
ソースをコピペします
main.cpp-------------------------------------------
#include "class2.h"
int main( int argc, char *argv[] ) {
//Class2 object2;
return 0;
}
class1.h --------------------------------------------
#include <string>
#include <map>
class Class1 {
std::string type;
static std::map<std::string, Class1 *> map;
public:
Class1(std::string s);
~Class1();
};
class1.cpp -------------------------------------------
#include <iostream>
#include "class1.h"
Class1::Class1(std::string s) : type(s) {
std::cout << "Class1::Class1 type=" << type << std::endl;
map[type] = this;
}
std::map<std::string, Class1 *> Class1::map;
Class1::~Class1() {} 続き・・・
class2.h ------------------------------------------
class Class2 {
public:
Class2();
};
class2.cpp ---------------------------------------
#include <iostream>
#include "class2.h"
//std::map<std::string, Class1 *> Class1::map;
#include "class1.h"
Class1 object1("XXX");
Class2::Class2() {
std::cout << "Class2::Class2 " << std::endl;
}
以上です class1.cpp
Class1::~Class1() {}
よく知らないけど、仮想デストラクタなんて、直接呼ぶもの？
こういうのは、実装・処理系が呼ぶんじゃないの？
君は、C++をかなり知っているの？ >>202
規格では異なる翻訳単位(class1.cpp, class2.cpp)で定義されてる
静的記憶期間を持つオブジェクト(Class1::map, object1)の初期化順序は未定
コンパイルオプションでどうにかなるものじゃないので設計を見直す・ソースを修正する それデストラクタの実装書いてるだけじゃないの？
そもそも仮想ですらないだろ >>204-207
レス有難う御座います。
人がいないと思ったら居るんですね。ありがたや
>>205
そうですか、あるアプリケーションをコンパイルしたら上記のソースのような箇所が有りまして・・・
姑息ですがグローバル変数の定義を直前に書いて凌ごうと思います。
よく分からないのがstd::mapではエラーになるけどstd::stringだと動いたりするんですよね
実際のソースではQMapの箇所で引っかかったりしています >>208
まあ、仕様で未規定ってなってるんだから、何が起きても文句は言えない部類だと思うよ。
良くわからなくて当たり前って事ね。 本家ようやく6.1.0来たな
Distroはsjljだから嫌いでちゅ gccなら__attribute__((init_priority(N)))使える >>210
嫌なら自分でビルドすれば良いんじゃないのか スレチだったら申し訳ないのですが
Windows10からCygwin/Xでリモートのサーバに
Xwin -query [鯖のIP]
とやった場合、キーボードがUSキーボードに変更されてしまうのですが
日本語キーボードのままにしておく方法はないでしょうか？
なお
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
に「IgnoreRemoteKeyboardLayout」（dwordで1）を入れる方法は効果なしでした 補足すると
Xwin -query [鯖のIP] -xkbmodel jp106 -xkblayout jp
でもダメでした
あとsage忘れ申訳ない bashのせいらしい
Windows10 Anniversary updateで知らぬ間にSSHdが起動している
http://yasuhide.blog.jp/archives/48155574.html あるプログラムをgcc (4.9.x)でコンパイルすると、-O2より-O0の方が
1.5倍ほど高速になってしまうのですが、考えられる原因はなんでしょうか？
普通のC++のコードだと思いますが、強いて言うと巨大なswitch caseが
あります(300 case)。MinGWでもLinuxでも同じ傾向になります。 >>222
なるほど、コンパイル時間の話なら十分ありえるね プロファイルとると面白い記事になりそうだな
最悪再現ソースだけでも 221です。高速なのは「実行時間」です。コンパイル時間ではありません。
やっぱり普通じゃないということですね。
アセンブラに出力して、地道に解析してみます。 いえ、アセンブラで解析するスキルが無いから、ここで質問してみたのでした。 >>226
コードを出さないとわからんよ。情報が少なすぎる cygwinと一緒に配布されているmingwはコンパイラはgcc-5なのに
wxWidgetsはgcc-4.8でコンパイルされててgcc-5と互換性がないとかいう糞仕様。
C++ABIが変更になってるせいだけど、影響ありすぎて迷惑 gcc5で旧ABIを使うか全部新ABIでリビルドすればいいだけ そもそも、cygwin+gccなんて環境でつくってるようなところなんてあるのか？ VSで作ると重いんだよ
メモ帳で簡易的に作れるだろ gnu autotools と emacs じゃないと作る気になれん 質問です。MSYS2インスト後、pacman -Sy mingw-w64-i686-toolchain でg++ 6.2.0 が入ったのですが、
都合で、g++ を 5.4.0あたりにデグレードしたいのですが、ググってもよくわかりません。
どうすれば可能ですか？ >>237
pacmanはデグレード管理できないことがわかりますた。使えないっすねぇ。
Cygwin+Mingw-64環境の方が使いやすいわ -std=c++11オプションをつけるとbits/stdc++.hがインクルードできない 質問です
MinGWでincludeでエラーがでるんですが、パスを教えてください！
お願いします ------------------------------------
#
# Usage:
#
# $ source setenv_gcc540
#
MINGW64=c:/mingw-w64/i686-5.4.0-win32-dwarf-rt_v5-rev0/mingw32
if [ -d "/usr/i686-w64-mingw32/bin" ]; then
umount /usr/i686-w64-mingw32
mount ${MINGW64} /usr/i686-w64-mingw32
else
mount ${MINGW64} /usr/i686-w64-mingw32
fi
export MINGW_HOME=/usr/i686-w64-mingw32
export PATH=${MINGW_HOME}/bin:${MINGW_HOME}/i686-w64-mingw32/bin:${PATH}
export LIBRARY_PATH=${MINGW_HOME}/lib:${MINGW_HOME}/i686-w64-mingw32/lib:
export C_INCLUDE_PATH=${MINGW_HOME}/include:${MINGW_HOME}/i686-w64-mingw32/include:
export CPLUS_INCLUDE_PATH=${C_INCLUDE_PATH}:${MINGW_HOME}/i686-w64-mingw32/include/c++:
------------------------------------ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) >>237
>都合で、g++ を 5.4.0あたりにデグレード
俺も自力でビルドした5.4を運用中
ソフト板のサクラエディタにも書いたが、msys2のgcc-6.2でサクラエディタをビルドするとクラッシュした。
おかしいなと思って6.1をビルドして再びビルドしたら今度はビルド中にセグメンテーションっぽいエラーで止まる
試しに以前野良ビルドした5.2でビルドしたら正常にビルドでき、エディタもクラッシュせず使えるようになった
本家のバグレポート見てもｃ++のビルドが途中で止まる or ぶっ壊れるとか無いみたいだし、おま環なのかなー 昨日Dev-Cってのをダウンロードしたんだけど、このスレの仲間なの？ おそらく自演の誘導なのだろうが、面白そうなので弄ってみる・・ Distroは6.3.0出てるのか・・・本家の方ももうじきだろうな
待つか、それともDistroを入れるか 本家MinGWの成果物はMinGW-w64の32bit sjljでスタティックリンク可能で
dwarfでは無理っていう考えで合ってます？ MSYS2、パッケージ更新した後コンソール起動させるとエラーも吐かないまま強制終了するんだけど
どうすればええの compinit で落ちるわ
原因ワカンネーからとりあえず compinit コメントアウトしとくわ
>>257
治んなかった OSのバージョンもパッケージのバージョンも書かずに・・ ここ見て msys2-runtime-devel msys2-runtime ダウングレードしたら動いた
https://github.com/Alexpux/MSYS2-packages/issues/793 windows2000でmingw-get-inst-20120426使っているが
インストール時にすべてdownload failedになる
12月ごろからだと思うが何か仕様でも変わったかな msys2のmingw 64でgit stashをやると
': 有効な識別子ではありません : export: `dashless
とかエラー出てるし
治らないし
誰か試して解決策教えてください printf(%b,xx)
2進法での表示はできないのかな？ あり
てっきり できるかなと何回もやってみたけど・・ cygwin の xserver を使っている人いる？
同じく cygwin の freeGLUT を使っている人いる？
描画されないんだが，まず何を確認したらいい？ >>271
cygwinのXserver使ってます。 >>271
まずは
/var/log/xwin/XWin.0.log
かな? 実行時に標準エラーに
libGL error: required WGL extension WGL_ARB_multisample is missing
libGL error: required WGL extension WGL_ARB_multisample is missing
が出る，このWGL がよくわからない．
ログは次のとおり
http://codepad.org/hu8zMgSM テストプログラムは
http://codepad.org/iE1MX9wa
コンパイルは
$ gcc glut03.c -lglut -lGLU -lGL
で通る．
なにか経験談のようなものでもいいので，情報がほしい
よろしくお願いいたします． 拡張機能が使えない？
有効になってないか、そもそも対応してないとか
根拠は無い DLLのリンクは通ってるの？
わからなかったら
objdump -p glut03.exe | grep DLL
してみたら？ 実行時のログが貼ってあるのにリンクがどうのとか言い出すレベル 一番良い方法はLinuxをやめてWindowsにする事だよ cygwinインストール時に/etc/postinstall/0p_000_autorebase.dashで止まって進みません
set-up再起動したり本体再起動してもダメでした そこはrebaseに時間かかる場合は止まっているように見える
ディスクアクセスが続いている状態なら辛抱強く待つべし MinGW + freeglut か
Visual studio C/C++ + freeglutの方がいいと思うけど…… 回答ありがとうございました
cygwinはインストールに時間がかかってしょうがなかったのでMinGWとテキストエディタにTerapadを使うことにしました http://www.msys2.org/
msys2-x86_64-20161025.exe
SHA256: 2c198787ea1c4be39ff80466c4d831f8c7f06bd56d6d190bf63ede35292e344c
$ sha256sum.exe msys2-x86_64-20161025.exe
2330957bc431fffb5fd359e40c20b2464be34ebbd1bfb531a7b09fba0c2808f7 *msys2-x86_64-20161025.exe プリプロセッサのcppのソースはどこにあるのか！？ MSYS2のwindresとcppをコピーして、自分のプログラムで使いたいんだけど、
windres.exeとcpp.exeを正しく実行するにはどうすればいいでしょうか？
最小構成にしたいと考えています。 include
lib
とexe
で試す
足りないものは追加 >>292
ありがとー、コンパイルできるようになった。 msys2で取得したgtk(gtkmm)をcmakeでmakeファイル作ったり
code::blocksでmsys環境外で利用したりがやっとわかってきた
具体的にはpacmanで取得するmakeやpkg-configはmsysではなく
mingwで統一しないとダメらしい しっかし何でGTKはバイナリのダウンロード止めちまったんだろうねえ？
いやまあ確かに更新はmsys2のpacmanでやった方が楽だろうけどさ
code::blocksのプロジェクトテンプレートが使えないとか
IDE使った導入に問題がある msys2のpacmanで取得したwxWidgets試してみたがコンパイルして実行してみるとエラーが出て駄目だった
なんかMismatchがどうとか
しようがないのでソースからビルドしたら今度は実行出来た
外部のIDE使うときはwx-configの出力結果をprefix調整してコピペ しかしコンパイラのバージョン合ってないと起動できないとかシビアだな
毎回ライブラリをビルドし直さないとならないって事か
まあwxはcode::blocksと相性良さそうなんで使ってみます hoge.dll から hoge.a を得るにはどうすればよいですか？ hoge.def はありません
また hoge.dll 用の hoge.lib もあるので hoge.lib から hoge.a を得る方法でもいいのですが
ご存知でしたら教えてください Cygwin,MingW環境に限らず(まっとうなやり方では)どうやってもできません
.dllファイルは構造的には(特殊な).exeファイルと同じで
元になったオブジェクトファイルの情報は失われているので
構造的にはオブジェクトファイルの集合体(コンテナ)である
.aファイルへの変換・作成に利用することはできません mingw DLL リンクで検索すれば何か分かるか 普通にdllを使いたいって話だったのかな？
それならMingWのldは.libのインポートライブラリもサポートしてるはずなので
.libがあるならわざわざ.aファイルを用意する必要はないはずですよ
>>305はdll->スタティックライブラリに変換->完全な静的リンク(実行時にdllを必要としない)を
考えている場合のものでした 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
しらんけど インポートの定義は自分でヘッダファイルとか見て書かないといけないんだっけ？ そこまでするなら LoadLibrary GetProcAddress とあんま変わらないんだよな
面倒だからやりたくないんだよな GNU GDB 7.2 snapshot - with rudimentary TDS (Turbo Debugger Symbol) format support (originally written by Troy Rollo) obtained from old mail list postings,
and migrated to this snapshot with some corrections and slight enhancement.
https://sourceforge.net/projects/gdbwtds/ MinGW w64入れようとしてInstalling FilesでDownloading file...となってるときに
"The file has been downloaded incorrectly!"って言われてインストール失敗してたけど
ユーザー名に2バイト文字使われてたのが原因だった path tmp=c:\tmp とかに変わってても出るかな w64はインストーラ使わずに7zを直接落として使ってるわ。 XPのPCで、mingw-get-setup.exe起動してMinGW+MSYSをインストールしようと
思ってるんだけど、「cannot open URL」と出てインストールできないんだけど、
対処法ありますか?
同じNW環境のWindows 7、10ではインストールできてます
ブラウザから、prdownloads.sourceforge.netのURL(～?downloadってついてるサーブレット?)へ
アクセスすると、インストーラが落とそうとしているパッケージはダウンロードできます
でもインストーラは、～.xzなパッケージをダウンロードできない、ようです >>317
ユーザー名が2バイト文字になってるとか >>318
情報どうもです
ユーザ名ですが、1バイト文字のみです 317です
>>320
さすがに色々と設定されているので今からは…
>>321
いえ、Proxy環境ではありません
Avastとか切ってもやってみたのですが、相変わらずインストールが成功しません…
パッケージ類をwgetとかで手元に置いといてローカル環境からインストール、みたいなこと
できるのかな… >>322
インストーラはOSの、てかIEの機能使ってパッケージをダウンロードしてる
んで、XPのIEってIE8だろ
SourceForgeとのTLS1.1とか1.2でのネゴシエートみたいなのができないからだろうな
サイトもまともに見れないのでは
32ビット環境のWindows10でインストールされたフォルダを丸ごとXPにコピーしたらどうだろう >>322
別のPCかVM環境用意してそこでクリーンなOSで試すんだ
それでうまく逝かないんなら時間の無駄 317です
クリーンインストールしたXPで再度試してみましたが、NGでした
>>323
これが真の理由のようです
IE8ではSourceForgeのページも表示されませんでした インストーラじゃなくminge-get単体で使えばいい
mingw-get updateしてから(mingw)\var\lib\mingw-get\dataの中を見れば必要なものは大体分かる # # echo foo | sed -e 's/foo/bar/'
bar
✔ Success (retv = 0)
# # echo foo | perl -pe 's/foo/bar/'
✗ Failure (retv = 127)
# # which perl
/usr/bin/perl >>327
ファイル/usr/bin/perlが壊れてるんじゃねえのかな
perl -vってやって起動するかえ? >>328
起動しませんでした
apt-cyg remove perl
apt-cyg install perl
で解決しないから困りました 失礼しました
# perl -v
✗ Failure (retv = 127) それはないかと
# which perl
/usr/bin/perl
✔ Success (retv = 0)
# # /usr/bin/perl -v
✗ Failure (retv = 127) 環境がよくわからない。failureとかの文字はshellが出してる？ 多分シェルがだしてる
このcygwin は gnupack_devel-13.06-2015.11.08 のを使っています 今気が付いたのですが gnupack のはポータブルなので
新しくダウンロードした方にhome 以下移したら
apt-cyg install xxx
などの手間はかかるけどperl 動きますね
今回はそれでOK
お騒がせしました 手元の mingw32/g++ 6.4 で仮想デストラクタがらみがうまくいかない現象が起きています
mingw32/g++ 5.4 ベースに戻すとうまくいくようです
なにか情報ありませんか？ >>337
モジュール名が更新されており、libstd++ ともども cygwin のモジュールを削除した上で新しく入れなおすことで解消しました
mingw64-g++6.4 で問題ありません
お騒がせいたしました Perlをmingw（windows7）でビルドできた人いる？
どうやったのか教えて欲しい ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ スカトロMinGWがいち早くgcc7.3.0になったな 最近MSYSがまともに動かないリリース連発してて萎えるわ
みんなWSLに移行したのかね >>342
更新失敗してない？
msys-2.0.dll (msys2-runtime)
pacman.exe (pacman)
bash.exe (bash)
この辺はいつも削除失敗で手動でコピーするはめになってる
人によってはターミナル系もかな これまでMSYS2と仮想マシン上のLinuxを両方使っててWSLも試してみたけど
WSLだけで全部賄うのは無理だし、MSYS2の代わりになるかも微妙だと思った cygwinってハードの最低動作環境ってどんなもん？
セレロンG1610でも十分動く？ LLVM Clangって､見つけたんですよ
gccより高速で､エラーの内容がわかりやすいんだけど
なんで､gcc使い続けてるの？ ゼロから作るんならClangでも良いけどgccでコンパイルできる
ソースが必ずしもClangでコンパイルできる訳ではないからでは visual styleのマニフェスト設定がわからん。。。教えてくれよ。 スクリプト走らせてるとusememが肥大化してしまうのですが
Cygwinのメモリ開放ってどうやるんでしょうか？ >>353
ありがとうございます
ただ、topなどで確認してもプロセスが占有してるというよりはよくわからないけどfreeのメモリが消費されてるといった感じなんです
あきらめて別の方法を探してみます スカトロMinGWを消してMinGW W64 7.3.0を入れた
ようやく来たか i686-7.3.0-release-posix-dwarf-rt_v5-rev0.7z
MD5 d1e009df8d254a15a549c5af2e2200db
SHA-1 96e11c754b379c093e1cb3133f71db5b9f3e0532
↑
これ、カスペが反応するんだけどみんなのところではどうよ
C:\mingw32\opt\bin\python.exe トロイの木馬 >>356
カスペはわりと誤検知を是とする製品だね
除外リストに入れてやるしかないと思う msys2 64bitとcygwin64両方ともautomakeを使おうとすると
ラッパーさんから使えるバージョンはないとか怒られて終わります
これのせいでautoconfとかも途中で終わるのでつかえません
調べまくりましたが途方にくれました何かアドバイスを
ちなみにautoconfは普通にバージョン見ると2.69で
automakeは1.10から1.9までたくさん入っています
他のlibとかも全部入れたと思います
調べたらラッパースクリプトがバージョン判断出来なくてコケるみたいなのを見たんですが
そのへんがよくわかりません sygwinは分からんけどmsysはpacmanで入れたモジュールなのかな
普通にpacmanで作った環境では特に問題なくautoconfできるけど >>359
pacmanで入れました
(どうしてもPGP鍵のエラーを解決出来なかったのでｓｉｇｌｅｖｅｌ無理やり変えたけど)
自分が信用出来ないので複数の入門用サイトのインストール手順そのままなぞっても変わらず
cygwinは普通にsetupから入れました
autotoolなど使わないで普通にコンパイルするだけなら普通に出来ます
最初はemacsとかでかいのをやろうとしたのですが、ハローワールド的なプログラムで
試しにやってみてもautoreconf等やはりautomakeのところで引っかかって終わります
msys2とcygwin両方とも同じというのが何故なのかわからないです
msys2の入口はどのみち3種類どれでやっても結果は変わらないです
am-wrapperに使えるバージョンが無いって怒られます
pacmanの入れ方が駄目だったんでしょうか あれ？鍵の更新も出てるメッセージの通りにやれば出来なかったっけ？ 鍵は特に指示するようなメッセージはないです
暗号エンジンが不正とかパッケージが壊れてるとか鍵が不正とかそれだけで
とりあえず適当にautomakeを打つと
$ which automake
/usr/bin/automake
$ automake
am-wrapper: automake: error: Unable to locate any usuable version of automake.
I tried these versions:
With a base name of '/usr/bin/automake'.
msys2とcygwin64両方同じです
これは正しい反応なのでしょうか 今気が付いたんですが
$ automake-1.10 とか直接やると当たり前かもしれませんがconfigure指定しろと動くので
やはり選択出来てないみたいです
あと調べるとWANT_AUTOMAKEでバージョン指定出来るみたいなので
それでautomakeするとエラーは出ないです
調べてもこんなところでつまずいてる人誰もいないみたいなのに何故… I tried these versions:
With a base name of '/usr/bin/automake'.
おかしいね MSYS2 からだと /proc/registry を見ればレジストリの内容を読めるけど、
レジストリの設定はどうやればいいの？ 上で長々とautomakeについて書いたものですが
最後に念のため全部管理者からにしてインストールから全て自分の知識を一切使わず
ぐぐったやり方に沿ってやりなおしたところやっぱり結果は同じでした
バージョン指定してautomakeを突破してもautom4teのエラーが出たりするので
とりあえず素直に諦めました
変なことは特にしてないと思うんですが…根本的に何かおかしいんでしょうね
一連の書き込み見て、もし何か気が付いた方いましたらよろしくお願いします まずMSYS2とCygwinで同じ状況というので疑われるのは環境の混在
きちんと分離できていれば両方同じ結果にはならないと思う
他のアプリを含めてWindowsのグローバルな環境変数を汚さないようにするかあるいは完全に把握してればこの手の問題は起き難い >>369
もしかしたら何か環境被ってるか影響受けて駄目なのかもしれないですね
両方全く一緒っていうのが…
今度時間空いたらまっさらなOSにでも入れてみようと思います まずは環境変数からCygwinを除去してみるところからだろ
そもそもWindowsの環境変数に混在させるのは良くない
必要な設定はシェルを起動するbatファイルにでも書いて切り分けをはっきりさせた方がいい コンパイラ g++ が-l オプションにてライブラリをサーチしてくれません
cygwin 上でのパス：/usr/loca/lib/libcppunit.a
実パス U:\usr\system\cygwin\usr\local\lib\libcppunit.a
をコンパイルオプション -l で見つけてくれるようにすればどうすればいいでしょうか？ >>373
とりあえずコンパイラの -L オプションで凌ぐことにしました >>374
コメントありがとうございます
それは大丈夫でした >>375
勘違いしている気がするのは気のせいかな
「-l」はリンクするライブラリの「lib」を除いた名称を
指定するためのオプション
そのライブラリを検索する場所を指定するオプションが
「-L」じゃなかったっけ コンパイルオプションとリンクオプションは区別しろよ >>377
はい、-L usr/local/lib -lcppunit とベタ打ちすることにしました cygwin の環境変数を触るのはあきらめました… >>379
LD_LIBRARY_PATH の設定で上手くいかないの？ >>380
それが手元のWindows7環境ではうまくいかないのです… googleとかから資金と技術者が流れこんだかな？ なんとしても__cplusplusを201703にするべく頑張ったんだろうなあ 201402じゃん ・・・と思ったら
-std=c++17で201703になるのか
つーか7.3.0でもそうなるやん >>389
本当？知らなかった
7.3.0で-std=c++1zや-std=gnu++1zを付けてコンパイルしても__cplusplusは201402のままだったのだが俺環？
8.1.0なら-std=c++1zでちゃんと201703になる >>390
俺環
g++ (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 7.3.0
686-7.3.0-release-posix-dwarf-rt_v5-rev0.7z
MD5: d1e009df8d254a15a549c5af2e2200db
SHA1: 96e11c754b379c093e1cb3133f71db5b9f3e0532
OS 名: Microsoft Windows 7 Professional
OS バージョン: 6.1.7601 Service Pack 1 ビルド 7601
プロセッサ: 1 プロセッサインストール済みです。
[01]: x64 Family 6 Model 60 Stepping 3 GenuineIntel ~2601 Mhz MinGWだけど -Wl,--stack でどうしてもスタックサイズが変わらないので悩んでいた
dumpbinとeditbinを使うと変わるし確かめられるんだけど、ようやく方法がわかった
リンカの-Xlinker optionで --stack=<バイトサイズ> と指定すれば変わった
どうも-Wlにバグがあるみたいだな
それとも-Wl,--stack=<バイトサイズ>としないといけないのだろうか
まあリンカの方をいじるのが確実だな 今試してみた
-Wl,--stack=<バイトサイズ> でも駄目でした
結局-Xlinker --stack=<バイトサイズ>で行きます OBJ吐いて結合のときと
OBJ吐かずにコンパイル即EXEのときで違うとか Eclipse CDT使うと通常ではOBJ吐いてから結合だよ
OBJが一つしかなくても >>399
過大な期待を抱かなければ今も昔も便利なものだぞｗ Git For Windows の一部として生き残るでしょ。MinGW >>405
なんでないの?
Git For WindowsのGit Bash便利だよ。 gitの付属物としてのmsys2だとpackmanとか入ってないから面倒 普通、pacmanでMSYS2にGitいんすこするでしょ
Git For Windows の存在意義って何？w >>410
Windowsがパッケージを管理していることがメリットかな…。 windowsのあれはパッケージ管理なのか？アップデートはアプリ任せだが >>413
Git for WindowsもMSYS2もChocolatey経由でinstall&upgradeしている。
Windowsの「アプリと機能」ってパッケージ管理じゃないの? msys2のupgradeは
pacman -Ysu
じゃなくて？ >>410
MSYS2で擬似Linux環境が欲しいとかMinGWで
開発をしたいわけではないけど、最新の
VisualStudioとかAndroidStudioがGitを要求
するんでWindowsでGitだけ使いたいとかっていう
要求はある
Git使いたいわけではなくて、ソースコードに
GitHUBなどから動的にソースを取ってくる
見たいなものも増えているので GPLにしたくないのでclang＋libc++をベースとしたw32api開発環境を構築してみようと思ったけど全然情報ないのな >>417
このスレで言うのもあれだけど、わりとそのまま置き換えて使えるよ
msvc系で使うならターゲットも気にしなくていいし
でもそれならMSからvcのビルドツール落としてそっちのコマンドラインの方を
使った方がいいような気もする >>418
事態が結構複雑で・・・
言語はRust
使いたいライブラリはOpenCV(cmake)、GraphicsMagick(make/VisualMagick)、PDFium(Ninja)
ビルドツールだと最新のsln/vcxprojしかビルドできない(VisualMagickはVC++7のslnしか作れない)
コミュニティを入れればビルドできるだろうがめっちゃでかい
最近はWindowsでも脱msvcの流れっぽいしRustも例外ではない(リンカをlldにしようという話があるらしい)
最終的にはLinuxや*BSDでも使う可能性を考えるとmsvc依存は好ましくない
じゃあMinGWで・・・でもライブラリ類がGPLなのは困る。今更gccというのも
ならLLVM系は・・・clangはビルド済みを落とせるけどlibc++はどうすれば？？？ ←イマココ
以降愚痴。Chromeのコンパイラがmsvcからclangになんて記事が出回っているくらいだし
PDFiumもclangでビルドできるはずだがmsvc(コミュニティ)を使う記事しか見つからん
俺様ビルドシステムの上に情報不足とかマジやめて欲しい 別にMinGWでコンパイルしてもGPLになる訳じゃないしな デバッグにgccを使うだけじゃGPLにはならんな
リリースをvcでやるとか GPL系ライセンスの嫌いなところは業界内で通用する統一された解釈がなくトラブルに発展する可能性が高いこと
類似の事象でも人によって正反対の主張をしているとかザラだし おまえらＧＣＣランタイムライブラリ例外を知らんの？ >>428
プロプライエタリなプログラムと混ぜてはいけないと読めるが自分の解釈は間違っているかな？ GCCランタイムライブラリ例外、GCCランタイムライブラリ例外言っていた人はどこかへ行っちゃったんか？
OS例外というのもあるよね「何を持ってOSか、どこまでがOSか」に対する統一された見解はなくて
人や会社によって差があった気がするけど >>429
GCCのプラグインとしてproprietaryなプログラムを組み合わせると例外の恩恵を受けられない
「GPLと両立しないプラグインなど」を組み込ま「ない」GCCが、proprietaryなソースコードをビルド(*.oの出力、リンク)しても例外は適用される(出力されるものはGPL扱いにならない)
ように読んだ
たぶん「コンパイラの中間表現」はGIMPLEとかRTLみたいなGCC固有の表現を指してて、アセンブリ言語(-Sオプションで出力されるやつ)やオブジェクトコードは指してなさそう スカトロMinGWの方が先に8.2.0出しやがった 待った
このビルドおかしいぞ
g++ -v で --with-arch が i686 じゃなく i586 になってて
#include <thread> は通るのに std::thread がエラーになったり
#include <mutex> は通るのに std::mutex がエラーになるぞ
「このビルド」は、ここ↓で拾ったやつ
https://ja.osdn.net/projects/mingw/releases/p15522 >>434
mingw-getのサプライチェーンを疑ってみれ。 最近 Cygwin も今使ってるやつ居るのか不安になる事が・・
もしかして日本で10人ぐらいの Cygwin ユーザーの一人が俺だったりするんじゃないのか？とか >>437
俺も日本人ユーザーの一人だが、最近はあまり使っていない。
頻繁にパッケージは更新されているから、世界的にユーザーはいるんだろうと思う。 WINDOWSをアンインストールしてUNIXクローンを入れるのが一番幸せになれるよ リーナス君もタネンバウム先生も
作ったのは完全オリジナル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 から実行しても遅いか？ 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版なら行けるのかも？誰か動作報告よろしく。 NTFSのリンクはシンボリックリンクではないでしょ シンボリックリンクあるよ、ジャンクションじゃないやつ >>605
シンボリックリンクはSever2008/Vistaから導入された。もう10年以上前になる。
https://www.atmarkit.co.jp/fwin2k/win2ktips/988symlink/symlink.html
つかお前、このレベルの話を知らないでその言い草は完全に老害化してるぞ。 mklink /? で普通に表示されるのに
それすらやったことないのか？ 共有フォルダ作るときなんか
シンボリックリンクとジャンクションの違いを知らないと困るだろうが >>604
シンボリックリンクもジャンクションも辿れるし、環境変数の設定(CYGWIN=winsymlinks:nativestrict)によってはln -sやtarの展開でNTFSのシンボリックリンクができる
NTFS側でD:とかをリンク先にしても、勝手に/cygdrive/d以下に読み替えてくれる
cygdrive以下だけ動かないなら、/etc/fstabの設定がおかしいとか? だけどシンボリックリンクωを名乗ってるだけでシンボリックリンクではないですねこれ Windowsには
1.ハードリンク
2.ジャンクション
3.あほなシンボリックリンク
4.だるいシンボリックリンク
がある >>611
すまんが、/cygdrive以下だけ動かない、というのは間違いだった。
動作としては、シンボリックリンクを辿ることは出来るが、戻れない、というものだ。
本来はシンボリックリンクはカレントと共に使用される。
つまりD:/dev/debugがシンボリックリンクでそこにD:/devからcdして入ったら、 cd .. だとD:/devに戻って来れないといけない。
（シンボリックリンク先に入った時の元に戻る。他から入ったらそこに当然戻る）
これが出来ておらず、debugしかないディレクトリ（というものを作って渡しているのだと思う）に戻ってしまう。
だから下から上が参照出来ない。上から下は参照出来るし、
下から上でも自分に戻ってくるのなら参照出来る。（言葉だと分かりにくいが要するに以下が通る）
MyMachine@MyName /cygdrive/d/dev/debug
$ less ../debug/some_file
下から上でもファイル名の補完は出来るのでbash自体は動作してる。
なお cd ../.. とシンボリックリンクを跨いで2つ上がることは可能。
cdってbashのコマンドだっけ？だとして、やはりbash自体は動作してる。
bashから各アプリに渡す時に失敗しているか、cygwin1.dll自体が対応してないか、だと思う。
バグ報告してもいいけど、それ以前に64bit環境の動作を確かめてからでないとウザがられる。
というわけで普段から64bit環境で使っている人がいたら試してみてくれ。
>>612
いや完全にシンボリックリンクだよ。
ln -s と使い勝手は同じ。 cygwinはもう永眠させてやれ
WSLに乗っ取られた >>615
何をしようとしているか大体分かった。
・/cygdrive/d/dev/debug はシンボリックリンクで /cygdrive/d/test/debug を指すと仮定
・/cygdrive/d/dev/some_file があると仮定
このとき
・まずcd /cygdrive/d/dev/debugする
・次にcp ../some_file .するとファイルが無いと言われる
ということだと思う。もしそうならそれがUNIX系では普通。LinuxやMacでもそうなる。
これは、cdした時点で既にカレントディレクトリが/cygdrive/d/test/debugに移っているからで、cpは/cygdrive/d/test/some_fileを読もうとしているために起こる。つまり
>本来はシンボリックリンクはカレントと共に使用される。
がUNIX的には正しくない。
実際の挙動としては、
・UNIXの場合、カーネル的にはカレントディレクトリはあくまでもディレクトリで、シンボリックリンクをパスの途中に含むことはできない
・cd ..でもといたディレクトリに戻るのはbashがシンボリックリンクを本当のデイレクトリのようにエミュレーションしているから(set -Pで切れる)
・これは基本的には内部コマンドのcdやpwdに対してのみできることで、外部コマンドのcpやlessに対してはできない(引数の..が親ディレクトリの意味になるかはコマンドに依存するから、シェルが勝手に置き換えられない)
・シェルはPWD環境変数にシンボリックリンクを含むロジカルなカレントディレクトリを出力するので、これを見るようにすれば原理的には外部コマンドもエミユレーションに対応できる(危なっかしいので普通はしない)
WindowsのシンボリックリンクはUNIXと違ってOS自体がシンボリックリンクを含むカレントディレクトリを扱っているようだが、CYGWINはUNIXに合わせていると考えられる。 >>618
こちらの状況は正しく伝わっており、君の言っていることも正しい。
こちらも615を書いた後、遠い昔にシンボリックリンク周りでトラブった記憶があり、
あれはなんだったかな？と思っていたところだった。
つまりbashで上手く誤魔化していてくれているわけだ。
ではtcshは？と確認したが、こちらもsymlinks変数で誤魔化し方を調整出来るようになっている。
https://linuxjm.osdn.jp/html/tcsh/man1/tcsh.1.html
結果、Cygwinとしては仕様通り、UNIXは糞仕様（≒仕様バグ）だな。
突っ込む必要はないと思うが、
> (引数の..が親ディレクトリの意味になるかはコマンドに依存するから、シェルが勝手に置き換えられない)
これはよく分からない。
bashがコマンドに引数を渡すときにあらかじめシンボリックリンク周りを解決していたら、どういう問題が発生する？
というかtcshだとsymlinks=expandに設定したらそうなるらしい。
今回で言えば、
MyMachine@MyName /cygdrive/d/dev/debug
$ cp ../some_file .
を cp /cygdrive/d/dev/somefile /cygdrive/d/dev/debug として実行すれば問題ないはず。
(.を展開する必要はないかもだが）
既存シェルスクリプトの互換性が無くなるだけなら仕様バグでした、残念でした、でしかなく、
後発のwindowsでは修正されているということになる。
シンボリックリンクを辿って、その上の「論理的ではない、物理的上位ディレクトリ」を辿る必要がある使い方なんて無いはず。
なお上記man of tcshのsymlinksの最後の
> > cd ".."; echo $cwd
> /tmp/from
> > /bin/echo ..
> /tmp/to ←これがよく分からん、/tmpではなくて？あるいはコマンドが .. ではなく /bin/echo . なら納得だが
> > /bin/echo ".."
> ..
分かれば出来れば解説よろしく。 WindowsがーではなくCygwinの問題でしょ
WindowsはWindowsの仕様でやってる。それがなんであれ正しい仕様
Cygwinがエミュレート機能をすべて行ってる
問題があるならそれはCygwinの問題
WSLならその問題も解決してるだろうさ >>620
それは違う。
Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
だから仕様としてUnixと同じ動作になる。
詳しくはWikiなり本家なり読めばいい。
問題はUnixの糞仕様が今も修正されずそのままbash等で誤魔化され続け、
windowsでは修正された？為に動作が異なっている事による。
ただこれをCygwinで修正することは出来ないし、するべき事柄でもない。 > Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
ただしい
? だから仕様としてUnixと同じ動作になる。
○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない なんか文字化けする方法のバツを記録してるな。これでいいか？
× だから仕様としてUnixと同じ動作になる。
○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない >>620
なおWSLは理屈上はUnixの動作になるはず。
ただしbash等を見る限り既知の問題だから対策出来そうではあるが、
バイナリ互換なので現実的に無理だと思う。
(もちろんwindows専用bashを用意すればいいが、それだと既存のシェルスクリプトが動かなくなる。
といってもそれで問題が発生するような奴はWSLなんて使わずDockerだと思うが）
が、まあ、俺に関して言えば、
問題の詳細は判明し、特段問題ないから当面はCygwinを使う。
(すまんがNGに当たっているようなのでバラバラにして投稿する） (すまんがNGに当たっているようなのでバラバラにして投稿する）
>>623
> ○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない
違う。そこを目指してない。
CygwinはUnixのシステムコールをcygwin1.dllが受け付けることにより、
GNU等が書き溜めた膨大なUnix向けCソースをそのまま動作させることを目標としている。
結果、ありとあらゆるUnixのツールがcygwin上では動くので、大成功している。 >>623続き
windowsのＣＭＤ。ＥＸＥのエミュレーションなんて必要ないし、目指してもいない。
本家でも読め。
そして認識も間違っている。CygwinはUnixと同じ動作になってる。つまり、「できてる」 >>619
・tcshのmanは間違っているだけだと思う。実際試したら想定通り/tmpになった。
・シェルが勝手に置き換えるべきではないというのは、単にgrep ..とかの動作が今までと変わって直感的でなくなるあたりの問題。.や..の置き換えの仕様とエスケープやクォートの仕様を十分理解すればまあそんなに困らないとは感じる。 >>627
おおサンクス、手元にこなれた環境がないので助かる。
しかし今更このレベルの誤字ってあるかね？
まあtcshなんて今時誰も使ってないが、他のマニュアルもそうなってるし。
https://linux.die.net/man/1/tcsh
とはいえ実行結果がそうなのならそれが一番信憑性があるが。
Unixは今更直せないで行くのだろうけど、WSLの際にMS内部ではどうするか検討してるだろうね。
WSL推しの人はどうぞ動作報告よろしく。 このところ、MSYS2 の pacman を実行するとエラーが出るな
サーバー不調なん？それとも pacman がバグった？
一度アンインストールして最初から入れなおしてもダメやった・・・ いつの間にか直ってた
やっぱり、サーバーが不調なだけだったのか・・・ 回線があまりに遅いと向こうからお断りしてくるのでは 今更
pacmanでfork errorでまくったので見切った。
wslでLinux入れてmingw64クロスコンパイルしている。
wslのコンソールでwindowsバイナリもそのまま動くし良い。
cygwinやmsysみたいにcygwin, msysバイナリとwindowsバイナリが混在することの混乱もないしさらに良い pacmanでfork errorの一番の解決策は
ちゃんと出てきたメッセージを読むこと
これに尽きる
638がそうなのかは知らんが WSLで使うディストリビューション(ArchとかUbuntuとか)によるでしょう
共通して言えるのはLinuxではセキュリティ修正の取り込みは早い WSL は色々なディストリビューションが選べるんですね インストールしようと思ったら、このサイト3年近く更新が止まってる・・・
http://xhmikosr.1f0.de/tools/msys/
今入れるならどうしたらいい？ WSLがある以上、MSYSのメンテはもう廃れるだろうな。
意味ねーし。
cygwinはXのためだけに存在する マジかよシグウィン窓から投げ捨てた
WSL派になります DLLだけで動くのが便利なときもあるが、日々の生活はWSLだね Windows 10, WSL, Ubuntu 18.04 で、
VSCode の拡張機能、Remote WSL も使う
Linux側には、日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv を使って、
ruby 2.6.6, node 12.16.2 を入れた
yarn は、Windows側に入れて、WSL から、拡張子なしのyarn コマンドを呼べる。
これは、#!/bin/sh で始まるシェルスクリプト
anyenv は多言語向きで、rbenv, nodenv, pyenv, phpenv などを同じ使い方で、統一的に扱える。
~/.bashrc に、下の2行を追加するだけで、各言語ごとに追加しないでも良い
export PATH="$HOME/.anyenv/bin:$PATH"
eval "$(anyenv init -)" MSYS+MinGW、仮想マシン+Linuxって感じでWSLの入る余地がない
WSL+MinGWツールチェーンにすれば仮想マシンすら必要ないって考えもあるけど
やっぱり仮想マシンは手放せないからWindows側はMSYSでいいやってなる >>653
MSYS+MinGWで何作ってるの？
Windowsアプリ？
まあWindowsアプリしかないよね。
WSLはLinuxアプリを作って動かすものなので目的が違うよ。 仮想マシンは手放せないけど、仮想マシンはほぼテスト環境になった
作ったアプリを動かすための環境
普段の開発でテストのためだけの環境を使う気にならない
起動重いしメモリ食うし msys+mingw入れて何がしたい？
ffmpegをビルドしたいから ああ、なるほど。テスト環境じゃないから
一つしか仮想マシンがないんだな
それぞれ微妙に異なるからテスト環境（仮想マシン）は
プロジェクトごとに必要なんだよ >>658
LinuxツールのWindowsネイティブ版への移植以外になんかあるの？
ffmpegもそうだし
まあ全員がWSLをインストールしてるとは限らないから
Windowsネイティブ版を作る意味はあるだろうね。 cygwin
mingw
wsl
作ったアプリの動作時オーバーヘッド（動作速度）が大きい順に並べて マジかよWSLに失望しました。窓から投げ捨ててMinGWに乗り換えます >>665
結論ありきの質問だからねｗ
使ってみればわかる。
WSLが一番軽いし一番正確に動く。 mingw-w64-〇〇〇-yasm-1.3.0-4 (は32bit用はi686、64bit用はx86_64)
yasm-1.3.0-2
どう違うの？
入れるのはどっち？ 前者はMinGW-w64のDLLが必要。いわゆるネイティブアプリ
後者はMSYSのDLLと場合によってはターミナルエミュレータが必要
どちらを使うかは環境と用途次第 msys2を入れてpacman -Syuをやった後、home/PC名のフォルダに、.gnupgというフォルダがあるんだけど、これって消しちゃダメ？ え！？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へｌ移行するのもわかる気がする 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が１なのか２なのか知る方法は？ openSUSE Leap 15.1用のmingw配布消えとるやん
くそがー そもそもWSL2はエンスー向けか
普通の人は１が入ってるのか 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（２倍ぐらい遅い）→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 太丸ゴシック体Ｂで、今は誤魔化してます
$ 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はWSｌじゃなくて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って/を「ルート」と読んでしまうから-にしてたんだけど、まさかこれだったとは・・・
㌧x >>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
シュールすぎるんだけどｗ 開発環境が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のような頓珍漢な内容だったんで
端っから破綻している話をおちょくっただけだが文句あんのか？
マニュアルトークばっかりで中身のないハリボテ野郎がｗ >>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を超えると表示できなくなるよ。
