Cygwin + MinGW + GCC 相談室 Part 8
>>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のCMD。EXEのエミュレーションなんて必要ないし、目指してもいない。 本家でも読め。 そして認識も間違っている。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 結論ありきの質問だからねw 使ってみればわかる。 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へl移行するのもわかる気がする windowsのSSHサーバ立ち上げてwslをシェルにできるのは便利 PowerShell極めてるひとなら不要かもしれんけどね マジレスするとmsys使ってて問題無ければwsl要らない >>684 共存できる。msys2はただのアプリでしかないから >>685 msysの問題はUbuntuと同じようなメンテナンス力を期待できないところかな WSLは本物のUbuntuのディストリのパッケージが使われてるので Ubuntuとほぼ同等にメンテナンスされてると思っていい だけどmsysは(Ubuntuと比べたら小さな)開発者が対応してるパッケージしか使えない しかもLinuxと完全互換じゃないからmsysでソースコードからコンパイルしようとしても 動くとは限らない。WSLを使えばそういった煩わしさから開放される。 msysはWSLを入れてない人のためのWindows用アプリを作るためのものだよ 開発者がLinuxの代わりとして使うものじゃない >>687 シンボリックリンクでホームディレクトリ以下から アクセスしやすくするのがおすすめ 色々と混ざらないし複数のディストリでも共有できる 色々と混ぜたいからホームディレクトリを一緒にするんだろ そうじゃなければ最初から分けとけばいいだけの話だ >>689 「色々」と混ぜたいならその「色々」だめを混ぜればいいじゃん 全部混ぜる必要はない 「色々」と混ぜたいならその「色々」だけを混ぜればいいじゃん Microsoft Store に WSL Ubuntu 20.04 LTS 出てるけど、まだ入れない方がいいんですか 早くても、8月以降に、20.04.1 とか修正版が出た後。 1年後でも良い Ruby のirb では、MSYS2/MinGW で、日本語入力でバグるから、 WSL の方が、互換性が高い 日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv で、 色々なバージョンも入れられる VSCode も、Remote WSL 拡張機能で、Linux 側へアクセスできる >>679 コマンドプロンプト・PowerShell で、wsl と入力すれば、WSLが起動する 最も良いのは、Linux 側のフォルダのショートカットをデスクトップにでも作って、 そのフォルダの右クリックメニューから、VSCode を起動する これで、WSLを起動して、Linux側のプロジェクトを開ける wsl, opensuse leapにmingw64入れてクロスビルドしてる。 configure作って--hostでmingw指定すれば楽勝すぎて屁が出そう 自分が使っているWSLが1なのか2なのか知る方法は? openSUSE Leap 15.1用のmingw配布消えとるやん くそがー そもそもWSL2はエンスー向けか 普通の人は1が入ってるのか MinGWっていうかGitBash環境なんだけど WSL1より2倍ぐらいシェルスクリプトが遅いんだよね どこが原因かわからんけどこんなもん? なにか大きな差がでるポイントでもあるんかね? WSL1 (bash 4.4.20) だと $ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done' real 0m6.317s user 0m6.313s sys 0m0.000s MinGW64 (bash 4.4.23) だと $ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done' real 0m15.053s user 0m15.000s sys 0m0.030s Cygwin (bash 4.4.12) だと $ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done' real 0m13.897s user 0m13.858s sys 0m0.046s うーん、こんな単純なコードで2倍の差がでてるから もうこれはどうしようもないのか? 比較とか計算が遅いのかと思ってやってみたけど この比率は変わらない WSL1 $ time bash -c 'for i in $(seq 1000000); do :; done' real 0m2.159s user 0m1.828s sys 0m0.359s Cygwin $ time bash -c 'for i in $(seq 1000000); do :; done' real 0m4.222s user 0m3.889s sys 0m0.341s MinGW64 $ time bash -c 'for i in $(seq 1000000); do :; done' real 0m4.821s user 0m4.342s sys 0m0.436s WSL1 → Cygwin(2倍ぐらい遅い)→MinGW(さらに10%遅い) こんな傾向がある。ファイルシステムは関係ないはず やってるのはCPUの処理だけなはずなんだけどなぁ 調べるとradeonのドライバを切れとか書いてあるけど… radeonの話は画面に出力が絡むなら 関係ありそうな気もするけど、それ以外でも発生するんだろうかね あとHOMEは MinGWは /c/Users/myname Cygwinは/home/mynameだ よく見ると大きな差があるのはuser空間だから コンパイルオプションが違ってるとかなのかな? seq使うんじゃなくて{1..1000000}の方がいいかもね >>707 つってもわずか一回だからなぁ。やってみてもいいけど WSL1 $ time bash -c 'for i in {1..1000000}; do :; done' real 0m1.710s user 0m1.547s sys 0m0.156s Cygwin $ time bash -c 'for i in {1..1000000}; do :; done' real 0m4.854s user 0m4.811s sys 0m0.108s MinGW64 $ time bash -c 'for i in {1..1000000}; do :; done' real 0m4.934s user 0m4.843s sys 0m0.109s あとあれから少しわかったのはMinGWは何回か繰り返せば Cygwinに迫るのでファイル読み込み?とかも少し関連してるんだと思う が2倍以上かかることに変わりはない cygwin.dll?とかが遅いのかもな。MinGWでも使ってるんじゃなかったっけ? >>708 を、WSL1, Ubuntu 18.04 で、3回やった。 8GB メモリ、CPU-i3・エコモード real 0m4.680s user 0m4.234s sys 0m0.453s ちなみに俺のはCPUはi7な Cygwin、MinGWを実行したら それの2倍かかるはず cygwinはforkがヘボいから遅い MinGWといいつつmsysのbashやろ これもforkがcygwinゆずりだから遅い。 wslもfork遅いと思うけど。 virtual boxにwindowsファイルを共有させたものの方が実は速い。 純粋にwindowsとLinuxの環境を同居させたきゃ仮想PC Linuxでwindows binaryをクロスビルド、テストまでしたけりゃwsl まあ名前解決のところと passwd/group の設定はしといた方がいいね >>712 forkが遅いのはわかってるけど、 このコードでforkなんて大量にはしないだろ? time bash -c 'for i in {1..1000000}; do :; done' read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる