Cygwin + MinGW + GCC 相談室 Part 8

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

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

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

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

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

**デフォルトの名無しさん** · 2019/12/23(月) 12:40:57.34

もちつけ
他人のせいにする前に自分を疑え

**デフォルトの名無しさん** · 2019/12/23(月) 12:45:36.48

自分を疑う自分を疑え

**デフォルトの名無しさん** · 2019/12/23(月) 13:59:53.49

>>602
それはそうだが普段シンボリックリンクである事なんて意識しないからな。
いまだにcygwinではNTFSのシンボリックリンクを辿れないのはしょぼいと思うが。
なお32bit版。bashはversion4.4.12(3)、cygwin1.dll はversion 3001.2.0.0
（昨日の時点でsetup.exeを使いBestに更新）

64bit版なら行けるのかも？誰か動作報告よろしく。

**デフォルトの名無しさん** · 2019/12/23(月) 14:06:09.78

NTFSのリンクはシンボリックリンクではないでしょ

**デフォルトの名無しさん** · 2019/12/23(月) 14:48:39.41

シンボリックリンクあるよ、ジャンクションじゃないやつ

**デフォルトの名無しさん** · 2019/12/23(月) 15:26:21.18

>>605
シンボリックリンクはSever2008/Vistaから導入された。もう10年以上前になる。
https://www.atmarkit.co.jp/fwin2k/win2ktips/988symlink/symlink.html
つかお前、このレベルの話を知らないでその言い草は完全に老害化してるぞ。

**デフォルトの名無しさん** · 2019/12/23(月) 15:39:18.43

mklink /? で普通に表示されるのに
それすらやったことないのか？

**デフォルトの名無しさん** · 2019/12/23(月) 15:40:22.34

共有フォルダ作るときなんか
シンボリックリンクとジャンクションの違いを知らないと困るだろうが

**デフォルトの名無しさん** · 2019/12/23(月) 15:41:13.85

みなさん思いのほか親切ですね

**デフォルトの名無しさん** · 2019/12/23(月) 15:47:56.41

>>604
シンボリックリンクもジャンクションも辿れるし、環境変数の設定(CYGWIN=winsymlinks:nativestrict)によってはln -sやtarの展開でNTFSのシンボリックリンクができる
NTFS側でD:とかをリンク先にしても、勝手に/cygdrive/d以下に読み替えてくれる
cygdrive以下だけ動かないなら、/etc/fstabの設定がおかしいとか?

**デフォルトの名無しさん** · 2019/12/23(月) 15:48:24.03

だけどシンボリックリンクωを名乗ってるだけでシンボリックリンクではないですねこれ

**デフォルトの名無しさん** · 2019/12/23(月) 15:52:08.05

難癖つけたいんなら、具体的に問題を指摘しろや

**デフォルトの名無しさん** · 2019/12/23(月) 15:54:08.35

Windowsには
1.ハードリンク
2.ジャンクション
3.あほなシンボリックリンク
4.だるいシンボリックリンク
がある

**デフォルトの名無しさん** · 2019/12/23(月) 16:12:25.30

>>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 と使い勝手は同じ。

**デフォルトの名無しさん** · 2019/12/23(月) 16:26:38.22

cygwinはもう永眠させてやれ
WSLに乗っ取られた

**デフォルトの名無しさん** · 2019/12/23(月) 18:46:28.73

>>612
黙れ！

**デフォルトの名無しさん** · 2019/12/23(月) 22:27:33.69

>>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に合わせていると考えられる。

**デフォルトの名無しさん** · 2019/12/23(月) 23:39:27.27

>>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 ".."
> ..
分かれば出来れば解説よろしく。

**デフォルトの名無しさん** · 2019/12/23(月) 23:43:56.19

WindowsがーではなくCygwinの問題でしょ
WindowsはWindowsの仕様でやってる。それがなんであれ正しい仕様

Cygwinがエミュレート機能をすべて行ってる
問題があるならそれはCygwinの問題

WSLならその問題も解決してるだろうさ

**デフォルトの名無しさん** · 2019/12/23(月) 23:58:57.35

>>620
それは違う。
Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
だから仕様としてUnixと同じ動作になる。
詳しくはWikiなり本家なり読めばいい。

問題はUnixの糞仕様が今も修正されずそのままbash等で誤魔化され続け、
windowsでは修正された？為に動作が異なっている事による。
ただこれをCygwinで修正することは出来ないし、するべき事柄でもない。

**デフォルトの名無しさん** · 2019/12/24(火) 00:05:26.55

> Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
ただしい

? だから仕様としてUnixと同じ動作になる。
○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない

**デフォルトの名無しさん** · 2019/12/24(火) 00:06:45.59

なんか文字化けする方法のバツを記録してるな。これでいいか？

× だから仕様としてUnixと同じ動作になる。
○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない

**デフォルトの名無しさん** · 2019/12/24(火) 00:22:04.30

>>620
なおWSLは理屈上はUnixの動作になるはず。
ただしbash等を見る限り既知の問題だから対策出来そうではあるが、
バイナリ互換なので現実的に無理だと思う。
(もちろんwindows専用bashを用意すればいいが、それだと既存のシェルスクリプトが動かなくなる。
といってもそれで問題が発生するような奴はWSLなんて使わずDockerだと思うが）

が、まあ、俺に関して言えば、
問題の詳細は判明し、特段問題ないから当面はCygwinを使う。

(すまんがNGに当たっているようなのでバラバラにして投稿する）

**デフォルトの名無しさん** · 2019/12/24(火) 00:23:19.80

(すまんがNGに当たっているようなのでバラバラにして投稿する）

>>623
> ○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない
違う。そこを目指してない。
CygwinはUnixのシステムコールをcygwin1.dllが受け付けることにより、
GNU等が書き溜めた膨大なUnix向けCソースをそのまま動作させることを目標としている。
結果、ありとあらゆるUnixのツールがcygwin上では動くので、大成功している。

**デフォルトの名無しさん** · 2019/12/24(火) 00:24:32.17

>>623続き

windowsのＣＭＤ。ＥＸＥのエミュレーションなんて必要ないし、目指してもいない。
本家でも読め。

そして認識も間違っている。CygwinはUnixと同じ動作になってる。つまり、「できてる」

**デフォルトの名無しさん** · 2019/12/24(火) 00:29:23.48

>>619
・tcshのmanは間違っているだけだと思う。実際試したら想定通り/tmpになった。
・シェルが勝手に置き換えるべきではないというのは、単にgrep ..とかの動作が今までと変わって直感的でなくなるあたりの問題。.や..の置き換えの仕様とエスケープやクォートの仕様を十分理解すればまあそんなに困らないとは感じる。

**デフォルトの名無しさん** · 2019/12/24(火) 00:49:31.91

>>627
おおサンクス、手元にこなれた環境がないので助かる。
しかし今更このレベルの誤字ってあるかね？
まあtcshなんて今時誰も使ってないが、他のマニュアルもそうなってるし。
https://linux.die.net/man/1/tcsh
とはいえ実行結果がそうなのならそれが一番信憑性があるが。

Unixは今更直せないで行くのだろうけど、WSLの際にMS内部ではどうするか検討してるだろうね。
WSL推しの人はどうぞ動作報告よろしく。

**デフォルトの名無しさん** · 2019/12/24(火) 15:52:35.51

WSLの話題はこちらへどうぞ https://mao.5ch.net/test/read.cgi/linux/1560665525/

cygwinの話題は引き続きこのスレでどうぞ

**デフォルトの名無しさん** · 2020/01/05(日) 00:06:31.37

>>627
ばーーーか

**627** · 2020/02/21(金) 14:13:26.80

>>630
ごめんなさい。

**デフォルトの名無しさん** · 2020/03/07(土) 09:24:50.59

このところ、MSYS2 の pacman を実行するとエラーが出るな
サーバー不調なん？それとも pacman がバグった？
一度アンインストールして最初から入れなおしてもダメやった・・・

**デフォルトの名無しさん** · 2020/03/11(水) 21:27:12.49

いつの間にか直ってた
やっぱり、サーバーが不調なだけだったのか・・・

**デフォルトの名無しさん** · 2020/03/12(木) 11:58:54.03

自分の回線を疑う気は皆無か

**デフォルトの名無しさん** · 2020/03/12(木) 19:21:51.59

自分の回線だけだったら書き込まないが・・・

**デフォルトの名無しさん** · 2020/03/25(水) 09:30:19.85

回線があまりに遅いと向こうからお断りしてくるのでは

**デフォルトの名無しさん** · 2020/03/28(土) 13:48:39.21

サーバー不調なだけだぞ、公式でも話題になってた
https://github.com/msys2/MINGW-packages/issues/6256

**デフォルトの名無しさん** · 2020/04/02(木) 18:00:43.50

今更
pacmanでfork errorでまくったので見切った。
wslでLinux入れてmingw64クロスコンパイルしている。
wslのコンソールでwindowsバイナリもそのまま動くし良い。
cygwinやmsysみたいにcygwin, msysバイナリとwindowsバイナリが混在することの混乱もないしさらに良い

**デフォルトの名無しさん** · 2020/04/03(金) 04:00:25.48

GCC 9.3を早く出してくれ

**デフォルトの名無しさん** · 2020/04/03(金) 09:51:54.29

pacmanでfork errorの一番の解決策は
ちゃんと出てきたメッセージを読むこと
これに尽きる
638がそうなのかは知らんが

**デフォルトの名無しさん** · 2020/04/05(日) 22:38:22.52

WSLよりMSYS2の方が更新早い？

**デフォルトの名無しさん** · 2020/04/06(月) 09:55:13.35

WSLで使うディストリビューション(ArchとかUbuntuとか)によるでしょう
共通して言えるのはLinuxではセキュリティ修正の取り込みは早い

**デフォルトの名無しさん** · 2020/04/06(月) 20:27:42.43

WSL は色々なディストリビューションが選べるんですね

**デフォルトの名無しさん** · 2020/04/19(日) 17:57:31.18

インストールしようと思ったら、このサイト3年近く更新が止まってる・・・
http://xhmikosr.1f0.de/tools/msys/

今入れるならどうしたらいい？

**デフォルトの名無しさん** · 2020/04/19(日) 22:00:29.69

WSLがある以上、MSYSのメンテはもう廃れるだろうな。
意味ねーし。
cygwinはXのためだけに存在する

**デフォルトの名無しさん** · 2020/04/19(日) 23:35:15.05

>>645
えっ、そんなのあるの？

**デフォルトの名無しさん** · 2020/04/20(月) 01:29:10.82

そ、そんな～(´・ω・｀)

**デフォルトの名無しさん** · 2020/04/20(月) 04:16:21.28

更新が止まってしまった

**デフォルトの名無しさん** · 2020/04/20(月) 04:41:27.35

>>645
cygwinは便利だ。

**デフォルトの名無しさん** · 2020/04/20(月) 07:25:19.48

マジかよシグウィン窓から投げ捨てた
WSL派になります

**デフォルトの名無しさん** · 2020/04/20(月) 08:37:44.26

DLLだけで動くのが便利なときもあるが、日々の生活はWSLだね

**デフォルトの名無しさん** · 2020/04/20(月) 09:12:16.95

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 -)"

**デフォルトの名無しさん** · 2020/04/20(月) 09:13:30.71

MSYS+MinGW、仮想マシン+Linuxって感じでWSLの入る余地がない
WSL+MinGWツールチェーンにすれば仮想マシンすら必要ないって考えもあるけど
やっぱり仮想マシンは手放せないからWindows側はMSYSでいいやってなる

**デフォルトの名無しさん** · 2020/04/20(月) 10:24:18.82

>>653
同じく

**デフォルトの名無しさん** · 2020/04/20(月) 13:58:21.58

>>653
MSYS+MinGWで何作ってるの？
Windowsアプリ？

まあWindowsアプリしかないよね。
WSLはLinuxアプリを作って動かすものなので目的が違うよ。

**デフォルトの名無しさん** · 2020/04/20(月) 14:00:46.58

仮想マシンは手放せないけど、仮想マシンはほぼテスト環境になった
作ったアプリを動かすための環境

普段の開発でテストのためだけの環境を使う気にならない
起動重いしメモリ食うし

**デフォルトの名無しさん** · 2020/04/20(月) 14:10:17.96

起動したままで良い
メモリ喰うのは諦めろ

**デフォルトの名無しさん** · 2020/04/20(月) 14:16:53.62

msys+mingw入れて何がしたい？
ffmpegをビルドしたいから

**デフォルトの名無しさん** · 2020/04/20(月) 14:17:05.96

ああ、なるほど。テスト環境じゃないから
一つしか仮想マシンがないんだな

それぞれ微妙に異なるからテスト環境（仮想マシン）は
プロジェクトごとに必要なんだよ

**デフォルトの名無しさん** · 2020/04/20(月) 14:18:38.31

>>658
LinuxツールのWindowsネイティブ版への移植以外になんかあるの？
ffmpegもそうだし

まあ全員がWSLをインストールしてるとは限らないから
Windowsネイティブ版を作る意味はあるだろうね。

**デフォルトの名無しさん** · 2020/04/20(月) 17:04:12.19

だから何としか言えねぇ

**デフォルトの名無しさん** · 2020/04/20(月) 21:50:47.06

cygwin
mingw
wsl

作ったアプリの動作時オーバーヘッド（動作速度）が大きい順に並べて

**デフォルトの名無しさん** · 2020/04/20(月) 21:54:06.18

c
w
m

**デフォルトの名無しさん** · 2020/04/20(月) 21:57:01.49

マジかよWSLに失望しました。窓から投げ捨ててMinGWに乗り換えます

**デフォルトの名無しさん** · 2020/04/20(月) 23:38:08.46

いやいや君なんでも即断すぎやろw

**デフォルトの名無しさん** · 2020/04/21(火) 05:17:44.95

>>665
結論ありきの質問だからねｗ

使ってみればわかる。
WSLが一番軽いし一番正確に動く。

**デフォルトの名無しさん** · 2020/04/22(水) 00:52:15.00

mingw-w64-〇〇〇-yasm-1.3.0-4 (は32bit用はi686、64bit用はx86_64)
yasm-1.3.0-2

どう違うの？
入れるのはどっち？

**デフォルトの名無しさん** · 2020/04/22(水) 09:41:29.70

前者はMinGW-w64のDLLが必要。いわゆるネイティブアプリ
後者はMSYSのDLLと場合によってはターミナルエミュレータが必要
どちらを使うかは環境と用途次第

**デフォルトの名無しさん** · 2020/04/22(水) 09:46:40.84

おま環

**デフォルトの名無しさん** · 2020/04/23(木) 21:18:54.36

msys2を入れてpacman -Syuをやった後、home/PC名のフォルダに、.gnupgというフォルダがあるんだけど、これって消しちゃダメ？

**デフォルトの名無しさん** · 2020/04/26(日) 14:07:46.35

え！？WSLってそのままでは音流せないんですか！？

**デフォルトの名無しさん** · 2020/04/26(日) 15:10:53.48

gnupgってGPGだろ
GNU製のPGP暗号化と復号プログラム

**デフォルトの名無しさん** · 2020/04/26(日) 16:13:34.86

>>671
PulseAudio使えばいいだけじゃね？

**デフォルトの名無しさん** · 2020/04/27(月) 04:32:34.19

ではWSLは、デフォルトでは音すら流せない杜撰な造りをしていると認めるんですか？

**デフォルトの名無しさん** · 2020/04/27(月) 06:42:04.21

単にサウンドデバイスを実装してないだけだよ
設計は良く出来てるので実装しようと思えば出来るだろうが
利用者が求めてない機能なので優先度が低い
WSLの利用者は開発者だからね。開発者が欲しい機能が最優先

**デフォルトの名無しさん** · 2020/04/27(月) 06:46:16.14

あ、もしWSLが開発者向けの機能を優先してるのを知った上で
WSLは駄目だって印象を与えようとした書き込みだったらごめん、邪魔したね
そうでないなら音ならWindowsで鳴らせばいいと気づければOKだよ
音を鳴らす程度のためにWSLは不要だからね

**デフォルトの名無しさん** · 2020/04/27(月) 17:16:43.92

>>653
wslはwslのコマンドラインからlinuxバイナリもwindowsバイナリも動く優れものなんだよ

**デフォルトの名無しさん** · 2020/04/27(月) 18:06:23.13

>>677
そうそう。だからbashのシェルスクリプトで
Windowsのコマンドを実行してOSの設定を変更するとかできちゃう

**デフォルトの名無しさん** · 2020/04/27(月) 19:44:31.43

Windowsのコマンドプロンプト側からWSLのディレクトリに入っていけるの？

**デフォルトの名無しさん** · 2020/04/27(月) 19:55:00.34

>>679
それはコマンドプロンプト自体の問題で、こいつは古いアプリなのでUNCパスに対応していない
UNCパス（\\ではじまるネットワークフォルダのパス）を扱えるツールを使う必要がある
WSLのディレクトリに対応してるかというよりも
ネットワークフォルダに対応しているかという話に近い

PowerShellはUNCパスに対応しているからWSLのディレクトリにも入れる
コマンドプロンプトから実行するコマンドもUNCパスに対応していれば参照できる
またネットワークフォルダはドライブに割り当てることが出来るので
ドライブに割り当てればコマンドコマンドからWSLのディレクトリに入ることも出来る

**デフォルトの名無しさん** · 2020/04/27(月) 19:56:20.68

ちなみにcdの代わりにpushdを使えば
コマンドコマンドからUNCパスに移動できる
一時的にドライブを割り当てているだけだが

**デフォルトの名無しさん** · 2020/04/27(月) 22:41:42.75

詳しい情報サンクス！
これなら皆がWSLへｌ移行するのもわかる気がする

**デフォルトの名無しさん** · 2020/04/27(月) 23:26:27.00

windowsのSSHサーバ立ち上げてwslをシェルにできるのは便利
PowerShell極めてるひとなら不要かもしれんけどね

**デフォルトの名無しさん** · 2020/04/28(火) 10:33:28.83

MSYS2とWSLって共存出来るんですか？

**デフォルトの名無しさん** · 2020/04/28(火) 10:52:09.80

マジレスするとmsys使ってて問題無ければwsl要らない

**デフォルトの名無しさん** · 2020/04/28(火) 17:09:56.15

>>684
共存できる。msys2はただのアプリでしかないから

>>685
msysの問題はUbuntuと同じようなメンテナンス力を期待できないところかな
WSLは本物のUbuntuのディストリのパッケージが使われてるので
Ubuntuとほぼ同等にメンテナンスされてると思っていい

だけどmsysは（Ubuntuと比べたら小さな）開発者が対応してるパッケージしか使えない
しかもLinuxと完全互換じゃないからmsysでソースコードからコンパイルしようとしても
動くとは限らない。WSLを使えばそういった煩わしさから開放される。

msysはWSLを入れてない人のためのWindows用アプリを作るためのものだよ
開発者がLinuxの代わりとして使うものじゃない

**デフォルトの名無しさん** · 2020/04/28(火) 17:14:36.86

ホームパスを一緒にすると色々弊害出そう

**デフォルトの名無しさん** · 2020/04/28(火) 17:30:05.30

>>687
シンボリックリンクでホームディレクトリ以下から
アクセスしやすくするのがおすすめ
色々と混ざらないし複数のディストリでも共有できる

**デフォルトの名無しさん** · 2020/04/28(火) 18:17:52.10

色々と混ぜたいからホームディレクトリを一緒にするんだろ
そうじゃなければ最初から分けとけばいいだけの話だ

**デフォルトの名無しさん** · 2020/04/28(火) 18:20:54.27

>>689
「色々」と混ぜたいならその「色々」だめを混ぜればいいじゃん
全部混ぜる必要はない

**デフォルトの名無しさん** · 2020/04/28(火) 18:21:10.90

「色々」と混ぜたいならその「色々」だけを混ぜればいいじゃん

**デフォルトの名無しさん** · 2020/04/29(水) 09:35:11.34

混ぜるな危険

**デフォルトの名無しさん** · 2020/04/29(水) 09:46:08.06

Microsoft Store に　WSL Ubuntu 20.04 LTS　出てるけど、まだ入れない方がいいんですか

**デフォルトの名無しさん** · 2020/04/29(水) 10:27:50.31

早くても、8月以降に、20.04.1 とか修正版が出た後。
1年後でも良い

Ruby のirb では、MSYS2/MinGW で、日本語入力でバグるから、
WSL の方が、互換性が高い

日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv で、
色々なバージョンも入れられる

VSCode も、Remote WSL 拡張機能で、Linux 側へアクセスできる

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

>>679
コマンドプロンプト・PowerShell で、wsl と入力すれば、WSLが起動する

最も良いのは、Linux 側のフォルダのショートカットをデスクトップにでも作って、
そのフォルダの右クリックメニューから、VSCode を起動する

これで、WSLを起動して、Linux側のプロジェクトを開ける

**デフォルトの名無しさん** · 2020/04/29(水) 11:51:03.18

wsl, opensuse leapにmingw64入れてクロスビルドしてる。
configure作って--hostでmingw指定すれば楽勝すぎて屁が出そう

**デフォルトの名無しさん** · 2020/04/29(水) 11:51:38.68

自分が使っているWSLが１なのか２なのか知る方法は？

**デフォルトの名無しさん** · 2020/04/30(木) 13:35:41.83

openSUSE Leap 15.1用のmingw配布消えとるやん
くそがー

**デフォルトの名無しさん** · 2020/04/30(木) 17:32:57.91

そもそもWSL2はエンスー向けか
普通の人は１が入ってるのか

**デフォルトの名無しさん** · 2020/05/02(土) 23:21:47.63

MinGWっていうかGitBash環境なんだけど
WSL1より2倍ぐらいシェルスクリプトが遅いんだよね
どこが原因かわからんけどこんなもん？
なにか大きな差がでるポイントでもあるんかね？

**デフォルトの名無しさん** · 2020/05/03(日) 03:37:53.54

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倍の差がでてるから
もうこれはどうしようもないのか？

**デフォルトの名無しさん** · 2020/05/03(日) 04:04:18.44

比較とか計算が遅いのかと思ってやってみたけど
この比率は変わらない

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の処理だけなはずなんだけどなぁ