FreeBSD(*BSD)/LinuxなどのUnix系OSで，クライアント環境を
構築するためには，Office系ソフトウェア，Desktop環境，
などの整備が重要になってくるはずだ．
そのための手段は問わない．またまた熱く語ってくれ．
FreeBSD での Office 環境を語れ!
https://pc5.5ch.net/test/read.cgi/unix/1094394684/
FreeBSD での Office 環境を語れ! その2
https://mevius.5ch.net/test/read.cgi/unix/1107211157/
探検
BSD/LinuxでのOffice/Desktop環境を語れ！ Part03
1名無しさん＠お腹いっぱい。
2021/10/06(水) 20:57:41.76117115
2022/04/25(月) 20:07:21.24 >>116
確かに動いた あっさりと
https://i.imgur.com/uWiXdbE.jpg
それも i386-wine-devel で使ってたやつがそのまんま
wime氏、116氏、ありがとう そのうち私も何らかの成果があればご報告差し上げます
確かに動いた あっさりと
https://i.imgur.com/uWiXdbE.jpg
それも i386-wine-devel で使ってたやつがそのまんま
wime氏、116氏、ありがとう そのうち私も何らかの成果があればご報告差し上げます
2022/04/26(火) 11:52:14.78
wineは使わないけどV2Cだって13-stableで動くよ。
自分はV2C-Rを使ってて最近V2C/2に移行した。
自分はV2C-Rを使ってて最近V2C/2に移行した。
2022/04/26(火) 12:05:21.06
これ？確かディスコンになったパッケージを使うやつ
https://mevius.5ch.net/test/read.cgi/unix/1632283136/79
https://mevius.5ch.net/test/read.cgi/unix/1632283136/79
2022/04/26(火) 12:47:16.31
そうそれ。
JAILで古いportsをビルドしてパッケージだけメイン環境に突っ込んだ。
スクリプトエンジンが変わってて動かんから古いエンジンを突っ込む必要があったり
ちょっと手間だったけどV2C/2が快適に動いててこの書き込みしてる。
JAILで古いportsをビルドしてパッケージだけメイン環境に突っ込んだ。
スクリプトエンジンが変わってて動かんから古いエンジンを突っ込む必要があったり
ちょっと手間だったけどV2C/2が快適に動いててこの書き込みしてる。
2022/04/28(木) 10:11:27.28
>>74
これをベースにした合成フォントがportsに来たみたいですよ
FreshPorts -- japanese/font-udev-gothic: UDEV Gothic
https://www.freshports.org/japanese/font-udev-gothic/
これをベースにした合成フォントがportsに来たみたいですよ
FreshPorts -- japanese/font-udev-gothic: UDEV Gothic
https://www.freshports.org/japanese/font-udev-gothic/
123FreeBSDでwimeを使っている君
2022/04/28(木) 20:24:05.14 >>122
おおっ！ Portsに来たぁぁ！
２つあるのか。明朝はないのね。
ん？ 「Nerd Fonts」。「オタク文字」？ って何だ？
FreshPorts -- japanese/font-udev-gothic: UDEV Gothic
https://www.freshports.org/japanese/font-udev-gothic/
FreshPorts -- japanese/font-udev-gothic-nf: UDEV Gothic (Nerd Fonts)
https://www.freshports.org/japanese/font-udev-gothic-nf/
おおっ！ Portsに来たぁぁ！
２つあるのか。明朝はないのね。
ん？ 「Nerd Fonts」。「オタク文字」？ って何だ？
FreshPorts -- japanese/font-udev-gothic: UDEV Gothic
https://www.freshports.org/japanese/font-udev-gothic/
FreshPorts -- japanese/font-udev-gothic-nf: UDEV Gothic (Nerd Fonts)
https://www.freshports.org/japanese/font-udev-gothic-nf/
2022/04/28(木) 20:52:12.95
>>123
上流リポジトリ
https://github.com/yuru7/udev-gothic
HackGenの作者さんの様でテキストエディタや端末エミュレータ用の等幅フォントですね
ナードフォントというやつは絵文字グリフが充実したフォントらしいです
上流リポジトリ
https://github.com/yuru7/udev-gothic
HackGenの作者さんの様でテキストエディタや端末エミュレータ用の等幅フォントですね
ナードフォントというやつは絵文字グリフが充実したフォントらしいです
2022/04/29(金) 03:45:46.68
>>113
この方妙に入力システムにこだわりがあるらしいんですけどどう思いますか？
https://mevius.5ch.net/test/read.cgi/win/1648180114/681
https://mevius.5ch.net/test/read.cgi/win/1648180114/683
この方妙に入力システムにこだわりがあるらしいんですけどどう思いますか？
https://mevius.5ch.net/test/read.cgi/win/1648180114/681
https://mevius.5ch.net/test/read.cgi/win/1648180114/683
2022/04/29(金) 22:19:21.18
>>124
わざわざレスすいません。
モリサワの「BIZ UD」フォントからのPorts化なのでなく、
「yuru7」氏の二次的成果物（BIZ UD+JetBrains Mono）からの
Ports化なんですね。
わざわざレスすいません。
モリサワの「BIZ UD」フォントからのPorts化なのでなく、
「yuru7」氏の二次的成果物（BIZ UD+JetBrains Mono）からの
Ports化なんですね。
2022/04/29(金) 22:23:29.31
>>125
と、言われても……、なあ。
連日の長レスの後の短レスの投稿数の多さが恐いと思います。
Windowsは、「データを持って行って」ぐらいでしか
使ったことがないので、理解できませんでした。
今でこそ、Windowsが対応しておかないといけないキーボードは、
日本語か、英語か、ぐらいの選択ですが、昔は、Windowsが対応して
おくべきキーボードがたくさんありました。
101/104英語、106/109日本語、PC9801系、AX、J3100（ATコネクタ）、
FM-TOWNS、親指シフト（最近まで現役だったみたい）、かなあ。
Controlキーが、左にしかない場合もあるし、Windowsさんには歴史が
あるんだから、ぐちゃぐちゃとは言えないよね。
大昔（MS-DOS時代の話かもしれない）に読んだ、ATOKのバグ出し
チーム（だったかな？）の記事。
バグ出しチームは、標準のキー割り当てで変換し（当たり前ですが）、
しかも、変換結果の漢字が何番目に出るかも記憶しているため、
即、変換結果を選ぶことができ、漢字変換が正確で速いのは良いが、
学習機能を使わない状態（無意識に学習機能を使わないようにしていた）
だったため、学習機能の向上の役に立たない、ということに気づいた、
という話。
と、言われても……、なあ。
連日の長レスの後の短レスの投稿数の多さが恐いと思います。
Windowsは、「データを持って行って」ぐらいでしか
使ったことがないので、理解できませんでした。
今でこそ、Windowsが対応しておかないといけないキーボードは、
日本語か、英語か、ぐらいの選択ですが、昔は、Windowsが対応して
おくべきキーボードがたくさんありました。
101/104英語、106/109日本語、PC9801系、AX、J3100（ATコネクタ）、
FM-TOWNS、親指シフト（最近まで現役だったみたい）、かなあ。
Controlキーが、左にしかない場合もあるし、Windowsさんには歴史が
あるんだから、ぐちゃぐちゃとは言えないよね。
大昔（MS-DOS時代の話かもしれない）に読んだ、ATOKのバグ出し
チーム（だったかな？）の記事。
バグ出しチームは、標準のキー割り当てで変換し（当たり前ですが）、
しかも、変換結果の漢字が何番目に出るかも記憶しているため、
即、変換結果を選ぶことができ、漢字変換が正確で速いのは良いが、
学習機能を使わない状態（無意識に学習機能を使わないようにしていた）
だったため、学習機能の向上の役に立たない、ということに気づいた、
という話。
128FreeBSDでwimeを使っている君
2022/04/29(金) 22:28:44.94 >>113 の件について追加。
FreeBSD13.0R/amd64＋Wine(i386-wine-devel-6.12)＋
wime4.1.4＋ATOK17(2004)＋emacs-canna-27.2 の
環境下において。
emacs-canna標準の、canna.el使用時の、漢字変換時に、
ごくまれに、WindowsなATOKの変換候補のGUI表示がされる。
もちろん、そのGUI表示で変換候補を選ぶことはできず、
単に描画されるだけです。
この描画は勝手に消えてくれないので、ATOKのプロパティを
表示（wimectrl -s）させて、プロパティをキャンセルすると、
ATOKのプロパティの描画と一緒に消えてくれます。
ただ、「たまになる」だけで確実に再現させることができません。
「標準のEmacs＋yc.el」の時も、ごくごくまれになっていたと
記憶するのですが、条件を思い出せません。
実害はないのですが、一応、そういう現象がある、という事で。
それと、繰り返しになりますが、「標準のEmacs＋yc.el」より
「emacs-canna」の方が、軽いように感じます。
「Emacs LispでCanna」と、バイナリで対応の「emacs-canna」なら、
当然かもしれません。
もう「標準のEmacs＋yc.el」には戻れません。
FreeBSD13.0R/amd64＋Wine(i386-wine-devel-6.12)＋
wime4.1.4＋ATOK17(2004)＋emacs-canna-27.2 の
環境下において。
emacs-canna標準の、canna.el使用時の、漢字変換時に、
ごくまれに、WindowsなATOKの変換候補のGUI表示がされる。
もちろん、そのGUI表示で変換候補を選ぶことはできず、
単に描画されるだけです。
この描画は勝手に消えてくれないので、ATOKのプロパティを
表示（wimectrl -s）させて、プロパティをキャンセルすると、
ATOKのプロパティの描画と一緒に消えてくれます。
ただ、「たまになる」だけで確実に再現させることができません。
「標準のEmacs＋yc.el」の時も、ごくごくまれになっていたと
記憶するのですが、条件を思い出せません。
実害はないのですが、一応、そういう現象がある、という事で。
それと、繰り返しになりますが、「標準のEmacs＋yc.el」より
「emacs-canna」の方が、軽いように感じます。
「Emacs LispでCanna」と、バイナリで対応の「emacs-canna」なら、
当然かもしれません。
もう「標準のEmacs＋yc.el」には戻れません。
2022/04/30(土) 16:58:54.71
2022/05/01(日) 02:28:56.20
>>127
もしご本人が読んだらどんな反応があるか目に浮かぶ様なご回答ですな
もしご本人が読んだらどんな反応があるか目に浮かぶ様なご回答ですな
2022/05/01(日) 22:57:53.03
>>130
恐いのは恐いんですが、悪口ではないんですよ。
ただ、キー割り当てやソフトウェアの挙動には、人間側として
不満があったとしても、よかれと思って考えられた設計思想や、
俗に語られる、タイプライターの配列の話などの、
いまさら変えられない歴史があるし、あえて、人間側が標準状態に
合わせるのも考え方として「ある」という話です。
ATOKのバグ出しチームの話も、「へえ、変換学習をさせなければ
変換先の順番が変わらないのだから、変換作業が速くなるね」と
感心したので、憶えていたのだと思います。
ATOKのスレで、ATOKの新規インストールをしたので、
「これから（自分流の入力をして）辞書を鍛える」というレスが
並んでいた中に、「短文でなく、長文で変換をしたら、文脈に
応じた変換結果になりやすいのに」というレスを見てからは、
執筆者も、文脈を読み取りやすい長さのタイミングで
変換するようになりました。そのレスには感謝しています。
恐いのは恐いんですが、悪口ではないんですよ。
ただ、キー割り当てやソフトウェアの挙動には、人間側として
不満があったとしても、よかれと思って考えられた設計思想や、
俗に語られる、タイプライターの配列の話などの、
いまさら変えられない歴史があるし、あえて、人間側が標準状態に
合わせるのも考え方として「ある」という話です。
ATOKのバグ出しチームの話も、「へえ、変換学習をさせなければ
変換先の順番が変わらないのだから、変換作業が速くなるね」と
感心したので、憶えていたのだと思います。
ATOKのスレで、ATOKの新規インストールをしたので、
「これから（自分流の入力をして）辞書を鍛える」というレスが
並んでいた中に、「短文でなく、長文で変換をしたら、文脈に
応じた変換結果になりやすいのに」というレスを見てからは、
執筆者も、文脈を読み取りやすい長さのタイミングで
変換するようになりました。そのレスには感謝しています。
2022/05/01(日) 23:00:08.42
そのスレで言及があった「窓使いの憂鬱」は知っていましたが、
共同使用のPCには入れられないし（共同使用相手がUnix系とは
限らない）、「窓使いの憂鬱」を入れられる環境なら、
Emacsな人なら、xyzzyを入れて「メモ帳」代わりに使っても
よいだろうし、Windowsのダイアログ入力のコピペなどの
すべてまでも、を、Unixっぽくするのも、どうなのか、
Windowsにおいて、「絶対にマウスを使たくないでござる」は、
難しいだろうな、人間には慣れる能力もあるのに、と、
思ったことがあります。
『UNIXという考え方−その設計思想と哲学』を読んで、
マウス操作もアリ（操作は、なるべく楽をしろ）なのだな、と、
考えを改めた執筆者君でしたー（きょうのわんこ風）。
共同使用のPCには入れられないし（共同使用相手がUnix系とは
限らない）、「窓使いの憂鬱」を入れられる環境なら、
Emacsな人なら、xyzzyを入れて「メモ帳」代わりに使っても
よいだろうし、Windowsのダイアログ入力のコピペなどの
すべてまでも、を、Unixっぽくするのも、どうなのか、
Windowsにおいて、「絶対にマウスを使たくないでござる」は、
難しいだろうな、人間には慣れる能力もあるのに、と、
思ったことがあります。
『UNIXという考え方−その設計思想と哲学』を読んで、
マウス操作もアリ（操作は、なるべく楽をしろ）なのだな、と、
考えを改めた執筆者君でしたー（きょうのわんこ風）。
2022/05/02(月) 10:00:39.94
ありきたりな環境で人並みに過ごすのか、楽をする為に人並み外れた途方も無い時間と労力を費やすのか
まさに人それぞれと言う話でござるな
まさに人それぞれと言う話でござるな
2022/05/02(月) 12:23:55.75
まあどっちかというとWindowsならマウス無しのオペレーションも無くはないんだけどね。
2022/05/03(火) 02:13:54.53
> BSD/LinuxでのOffice/Desktop環境を語れ！ Part03
2022/05/03(火) 06:07:53.55
ちんちんシュッ!シュッ!シュッ!
2022/05/03(火) 08:38:34.79
お題にはちんちんなんか生えて無いが
2022/05/06(金) 01:20:47.43
2022/05/08(日) 00:39:11.24
みなさん、フツーにリッチなデスクトップ環境を使っているのね。
計算機資源は、makeやコンパイルに振り向けるべきだよ、
それなら自作PCも安価で済むしね、という貧乏性な執筆者です。
大昔、初めてWindow Managerの仮想デスクトップを使った時は、
「わー、すげー」とか言って、いくつかの窓を仮想デスクトップへ
移動させたが、存在を忘れてシャットダウン。
仮想デスクトップマネージャみたいなものがあっても、
「見えていない物は忘れてしまう」という事に気づいて、
そもそも、仮想デスクトップは使わなくなった。
XのWindow Managerは、ソフトウェアを位置指定（-geometry）して
起動ができるので、「わー、すげー」とか言って、
「Emacsはこの位置で」などと、設定に夢中になったが、
同じソフトウェアを複数起動すると、ピッタリと同じ位置に
起動するので、先に起動していたのを忘れてしまう、という事で、
位置指定もやめた。ダメダメじゃん。
といっても、タイル型のWindow Managerへ行くほどでもないです。
計算機資源は、makeやコンパイルに振り向けるべきだよ、
それなら自作PCも安価で済むしね、という貧乏性な執筆者です。
大昔、初めてWindow Managerの仮想デスクトップを使った時は、
「わー、すげー」とか言って、いくつかの窓を仮想デスクトップへ
移動させたが、存在を忘れてシャットダウン。
仮想デスクトップマネージャみたいなものがあっても、
「見えていない物は忘れてしまう」という事に気づいて、
そもそも、仮想デスクトップは使わなくなった。
XのWindow Managerは、ソフトウェアを位置指定（-geometry）して
起動ができるので、「わー、すげー」とか言って、
「Emacsはこの位置で」などと、設定に夢中になったが、
同じソフトウェアを複数起動すると、ピッタリと同じ位置に
起動するので、先に起動していたのを忘れてしまう、という事で、
位置指定もやめた。ダメダメじゃん。
といっても、タイル型のWindow Managerへ行くほどでもないです。
2022/05/08(日) 07:22:02.21
> ※執筆者はC言語もMakefileも理解していない
2022/05/09(月) 22:51:06.79
>>140
あははー。
執筆者のスキルを明示するためにサラッと書いたんですが。
前スレにwimeネタを初めて書いた時点で書きましたが、
執筆者は、C言語も、Makefileも、理解していません。
いちおう、見るには見ますが、修正する能力はありません。
ケアレスミス程度なら修正しますが。
さらに言えば、シェルスクリプトも、こみいったものだと、
追いきれず、途中で迷子になります。
wimeや、Wineに対して、*BSD業界の高スキルユーザさんに
興味を持ってほしい、というのは、それが理由なんです。
「FreeBSDでは、動かないんですが」
「さあ？ Linuxでは普通に動いてるし」
「え゛え゛！」
って、ありそうでしょ。
あははー。
執筆者のスキルを明示するためにサラッと書いたんですが。
前スレにwimeネタを初めて書いた時点で書きましたが、
執筆者は、C言語も、Makefileも、理解していません。
いちおう、見るには見ますが、修正する能力はありません。
ケアレスミス程度なら修正しますが。
さらに言えば、シェルスクリプトも、こみいったものだと、
追いきれず、途中で迷子になります。
wimeや、Wineに対して、*BSD業界の高スキルユーザさんに
興味を持ってほしい、というのは、それが理由なんです。
「FreeBSDでは、動かないんですが」
「さあ？ Linuxでは普通に動いてるし」
「え゛え゛！」
って、ありそうでしょ。
2022/05/12(木) 07:23:45.98
143FreeBSDでwimeを使っている
2022/06/01(水) 23:33:10.45 執筆者しか、FreeBSDで、Wineが、ないと困るほどの状態で
常用しているユーザはいないのではないか、と思っていましたが、
FreeBSDでWineな方がおられました。
みなさん、WineのFreeBSDでの特有の知見を共有するためにも、
Wineをドンドン使いましょう【ＰＲ】。ｗ （URLの後は引用です）
https://twitter.com/stackfield_jpn/status/1528331070152019969
stackfield@stackfield_jpn
FreeBSDでCarrara 8.5 64bitが動いたな。 wine 6.0な。wine-devel(7.4.1)だと動かんのだがおもしろい話。
8:04 PM · May 22, 2022·Twitter Web App
https://twitter.com/5chan_nel (5ch newer account)
常用しているユーザはいないのではないか、と思っていましたが、
FreeBSDでWineな方がおられました。
みなさん、WineのFreeBSDでの特有の知見を共有するためにも、
Wineをドンドン使いましょう【ＰＲ】。ｗ （URLの後は引用です）
https://twitter.com/stackfield_jpn/status/1528331070152019969
stackfield@stackfield_jpn
FreeBSDでCarrara 8.5 64bitが動いたな。 wine 6.0な。wine-devel(7.4.1)だと動かんのだがおもしろい話。
8:04 PM · May 22, 2022·Twitter Web App
https://twitter.com/5chan_nel (5ch newer account)
144名無しさん＠お腹いっぱい。
2022/06/05(日) 04:35:01.14 FreeBSDの使い手でケンモメンねえ
まさかとは思うが可能性はゼロじゃねえ
まさかとは思うが可能性はゼロじゃねえ
2022/06/19(日) 11:19:27.74
LINEはwineで動くんかな？ (他力本願)
146名無しさん＠お腹いっぱい。
2022/06/21(火) 01:05:51.17 vncやxrdpで入ろうとするとconsolekit-daemonがエラー吐きながら1分から2分くらい待たせやがるんだが何事かわかる？
2022/06/21(火) 06:49:29.05
なぜその吐いたエラーを貼らんのか？
148名無しさん＠お腹いっぱい。
2022/06/21(火) 07:33:32.12 例えばこんなの
console-kit-daemon[7641]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device
> なぜその吐いたエラーを貼らんのか？
寝起きで思い出した様に書いたから
console-kit-daemon[7641]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device
> なぜその吐いたエラーを貼らんのか？
寝起きで思い出した様に書いたから
149名無しさん＠お腹いっぱい。
2022/06/21(火) 08:57:19.40 あとconsole-kit-daemonじゃないけど気になったのはこれ
xrdp-sesman[1599]: [ERROR] sesman_data_in: scp_process_msg failed
xrdp-sesman[1599]: [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
dbus-daemon[1440]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out (service_start_timeout=25000ms)
dbusが吐いたタイムアウトエラーの後に一応繋がりはするんだけどさ
xrdp-sesman[1599]: [ERROR] sesman_data_in: scp_process_msg failed
xrdp-sesman[1599]: [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
dbus-daemon[1440]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out (service_start_timeout=25000ms)
dbusが吐いたタイムアウトエラーの後に一応繋がりはするんだけどさ
150146
2022/06/22(水) 01:08:18.49 結局手直しは諦め新規インストール用データセットへinstallworld、設定複製、
chrootして各種パッケージ入れて再起動し一応解決
リフレッシュ出来たと思う事にしました
chrootして各種パッケージ入れて再起動し一応解決
リフレッシュ出来たと思う事にしました
2022/06/22(水) 14:20:58.00
Desktop環境の話なのか？
2022/06/22(水) 15:35:56.93
デスクトップ環境にリモートアクセスし操作する為のプログラム
そんなこと言い出したらwineの話もアウツでは
そんなこと言い出したらwineの話もアウツでは
2022/06/29(水) 16:31:07.07
2022/07/01(金) 06:33:31.92
おお～Becky!動くんだね～(^_^)
2022/07/02(土) 15:54:11.47
winnyとかFLMASKはwineで動くのかな？
当時？はFLMASKのためだけに、vmwareを入れたりしてたけど
当時？はFLMASKのためだけに、vmwareを入れたりしてたけど
2022/07/02(土) 17:58:32.96
2022/07/05(火) 21:43:23.06
FreeBSDのMATEに、
・mate-desktop/mate-netbook
https://github.com/mate-desktop/mate-netbook
・ubuntu-mate/mate-window-applets: Window applets for MATE Desktop
https://github.com/ubuntu-mate/mate-window-applets
・ghostbsd/station-tweak: This is Station Tweak, a fork of MATE Tweak.
https://github.com/ghostbsd/station-tweak
この辺を野良ビルドで入れるのオススメ
・mate-desktop/mate-netbook
https://github.com/mate-desktop/mate-netbook
・ubuntu-mate/mate-window-applets: Window applets for MATE Desktop
https://github.com/ubuntu-mate/mate-window-applets
・ghostbsd/station-tweak: This is Station Tweak, a fork of MATE Tweak.
https://github.com/ghostbsd/station-tweak
この辺を野良ビルドで入れるのオススメ
2022/07/07(木) 02:59:54.89
github使うのヤメレ、ってニュースがあったな
2022/07/07(木) 09:08:34.60
これのことか
GitHubの利用をやめるようオープンソースソフトウェア非営利団体が強く呼びかけ - GIGAZINE
https://gigazine.net/news/20220704-software-freedom-conservancy-give-up-github/
ギガジンを鵜呑みにしてしまう人っているのか
GitHubの利用をやめるようオープンソースソフトウェア非営利団体が強く呼びかけ - GIGAZINE
https://gigazine.net/news/20220704-software-freedom-conservancy-give-up-github/
ギガジンを鵜呑みにしてしまう人っているのか
2022/07/07(木) 23:09:55.29
Software Freedom Conservancyがどんな団体なのか
の方がgigazine云々より重要じゃないか？
の方がgigazine云々より重要じゃないか？
2022/07/08(金) 09:45:59.63
余所でやってください。
2022/08/03(水) 22:10:45.53
>>143
今、気づきましたが、ハンドル名をコピペミスしている……。
「ERROR: 余所でやってください。[unix]」エラーのため、
書き込みをリトライしていたからだと思います。
>>156
https://www.winehq.org/search?q=atok
上記URLのWineHQ公式のデータベースでは、
2017/07/21にReleasedされたWine2.13で、ATOK2017が、Garbage評価、
という報告が出てきます。
この年度時点で、すでにwimeは熟成した存在で、執筆者君が、FreeBSDで
wimeを試した初めてのレスが、前スレに書かれています。
この時点で、wimeに対するLinux業界での喜びの声は、沈静化しており、
執筆者の、Linux板のWineスレへのレスに対しても、「懐かしい」感の
あるレスがありました。
たしかに「素」のWineでは、ATOKは動きませんが、
Wine＋wime＋ATOKで、CannaServerに見える形で動くので
周回遅れでのデータベース登録となっているのも事実です。
※ATOK2017がwimeで動作するという報告は見あたりませんが。
日本語利用者がこのデータベースを参考にする可能性は、
比較的に低いと思われますが、誤解を生む登録だなあ、
と思います。
日本語を常用利用していない方が登録したのかなあ。
今、気づきましたが、ハンドル名をコピペミスしている……。
「ERROR: 余所でやってください。[unix]」エラーのため、
書き込みをリトライしていたからだと思います。
>>156
https://www.winehq.org/search?q=atok
上記URLのWineHQ公式のデータベースでは、
2017/07/21にReleasedされたWine2.13で、ATOK2017が、Garbage評価、
という報告が出てきます。
この年度時点で、すでにwimeは熟成した存在で、執筆者君が、FreeBSDで
wimeを試した初めてのレスが、前スレに書かれています。
この時点で、wimeに対するLinux業界での喜びの声は、沈静化しており、
執筆者の、Linux板のWineスレへのレスに対しても、「懐かしい」感の
あるレスがありました。
たしかに「素」のWineでは、ATOKは動きませんが、
Wine＋wime＋ATOKで、CannaServerに見える形で動くので
周回遅れでのデータベース登録となっているのも事実です。
※ATOK2017がwimeで動作するという報告は見あたりませんが。
日本語利用者がこのデータベースを参考にする可能性は、
比較的に低いと思われますが、誤解を生む登録だなあ、
と思います。
日本語を常用利用していない方が登録したのかなあ。
2022/08/03(水) 22:19:31.21
すでに、ずいぶん前から使っている方からすれば、いまさらでしょうが、
Emacs28.1で、文書中の全角空白（2byte空白）が赤のアンダーバーで
表示されるようになりました。
まあ、昔から設定によって全角空白などを表示させることはできましたが、
四角い形状で表示されたりして、執筆者的にはイマイチ感があり、
アンダーバー表示の控えめ感は、ありがたいと感じています。
ただ、Emacsのエコー領域に表示されるCannaの変換候補でも表示されます。
※emacs-cannaで、canna.elを使用。
不思議なことに、全角漢字の候補のうしろにも表示されています。
漢字は全角なので、まあ、おかしくはないけれど、意味がない、と
思うのですが……、ああーっ！分かったー！
変換候補の一単語ごとの区切りの空白に全角空白を使用しているので、
それに反応して赤のアンダーバーが表示されているんだ！
Emacs28.1で、文書中の全角空白（2byte空白）が赤のアンダーバーで
表示されるようになりました。
まあ、昔から設定によって全角空白などを表示させることはできましたが、
四角い形状で表示されたりして、執筆者的にはイマイチ感があり、
アンダーバー表示の控えめ感は、ありがたいと感じています。
ただ、Emacsのエコー領域に表示されるCannaの変換候補でも表示されます。
※emacs-cannaで、canna.elを使用。
不思議なことに、全角漢字の候補のうしろにも表示されています。
漢字は全角なので、まあ、おかしくはないけれど、意味がない、と
思うのですが……、ああーっ！分かったー！
変換候補の一単語ごとの区切りの空白に全角空白を使用しているので、
それに反応して赤のアンダーバーが表示されているんだ！
2022/08/03(水) 22:31:33.19
(ヽ´ん`) それぼく
ごぶさたしております。
ニュー速(嫌儲)のキャラクターがカワイイので、つい見に行って
しまう執筆者君です。
FreeBSD13.1R/amd64を新規インストールしました。
さて、執筆者がアテにしているソフトウェアはWineとwimeです。
WOW64となった現在のFreeBSDのWineでは、
32bit環境の展開で「versions do not match!」>>98 となったり、
wimeのwimectrlで「"libX11.so.6" not found」>>95 >>99となったりの
過去がありますので、今のところ、FreeBSD13.0R/amd64の
「/var/cache/pkg/」からコピーして保存しておいた
「i386-wine-devel-6.12,1.pkg」を、FreeBSD13.1R/amd64に
「pkg add」で入れて使っていますが、普通に入って、普通に、
i386-wine-devel-6.12が使えています。
wimeのために、FreeBSD13.0R/i386でmakeした「imm32.dll.so」を
「/usr/local/lib32/wine/i386-unix/imm32.dll.so」に置いて
wime（FreeBSD13.0R/i386でコンパイルしたもの）が稼働しています。
もちろん、Wineが6系なので、（他のdotファイルでもよいが）.cshrcに
「setenv WINEDLLPATH /usr/local/lib32/wine」を設定しています。
こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の
「Distribution Select」で「lib32」を入れておきました。
FreeBSDのPortsのWineは、公式やLinuxと同じタイミングで、VersionUp
する時もあれば、少し対応が遅く、ほぼ固定状態みたいな時があります。
i386-wineの時みたいな感じですが、まあ、ボランティアなので文句は
言えませんね。
余裕ができたらWOW64なWineを試してみます。
ごぶさたしております。
ニュー速(嫌儲)のキャラクターがカワイイので、つい見に行って
しまう執筆者君です。
FreeBSD13.1R/amd64を新規インストールしました。
さて、執筆者がアテにしているソフトウェアはWineとwimeです。
WOW64となった現在のFreeBSDのWineでは、
32bit環境の展開で「versions do not match!」>>98 となったり、
wimeのwimectrlで「"libX11.so.6" not found」>>95 >>99となったりの
過去がありますので、今のところ、FreeBSD13.0R/amd64の
「/var/cache/pkg/」からコピーして保存しておいた
「i386-wine-devel-6.12,1.pkg」を、FreeBSD13.1R/amd64に
「pkg add」で入れて使っていますが、普通に入って、普通に、
i386-wine-devel-6.12が使えています。
wimeのために、FreeBSD13.0R/i386でmakeした「imm32.dll.so」を
「/usr/local/lib32/wine/i386-unix/imm32.dll.so」に置いて
wime（FreeBSD13.0R/i386でコンパイルしたもの）が稼働しています。
もちろん、Wineが6系なので、（他のdotファイルでもよいが）.cshrcに
「setenv WINEDLLPATH /usr/local/lib32/wine」を設定しています。
こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の
「Distribution Select」で「lib32」を入れておきました。
FreeBSDのPortsのWineは、公式やLinuxと同じタイミングで、VersionUp
する時もあれば、少し対応が遅く、ほぼ固定状態みたいな時があります。
i386-wineの時みたいな感じですが、まあ、ボランティアなので文句は
言えませんね。
余裕ができたらWOW64なWineを試してみます。
2022/08/03(水) 22:38:16.29
FreeBSD13.1R/amd64でのVirtualBOXの話です。
現在のPortsでもpkg(8)の「quarterly」でも、VirtualBOXのVersionは
6.1.36です。
pkg(8)でVirtualBOX6.1.36を入れ、FreeBSD13.1R/amd64をブートすると
カーネルメッセージで、
KLD vboxdrv.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type
と言われます。
Solved - Virtualbox kernel module fails to load on FreeBSD 13.1-RELEASE | The FreeBSD Forums
https://forums.freebsd.org/threads/virtualbox-kernel-module-fails-to-load-on-freebsd-13-1-release.85191/
上記URLによると、2022/05/17時点の質問ですが、同じ状況が報告されて
いました。FreeBSD13.0でpkgがビルドされたことが原因のようです。
Forumで話題になっているのは6.1.34の頃の話のようですが、
6.1.36の今現在も同様のエラーが執筆者の環境では出ました。
ところが、上記Forumのfyamamoto氏の書き込み通りの手順で問題は
解決されました。
こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の
「Distribution Select」で「src」を入れておきました。
〔次に続く〕
現在のPortsでもpkg(8)の「quarterly」でも、VirtualBOXのVersionは
6.1.36です。
pkg(8)でVirtualBOX6.1.36を入れ、FreeBSD13.1R/amd64をブートすると
カーネルメッセージで、
KLD vboxdrv.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type
と言われます。
Solved - Virtualbox kernel module fails to load on FreeBSD 13.1-RELEASE | The FreeBSD Forums
https://forums.freebsd.org/threads/virtualbox-kernel-module-fails-to-load-on-freebsd-13-1-release.85191/
上記URLによると、2022/05/17時点の質問ですが、同じ状況が報告されて
いました。FreeBSD13.0でpkgがビルドされたことが原因のようです。
Forumで話題になっているのは6.1.34の頃の話のようですが、
6.1.36の今現在も同様のエラーが執筆者の環境では出ました。
ところが、上記Forumのfyamamoto氏の書き込み通りの手順で問題は
解決されました。
こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の
「Distribution Select」で「src」を入れておきました。
〔次に続く〕
2022/08/03(水) 22:52:27.66
〔前からの続き〕
fyamamoto氏の手法は、あらかじめpkgで「virtualbox-ose-kmod」を
インストールしておき、Portsから「virtualbox-ose-kmod」をmakeし、
カーネルモジュールだけをコピーするという手法で、正直なところ、
「make reinstall」でもいいような、とも思いますが、多少なりとも
時間や、計算機資源などが節約できるという利点があります。
執筆者は「基本的に、pkgでインストールし、一部のファイルだけを、
Portsでコンパイルされたバイナリで差し替えるため、workの下から
コピーで持ってくる」という、いかにも情弱っぽい手抜き手法を
Wineとwimeのために、とっていましたが、まさか、同じ手法を取る方が
おられるとは思いませんでした。本当に驚きました。
fyamamoto氏の後の、mss_cyclist氏の書き込みで、
＞I am not sure if this is necessary?
＞Code:
＞kldxref /boot/modules
とありますが、「kldxref /boot/modules」しておかないと、
warning: KLD '/boot/modules/vboxnetflt.ko' is newer than the linker.hints file
warning: KLD '/boot/modules/vboxnetadp.ko' is newer than the linker.hints file
とのメッセージが出ます。
fyamamoto氏の手法は、あらかじめpkgで「virtualbox-ose-kmod」を
インストールしておき、Portsから「virtualbox-ose-kmod」をmakeし、
カーネルモジュールだけをコピーするという手法で、正直なところ、
「make reinstall」でもいいような、とも思いますが、多少なりとも
時間や、計算機資源などが節約できるという利点があります。
執筆者は「基本的に、pkgでインストールし、一部のファイルだけを、
Portsでコンパイルされたバイナリで差し替えるため、workの下から
コピーで持ってくる」という、いかにも情弱っぽい手抜き手法を
Wineとwimeのために、とっていましたが、まさか、同じ手法を取る方が
おられるとは思いませんでした。本当に驚きました。
fyamamoto氏の後の、mss_cyclist氏の書き込みで、
＞I am not sure if this is necessary?
＞Code:
＞kldxref /boot/modules
とありますが、「kldxref /boot/modules」しておかないと、
warning: KLD '/boot/modules/vboxnetflt.ko' is newer than the linker.hints file
warning: KLD '/boot/modules/vboxnetadp.ko' is newer than the linker.hints file
とのメッセージが出ます。
2022/08/03(水) 22:58:38.04
執筆者は、FreeBSD13.0R/amd64で、Athlon5350のRadeonR3を
amdgpuで使っていましたが、FreeBSD13.1R/amd64では使えませんでした。
詳細としては、
カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。
モニターの電源ランプは、画面出力が「ある」状態だが、
実際の画面出力は「ない」。
たんに、「画面出力がないだけなのか」と、かなり時間を置いて
画面出力に頼らずにログイン作業をしてみたが、ログインできないので、
リセットボタンでリブートするしかない。
やってみたこと。
・「gpu-firmware-amd-kmod-banks」を入れてみた。
結果：状況変わらず。
・「loader.conf」に「hw.amdgpu.exp_hw_support=1」を追記。
出典：https://running-dog.net/2021/04/post_2429.html
結果：状況変わらず。
〔次に続く〕
amdgpuで使っていましたが、FreeBSD13.1R/amd64では使えませんでした。
詳細としては、
カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。
モニターの電源ランプは、画面出力が「ある」状態だが、
実際の画面出力は「ない」。
たんに、「画面出力がないだけなのか」と、かなり時間を置いて
画面出力に頼らずにログイン作業をしてみたが、ログインできないので、
リセットボタンでリブートするしかない。
やってみたこと。
・「gpu-firmware-amd-kmod-banks」を入れてみた。
結果：状況変わらず。
・「loader.conf」に「hw.amdgpu.exp_hw_support=1」を追記。
出典：https://running-dog.net/2021/04/post_2429.html
結果：状況変わらず。
〔次に続く〕
168FreeBSDでwimeを使っている君
2022/08/03(水) 23:09:41.27 〔前からの続き〕
PCIeスロットに、RadeonHD4350(RV710)なビデオカードをさして
radeon_drv.soを試してみましたが、
Fetal Server error : no screens found
で、Xサーバが起動せず。
しかたがないので、GeForceGT730なビデオカードにさし直し、
pkg(8)から入れた「nvidia-driver-340」で使っています。
NvidiaDriverだと、「/boot/loader.conf」に「nvidia_load="YES"」と
「/etc/X11/xorg.conf」に「Driver "nvidia"」だけで使えるので
ラクチンだなあ、と思います。
amdgpuが使えない、という最後の心当たりは、
AHCIブート（BIOSブート）で、FreeBSD13.1R/amd64をインストール
しており、「UEFIboot」にしていなかったからかなあ？ 、ぐらいです。
こんな風に変わっているよ、という助言などがあれば、
よろしくお願いします。
じゃ、お夜食、食べてきます。
PCIeスロットに、RadeonHD4350(RV710)なビデオカードをさして
radeon_drv.soを試してみましたが、
Fetal Server error : no screens found
で、Xサーバが起動せず。
しかたがないので、GeForceGT730なビデオカードにさし直し、
pkg(8)から入れた「nvidia-driver-340」で使っています。
NvidiaDriverだと、「/boot/loader.conf」に「nvidia_load="YES"」と
「/etc/X11/xorg.conf」に「Driver "nvidia"」だけで使えるので
ラクチンだなあ、と思います。
amdgpuが使えない、という最後の心当たりは、
AHCIブート（BIOSブート）で、FreeBSD13.1R/amd64をインストール
しており、「UEFIboot」にしていなかったからかなあ？ 、ぐらいです。
こんな風に変わっているよ、という助言などがあれば、
よろしくお願いします。
じゃ、お夜食、食べてきます。
2022/08/03(水) 23:45:22.27
xf86-video-ati/Makefile, xf86-video-amdgpu/Makefile に
ONLY_FOR_ARCHS_REASON= KMS is required and currently only available on x86/arm64/powerpc64
なんて書いてあるし
xf86-video-amdgpu/pkg-descr に
On FreeBSD requires amdgpu KMS driver from graphics/drm-kmod.
とあるけど graphics/drm-fbsd13-kmod はインストールしていたのか
ONLY_FOR_ARCHS_REASON= KMS is required and currently only available on x86/arm64/powerpc64
なんて書いてあるし
xf86-video-amdgpu/pkg-descr に
On FreeBSD requires amdgpu KMS driver from graphics/drm-kmod.
とあるけど graphics/drm-fbsd13-kmod はインストールしていたのか
2022/08/03(水) 23:50:56.79
あと 13.0 から 13.1 にアップグレードしたのなら -kmod は ports で make し直す必要があるかと
2022/08/04(木) 00:55:00.22
あわわ。即レス驚きました。ありがとうございます。
>>167 では、前提条件を書くのをコロリと忘れていました。
○FreeBSD13.1R/amd64はクリーンインストール。
○amdgpuを使うためにpkg(8)から入れた物は以下。
・xf86-video-amdgpu-22.0.0
・drm-fbsd13-kmod-5.4.191.g20220604_1
・gpu-firmware-amd-kmod-banks-20220511
○以下の設定をした。
・rc.confに「kld_list="amdgpu.ko"」
・xorg.confに「Driver "modesetting"」
・「#pw groupmod video -m <ユーザ名>」
「drm-fbsd13-kmod」の代わりに「drm-kmod」「drm-54-kmod」も
試しましたが状況は変わりませんでした。
>>167 では、前提条件を書くのをコロリと忘れていました。
○FreeBSD13.1R/amd64はクリーンインストール。
○amdgpuを使うためにpkg(8)から入れた物は以下。
・xf86-video-amdgpu-22.0.0
・drm-fbsd13-kmod-5.4.191.g20220604_1
・gpu-firmware-amd-kmod-banks-20220511
○以下の設定をした。
・rc.confに「kld_list="amdgpu.ko"」
・xorg.confに「Driver "modesetting"」
・「#pw groupmod video -m <ユーザ名>」
「drm-fbsd13-kmod」の代わりに「drm-kmod」「drm-54-kmod」も
試しましたが状況は変わりませんでした。
2022/08/04(木) 08:30:07.58
そもそもこれだけ熱心にレポート書いてる人が
あんなしょうもない釣りやるとも思えんよね
ここの嫌儲民はどちらかと言えばあの
あんなしょうもない釣りやるとも思えんよね
ここの嫌儲民はどちらかと言えばあの
2022/08/04(木) 11:44:50.27
2022/08/04(木) 12:05:37.86
2022/08/05(金) 00:52:11.29
ん？ 何か嫌疑が、かかってます？
古くさい釣りAAが貼られていたのも、それがらみですか？
世の中、ヒマ人が多いんですね。
嫌儲板には書いたことはありません。閲覧のみです。
そんなことよりも、wimeを、以下略。
執筆者は、UNIX板では「FreeBSDでwimeを使っている君」で
書き込みをしています。※他の板では書いていません。
仮に、初歩的な質問をする場合で、通りすがりのフリを
したくても、即バレてしまう文体なので、恥を忍んで固定名に
するつもりです。
Linux板に書く場合も、これからは同様にするつもりです。
それもこれも、すべてwimeの宣伝のためです。
なぜ宣伝するかというと、wimeを、以下略。
古くさい釣りAAが貼られていたのも、それがらみですか？
世の中、ヒマ人が多いんですね。
嫌儲板には書いたことはありません。閲覧のみです。
そんなことよりも、wimeを、以下略。
執筆者は、UNIX板では「FreeBSDでwimeを使っている君」で
書き込みをしています。※他の板では書いていません。
仮に、初歩的な質問をする場合で、通りすがりのフリを
したくても、即バレてしまう文体なので、恥を忍んで固定名に
するつもりです。
Linux板に書く場合も、これからは同様にするつもりです。
それもこれも、すべてwimeの宣伝のためです。
なぜ宣伝するかというと、wimeを、以下略。
2022/08/05(金) 00:56:09.74
さらに書き忘れていた。
執筆者がATIというかAMD系のビデオカードを選好するのは、
コンソールの文字が、クッキリ！ ハッキリ！ 白が明るい！
という、高度成長時代のテレビのＣＭみたいな好みがあるから、
というのもあるのですが、nvidia-driver使用時の、i386-wineでは、
pkg install後に、「patch-nvidia.sh」を走らせる必要があるから、
というものでした。
まあ、手順が増えると何かのトラブルに合う確率が上がるだろうから、
できれば避けたい、という、実につまらない理由です。
で、i386-wineで「patch-nvidia.sh」を走らせてみると、
nvidia.comから現在自分のPCで稼働している、
pkg(8)のnvidia-driver-340-340.108に対応した、
NVIDIA-FreeBSD-x86-340.108.tar.gzをダウンロードして
以下のように展開する、というものでした。
※もちろん、最初に走らせるだけでユーザ側での操作はありません。
［前の部分は略］
=> Extracting NVIDIA-FreeBSD-x86-340.108.tar.gz to /usr/local/lib32...
x libnvidia-tls.so.1
x libGL.so.1
x libnvidia-glcore.so.1
=> Cleaning up...
===> i386-wine-6.12,1 successfully patched for nvidia-driver-340.108_3
［終了］
ファイルの差し替え処理のようです。
執筆者がATIというかAMD系のビデオカードを選好するのは、
コンソールの文字が、クッキリ！ ハッキリ！ 白が明るい！
という、高度成長時代のテレビのＣＭみたいな好みがあるから、
というのもあるのですが、nvidia-driver使用時の、i386-wineでは、
pkg install後に、「patch-nvidia.sh」を走らせる必要があるから、
というものでした。
まあ、手順が増えると何かのトラブルに合う確率が上がるだろうから、
できれば避けたい、という、実につまらない理由です。
で、i386-wineで「patch-nvidia.sh」を走らせてみると、
nvidia.comから現在自分のPCで稼働している、
pkg(8)のnvidia-driver-340-340.108に対応した、
NVIDIA-FreeBSD-x86-340.108.tar.gzをダウンロードして
以下のように展開する、というものでした。
※もちろん、最初に走らせるだけでユーザ側での操作はありません。
［前の部分は略］
=> Extracting NVIDIA-FreeBSD-x86-340.108.tar.gz to /usr/local/lib32...
x libnvidia-tls.so.1
x libGL.so.1
x libnvidia-glcore.so.1
=> Cleaning up...
===> i386-wine-6.12,1 successfully patched for nvidia-driver-340.108_3
［終了］
ファイルの差し替え処理のようです。
2022/08/05(金) 01:02:54.85
日本語入力メソッド総合スレッド＠Linux＠5ch掲示板
https://mao.5ch.net/test/read.cgi/linux/1472658083/139-140
上記のレスのおかげでwime 4.1.5がリリースされているのを知りました。
新規リリースに気づいていませんでした。ありがとうございました。
上記URLでは「ATOK17」とありますが、ATOK17は、2004年度版となります。
＞ATOK17にあわせてATOK28W.IMEからATOK30W.IMEに変更したところ
とのレスが正しいとすると、2015年度版（ATOK28）に対する処理を
読み替えて変更した、ということですから、もともとの「ATOK17」表記は、
おそらく「ATOK30」が正しいと推測されるので、ATOK2017での動作報告
かと思われます。
いずれまとめて手順の書き換えをする時用にメモしておこう。
>>15に上記Linux板のURLを追加のこと、と。
https://mao.5ch.net/test/read.cgi/linux/1472658083/139-140
上記のレスのおかげでwime 4.1.5がリリースされているのを知りました。
新規リリースに気づいていませんでした。ありがとうございました。
上記URLでは「ATOK17」とありますが、ATOK17は、2004年度版となります。
＞ATOK17にあわせてATOK28W.IMEからATOK30W.IMEに変更したところ
とのレスが正しいとすると、2015年度版（ATOK28）に対する処理を
読み替えて変更した、ということですから、もともとの「ATOK17」表記は、
おそらく「ATOK30」が正しいと推測されるので、ATOK2017での動作報告
かと思われます。
いずれまとめて手順の書き換えをする時用にメモしておこう。
>>15に上記Linux板のURLを追加のこと、と。
2022/08/05(金) 01:05:31.18
179FreeBSDでwimeを使っている君
2022/08/05(金) 01:15:10.58 drm-fbsd13-kmodをpkg(8)から入れず、Portsから入れてみる。
○FreeBSD13.1R/amd64はクリーンインストール。
○amdgpuを使うために入れたもの
・pkg(8)：xf86-video-amdgpu-22.0.0
・ports ：drm-fbsd13-kmod-5.4.191.g20220604_1
※pkg(8)と同じバージョン
・pkg(8)：gpu-firmware-amd-kmod-banks-20220511
・pkg(8)：mesa-dri-21.3.8 ※注
・pkg(8)：mesa-libs-21.3.8 ※注
注 https://running-dog.net/2021/04/post_2429.htmlに
書いてあったのだが、すでに入っていた。
○以下の設定をした。
・rc.confに「kld_list="amdgpu.ko"」
・xorg.confに「Driver "modesetting"」
・「#pw groupmod video -m <ユーザ名>」
pkg(8)の「drm-fbsd13-kmod-5.4.191.g20220604_1」を、removeし、
portsから「drm-fbsd13-kmod-5.4.191.g20220604_1」を
入れましたが、以下のように状況は変わらずでした。
カーネルメッセージの、rc.confの評価あたりで、画面出力が
なくなる。
モニターの電源ランプは、画面出力が「ある」状態だが、
実際の画面出力は「ない」。 で、リセットボタン。
まさか、「１分くらい待つと画面出力が始まる」とかじゃないで
しょうね。
いえね、i386を使っていた頃は、VGA表示から精細な表示に
切り替わるのに10秒くらいかかっていたので。
○FreeBSD13.1R/amd64はクリーンインストール。
○amdgpuを使うために入れたもの
・pkg(8)：xf86-video-amdgpu-22.0.0
・ports ：drm-fbsd13-kmod-5.4.191.g20220604_1
※pkg(8)と同じバージョン
・pkg(8)：gpu-firmware-amd-kmod-banks-20220511
・pkg(8)：mesa-dri-21.3.8 ※注
・pkg(8)：mesa-libs-21.3.8 ※注
注 https://running-dog.net/2021/04/post_2429.htmlに
書いてあったのだが、すでに入っていた。
○以下の設定をした。
・rc.confに「kld_list="amdgpu.ko"」
・xorg.confに「Driver "modesetting"」
・「#pw groupmod video -m <ユーザ名>」
pkg(8)の「drm-fbsd13-kmod-5.4.191.g20220604_1」を、removeし、
portsから「drm-fbsd13-kmod-5.4.191.g20220604_1」を
入れましたが、以下のように状況は変わらずでした。
カーネルメッセージの、rc.confの評価あたりで、画面出力が
なくなる。
モニターの電源ランプは、画面出力が「ある」状態だが、
実際の画面出力は「ない」。 で、リセットボタン。
まさか、「１分くらい待つと画面出力が始まる」とかじゃないで
しょうね。
いえね、i386を使っていた頃は、VGA表示から精細な表示に
切り替わるのに10秒くらいかかっていたので。
2022/08/05(金) 01:25:20.23
http://mevius.5ch.net/test/read.cgi/unix/1632283136/152-153
出力先が切り替わってるとかはないか
出力先が切り替わってるとかはないか
2022/08/05(金) 06:52:41.45
うろ覚えだがgpu firmwareみたいな名前のpkgもportsで作り直しが必要だったような。
2022/08/05(金) 13:09:12.38
本当にその程度のレベルの人かと言う話でもある
2022/08/05(金) 13:34:41.24
WoW64連呼してるのも本当なのかと疑問に思ってる
wine/Makefile に
# Wine assumes a WoW64 package is available, which is not the case on
# FreeBSD yet.
と書いてあるから
64bitと32bitを統合したWoW64じゃなくて64bitと32bitを同時に使えるようにした
だけなんじゃないかと思うんだが違うんだろうか
WoW64には64bit Wine側の対応が必要で64bitだけのWineとは違うはずだから
wine/Makefile に
# Wine assumes a WoW64 package is available, which is not the case on
# FreeBSD yet.
と書いてあるから
64bitと32bitを統合したWoW64じゃなくて64bitと32bitを同時に使えるようにした
だけなんじゃないかと思うんだが違うんだろうか
WoW64には64bit Wine側の対応が必要で64bitだけのWineとは違うはずだから
2022/08/05(金) 15:31:16.04
Athlon Athlon5350なのにgpu-firmware-amd-kmod をインストールしているのが間違い
必要なのはgpu-firmware-radeon-kmodの方
分からないのならMeta ports の gpu-firmware-kmod
あと -kmod なのだから pkg ではなく ports から試すように（特にトラブってる時には）
必要なのはgpu-firmware-radeon-kmodの方
分からないのならMeta ports の gpu-firmware-kmod
あと -kmod なのだから pkg ではなく ports から試すように（特にトラブってる時には）
2022/08/05(金) 15:35:38.52
amdなんて使ってないけどwikipedia見て調べてみた
180 書いたの俺だけどこれは関係無かったか
180 書いたの俺だけどこれは関係無かったか
2022/08/05(金) 16:13:19.73
wine 等とまるで関係ないんだがCinnamonが割とまともにつかえる
足りないと思ったものは適宜追加しながらお好きな人はどうぞ
ただし画面ロックとシステム情報おまえらはまだダメか ヤらねばヤられる
足りないと思ったものは適宜追加しながらお好きな人はどうぞ
ただし画面ロックとシステム情報おまえらはまだダメか ヤらねばヤられる
187FreeBSDでwimeを使っている君
2022/08/06(土) 00:53:08.52 >>175
すいません。
Linux板のWineスレで、すでに「FreeBSDでwimeを使っている君」で
書いていました。
https://mao.5ch.net/test/read.cgi/linux/1585198566/449
>>186
Wineのスレではないので、良さげっぽかったり、便利っぽかったり、な
情報は書いてください。
スレタイは「Office/Desktop環境」となっていますが、
Unix系OSでOfficeソフトを使うような日常生活環境を構築するための
情報交換をしたい、人柱報告（>>4など）も読みたい、というのが
スレの趣旨です。
Desktop環境にしても、LinuxのDistributionにしても、構築する個人や、
コミュニティの好みで構築されているので、長短がありますから。
すいません。
Linux板のWineスレで、すでに「FreeBSDでwimeを使っている君」で
書いていました。
https://mao.5ch.net/test/read.cgi/linux/1585198566/449
>>186
Wineのスレではないので、良さげっぽかったり、便利っぽかったり、な
情報は書いてください。
スレタイは「Office/Desktop環境」となっていますが、
Unix系OSでOfficeソフトを使うような日常生活環境を構築するための
情報交換をしたい、人柱報告（>>4など）も読みたい、というのが
スレの趣旨です。
Desktop環境にしても、LinuxのDistributionにしても、構築する個人や、
コミュニティの好みで構築されているので、長短がありますから。
2022/08/06(土) 00:59:17.91
2022/08/06(土) 01:02:30.02
>>183
＞64bitと32bitを同時に使えるようにしただけなんじゃ
たぶん、そうだと思います。 >>38 >>67 あたりに書きました。
FreeBSDのWOW64なWineとはいっても、FreeBSD/amd64の場合、
そのままでは、64bitなWindowsソフトウェアしか使えません。
32bitなWindowsソフトウェアを使いたい場合は >>69 に
書いたように、シェルスクリプトを走らせて、
ユーザのホームディレクトリの下に
32bitなWine（バイナリ提供の様子）を展開しないと
いけませんから。
以下のURLは参考まで。
http://hayabusa6.2ch.net/test/read.cgi/linux/1455088008/51-n
https://mao.5ch.net/test/read.cgi/linux/1585198566/442-n
https://mao.5ch.net/test/read.cgi/linux/1585198566/679-n
＞64bitと32bitを同時に使えるようにしただけなんじゃ
たぶん、そうだと思います。 >>38 >>67 あたりに書きました。
FreeBSDのWOW64なWineとはいっても、FreeBSD/amd64の場合、
そのままでは、64bitなWindowsソフトウェアしか使えません。
32bitなWindowsソフトウェアを使いたい場合は >>69 に
書いたように、シェルスクリプトを走らせて、
ユーザのホームディレクトリの下に
32bitなWine（バイナリ提供の様子）を展開しないと
いけませんから。
以下のURLは参考まで。
http://hayabusa6.2ch.net/test/read.cgi/linux/1455088008/51-n
https://mao.5ch.net/test/read.cgi/linux/1585198566/442-n
https://mao.5ch.net/test/read.cgi/linux/1585198566/679-n
190FreeBSDでwimeを使っている君
2022/08/06(土) 01:16:46.45 なんだか、入門者の犬小屋スレみたいになっていますが、
みなさん、ありがとうございます。
amdgpu、以下の環境で動きました。 >>181 >>184 の通りです。
本当にありがとうございました。
すべては執筆者の、KernelModuleへの理解が足りなかったのが
原因でした。
・pkg(8)：xf86-video-amdgpu-22.0.0
・ports ：drm-fbsd13-kmod-5.4.191.g20220604_1
・ports ：gpu-firmware-kmod(MetaPort)
＊rc.confに「kld_list="amdgpu.ko"」
＊xorg.confに「Driver "amdgpu"」
※「modesetting」でも動いた。
CUIのコンソール（カーネルメッセージ）の出力が
VGAから精細になり、
「やだっ！amdgpu.koとamdgpu_kabini*.koなどのKernelModuleが
正常に読み込まれたんだわっ！」と、誰だか分からない物まねを
しました。
やはり、pkg(8)のKernelModuleが、13.0環境で作成されていたのが
問題だったのだと思います。
これなら、RadeonHD4350(RV710)なビデオカードも動くと思います。
※試していませんが。
入れてて良かった「Distribution Select」で「src」、
「ports」もね！ （田中みな実さんぽくキリッとキメ顔）
みなさん、ありがとうございます。
amdgpu、以下の環境で動きました。 >>181 >>184 の通りです。
本当にありがとうございました。
すべては執筆者の、KernelModuleへの理解が足りなかったのが
原因でした。
・pkg(8)：xf86-video-amdgpu-22.0.0
・ports ：drm-fbsd13-kmod-5.4.191.g20220604_1
・ports ：gpu-firmware-kmod(MetaPort)
＊rc.confに「kld_list="amdgpu.ko"」
＊xorg.confに「Driver "amdgpu"」
※「modesetting」でも動いた。
CUIのコンソール（カーネルメッセージ）の出力が
VGAから精細になり、
「やだっ！amdgpu.koとamdgpu_kabini*.koなどのKernelModuleが
正常に読み込まれたんだわっ！」と、誰だか分からない物まねを
しました。
やはり、pkg(8)のKernelModuleが、13.0環境で作成されていたのが
問題だったのだと思います。
これなら、RadeonHD4350(RV710)なビデオカードも動くと思います。
※試していませんが。
入れてて良かった「Distribution Select」で「src」、
「ports」もね！ （田中みな実さんぽくキリッとキメ顔）
2022/08/06(土) 01:29:59.85
>>189
Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると
~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ
(emulators/i386-wine(含-devel)の頃には起こらなかった挙動)
Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると
~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ
(emulators/i386-wine(含-devel)の頃には起こらなかった挙動)
2022/08/06(土) 17:28:29.19
>>182
その程度のレベルだったな
その程度のレベルだったな
2022/08/06(土) 23:59:32.37
2022/08/07(日) 00:00:32.06
>>191
執筆者の試行では、32bit環境の.wineのまま（新規生成していない）で、
WOW64なWineで32bitなソフトウェアが動きました。
WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が
できていました。
執筆者の試行では、32bit環境の.wineのまま（新規生成していない）で、
WOW64なWineで32bitなソフトウェアが動きました。
WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が
できていました。
195FreeBSDでwimeを使っている君
2022/08/07(日) 00:01:51.57 まずは、おわびです（ガバッ、土下座）。
お散歩がてら「さがわ@sagawa_aki」氏のTwitterを見ていると
以下のようなTweetがReTweetされていました。
https://twitter.com/scp1979/status/1547002783227817985
＞晋太郎@scp1979
＞FreeBSD13.1でWineを起動したら「wine: could not load http://ntdll.so: (null)」と出て起動しなかった。
＞ググても解決方法が見つからなかった...
＞pkg info -D wine を確認したところ、procファイルシステムが必要と書いてあったのでmountしたら起動した。
＞#FreeBSD #Wine #備忘録
＞8:39 AM ・ Jul 13, 2022・Twitter Web App
執筆者は青ざめました。
「wine: could not load http://ntdll.so: (null)」で
このTweetより先に、大騒ぎした張本人だからです。
※大騒ぎの初出は、以下のURL、2020/12/11(金)。
https://mevius.5ch.net/test/read.cgi/unix/1107211157/919-921
https://mevius.5ch.net/test/read.cgi/unix/1107211157/951
https://mevius.5ch.net/test/read.cgi/unix/1107211157/952-953
https://mao.5ch.net/test/read.cgi/linux/1585198566/449
https://twitter.com/5chan_nel (5ch newer account)
お散歩がてら「さがわ@sagawa_aki」氏のTwitterを見ていると
以下のようなTweetがReTweetされていました。
https://twitter.com/scp1979/status/1547002783227817985
＞晋太郎@scp1979
＞FreeBSD13.1でWineを起動したら「wine: could not load http://ntdll.so: (null)」と出て起動しなかった。
＞ググても解決方法が見つからなかった...
＞pkg info -D wine を確認したところ、procファイルシステムが必要と書いてあったのでmountしたら起動した。
＞#FreeBSD #Wine #備忘録
＞8:39 AM ・ Jul 13, 2022・Twitter Web App
執筆者は青ざめました。
「wine: could not load http://ntdll.so: (null)」で
このTweetより先に、大騒ぎした張本人だからです。
※大騒ぎの初出は、以下のURL、2020/12/11(金)。
https://mevius.5ch.net/test/read.cgi/unix/1107211157/919-921
https://mevius.5ch.net/test/read.cgi/unix/1107211157/951
https://mevius.5ch.net/test/read.cgi/unix/1107211157/952-953
https://mao.5ch.net/test/read.cgi/linux/1585198566/449
https://twitter.com/5chan_nel (5ch newer account)
196FreeBSDでwimeを使っている君
2022/08/07(日) 00:04:36.77 で、前スレ951氏助言の
「setenv WINEDLLPATH /usr/local/lib32/wine」との設定をコメントし、
/etc/fstabに「proc /proc procfs rw 0 0」と、設定をして、
winecfgを起動すると、普通にwinecfgが起動しました。
執筆者が、procをマウントしていれば、騒ぐ必要がなかったミスとなります。
前スレの951氏にはWineのソースを調べ、助言レスをさせる、という手間を
かけさせて、まことに申し訳ありませんでした。
Linux板のWineスレでも質問をして、申し訳ありませんでした
執筆者の不注意なミスにより、心配した方々に迷惑をかけて、
本当に申し訳ありませんでした。
「setenv WINEDLLPATH /usr/local/lib32/wine」との設定をコメントし、
/etc/fstabに「proc /proc procfs rw 0 0」と、設定をして、
winecfgを起動すると、普通にwinecfgが起動しました。
執筆者が、procをマウントしていれば、騒ぐ必要がなかったミスとなります。
前スレの951氏にはWineのソースを調べ、助言レスをさせる、という手間を
かけさせて、まことに申し訳ありませんでした。
Linux板のWineスレでも質問をして、申し訳ありませんでした
執筆者の不注意なミスにより、心配した方々に迷惑をかけて、
本当に申し訳ありませんでした。
197FreeBSDでwimeを使っている君
2022/08/07(日) 00:16:44.112022/08/07(日) 00:54:25.07
199名無しさん＠お腹いっぱい。
2022/08/07(日) 03:52:07.25 >>193
そうか ならばもう大体把握した
そうか ならばもう大体把握した
2022/08/07(日) 07:49:48.49
>>195
当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。
ついでにそれがportsに反映された時期も。
四ヶ月後に再度見に行くか？ったらまあしないだろうし
そもそも当時の作業者が初耳！してるくらいだから。
あとprocマウントしてても多分そのエラーは当時は出てたと思う。
なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。
当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。
ついでにそれがportsに反映された時期も。
四ヶ月後に再度見に行くか？ったらまあしないだろうし
そもそも当時の作業者が初耳！してるくらいだから。
あとprocマウントしてても多分そのエラーは当時は出てたと思う。
なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。
201FreeBSDでwimeを使っている君
2022/08/07(日) 22:03:53.46 >>198-200
○「wine: could not load ntdll . so : (null)」と出る件
※5chに書き込んだ時点でゴミがつくので1byte空白をはさみました
前スレ919(2020/12/11)の執筆者のレス時点では、
https://forums.freebsd.org/threads/i-cant-run-windows-applications-with-wine-64bit.77253/
の、forumsが Oct 8, 2020 (2020/10/08)で、一時的に止まった時点を
執筆者は閲覧し、レスしていました。
Alexander88207氏（i386-wineのコミッタ）の Oct 8, 2020 (2020/10/08)の
書き込み(post-480654)では、
試してみて、同様の結果になる、と、報告しています。
※執筆者はこの書き込みは見ていました。
それから、ずいぶんたってforumsが動き出しました。
tbyte氏の May 2, 2021 (2021/05/02)の書き込み(post-509356)では、
FreeBSD13のwine-devel-6.4でも同様です（執筆者意訳）、
と報告されています。
grahamperrin氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522107)で、
Alexander88207氏に対して、「Do you still get a null there?」
と返しています。
Alexander88207氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522113)で、
「But the workaround for this error is to mount procfs on /proc.」
と書かれました。（注）
〔次に続く〕
○「wine: could not load ntdll . so : (null)」と出る件
※5chに書き込んだ時点でゴミがつくので1byte空白をはさみました
前スレ919(2020/12/11)の執筆者のレス時点では、
https://forums.freebsd.org/threads/i-cant-run-windows-applications-with-wine-64bit.77253/
の、forumsが Oct 8, 2020 (2020/10/08)で、一時的に止まった時点を
執筆者は閲覧し、レスしていました。
Alexander88207氏（i386-wineのコミッタ）の Oct 8, 2020 (2020/10/08)の
書き込み(post-480654)では、
試してみて、同様の結果になる、と、報告しています。
※執筆者はこの書き込みは見ていました。
それから、ずいぶんたってforumsが動き出しました。
tbyte氏の May 2, 2021 (2021/05/02)の書き込み(post-509356)では、
FreeBSD13のwine-devel-6.4でも同様です（執筆者意訳）、
と報告されています。
grahamperrin氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522107)で、
Alexander88207氏に対して、「Do you still get a null there?」
と返しています。
Alexander88207氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522113)で、
「But the workaround for this error is to mount procfs on /proc.」
と書かれました。（注）
〔次に続く〕
202FreeBSDでwimeを使っている君
2022/08/07(日) 22:05:49.33 〔前からの続き〕
前スレ992(2021/10/06)の執筆者のレスでは、同じforumsを参照して
いましたが、執筆者は、「wine: could not load」の件は、
コロリと忘れていました。
そこで、Alexander88207氏のJul 12, 2021 (2020/07/12)の
書き込み(post-522315)で、
「コンパイル時のバグだけが修正され、実行時のバグは無視されている」
（執筆者意訳）が、執筆者がまとめたレスとして書かれました。（注）
注：おそらく、推測ですが、2021/07/11から2021/07/12の時点では、
Alexander88207氏がコミッタのi386-wineでは、問題に対応済みで
他のコミッタがかかわるwineとは、挙動が違ったのではないだろうか。
Alexander88207氏が「実行時のバグは」とこぼすぐらいですから。
つまり、i386-wineだと /proc をマウント(post-522113)するだけで
動いたのではないだろうか。
もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して
検証することができないのですが。
〔次に続く〕
前スレ992(2021/10/06)の執筆者のレスでは、同じforumsを参照して
いましたが、執筆者は、「wine: could not load」の件は、
コロリと忘れていました。
そこで、Alexander88207氏のJul 12, 2021 (2020/07/12)の
書き込み(post-522315)で、
「コンパイル時のバグだけが修正され、実行時のバグは無視されている」
（執筆者意訳）が、執筆者がまとめたレスとして書かれました。（注）
注：おそらく、推測ですが、2021/07/11から2021/07/12の時点では、
Alexander88207氏がコミッタのi386-wineでは、問題に対応済みで
他のコミッタがかかわるwineとは、挙動が違ったのではないだろうか。
Alexander88207氏が「実行時のバグは」とこぼすぐらいですから。
つまり、i386-wineだと /proc をマウント(post-522113)するだけで
動いたのではないだろうか。
もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して
検証することができないのですが。
〔次に続く〕
203FreeBSDでwimeを使っている君
2022/08/07(日) 22:07:33.37 〔前からの続き〕
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257105
で、「wine: could not load」の件が報告され、
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257020
と、関係があると思われていたが、違うようだ、と、なったようだ。
「id=257105」は閉じられて、その後、どうなったかは分からない。
https://www.freshports.org/emulators/wine-devel/
では、31 Aug 2021 07:11:18(2021/08/31) の wine-devel 6.16,1で
「ntdll: Always return a value in get_builtin_init_funcs.」
として問題に対応がなされた。
……というのが時系列ではないでしょうか。
執筆者は、FreeBSD13.1R/amd64において、FreeBSD13.0R/amd64で
取得しておいた、i386-wine-devel-6.12,1のpkg(8)を「pkg add」で
入れて使っていますが、WINEDLLPATHの環境変数を設定しなくても、
「/proc」のマウントだけで使えています。
「wine: could not load」問題を、まとめれば、ですが、
現在、FreeBSDで、Wineを使うなら「proc」をマウントしておくこと、
ということですね。
執筆者が青ざめて謝罪をした意味はあります。
なぜなら、こんなことでもなければ、執筆者は「proc」をマウント
することはなかっただろう、と、思うからです。
試した報告をする方々、助言をくださる方々に感謝します。
〔終了〕
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257105
で、「wine: could not load」の件が報告され、
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257020
と、関係があると思われていたが、違うようだ、と、なったようだ。
「id=257105」は閉じられて、その後、どうなったかは分からない。
https://www.freshports.org/emulators/wine-devel/
では、31 Aug 2021 07:11:18(2021/08/31) の wine-devel 6.16,1で
「ntdll: Always return a value in get_builtin_init_funcs.」
として問題に対応がなされた。
……というのが時系列ではないでしょうか。
執筆者は、FreeBSD13.1R/amd64において、FreeBSD13.0R/amd64で
取得しておいた、i386-wine-devel-6.12,1のpkg(8)を「pkg add」で
入れて使っていますが、WINEDLLPATHの環境変数を設定しなくても、
「/proc」のマウントだけで使えています。
「wine: could not load」問題を、まとめれば、ですが、
現在、FreeBSDで、Wineを使うなら「proc」をマウントしておくこと、
ということですね。
執筆者が青ざめて謝罪をした意味はあります。
なぜなら、こんなことでもなければ、執筆者は「proc」をマウント
することはなかっただろう、と、思うからです。
試した報告をする方々、助言をくださる方々に感謝します。
〔終了〕
204名無しさん＠お腹いっぱい。
2022/08/08(月) 04:07:14.04 >>202
> もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して
> 検証することができないのですが。
パッケージを保存しておいた実機で各種検証する人の書く事とも思えんが
> もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して
> 検証することができないのですが。
パッケージを保存しておいた実機で各種検証する人の書く事とも思えんが
2022/08/08(月) 04:41:56.49
206FreeBSDでwimeを使っている君
2022/08/08(月) 20:52:30.49 >>204 >>205
し、知らなかったんだお……。
FreshPortsでしか見られないと思っていたんだお……。
「その程度のレベル」なんだお……。
「This port and its pre-built binaries」って、そもそもi386-wineは、
バイナリ配布だったのか。jailか何かで、32bit版も同時にmakeしていると
思っていた（注）。
じゃあ、FreeBSDのWOW64なWineで、/home以下に展開される32bit版Wineが
バイナリ配布なのも当然なのか。
しかも、i386-wineが、WineHQ公式Versionに追従するのが遅かったのも、
今のWOW64版Wineの追従が、やや遅いのも、バイナリ待ち、すりあわせ、
などの理由で、当然なのか。
>>38 で執筆者は、i386-wineがwineに「吸収」と書きましたが、
今のFreeBSDのWineは、単にwineとi386-wineをたばねたもの、という感じで、
>>183 の印象は正しいようです。
FreeBSDのWineでは、「wow64」の名称は、本物のWOW64ではなく、
単に「どっちも使えますよ」って意味なのかもしれません。
注：
i386-wineで32bitなATOKを使う場合、32bitなファイル（imm32.dll.so）に
wimeのパッチをあてる必要がありますが、i386-wineは、バイナリ配布の
ため、i386-wineのportsでwimeのパッチをあてるのは、そもそも無理だった、
ということになります（手作業でi386-wineと同じ事をするなら別ですが）。
>>14 で、執筆者は、
＞※i386-wineで、wimeのパッチがあたるかは、執筆者は未検証。
と、書きましたが、この迂遠な手抜き手法は、そうするしかなかった、と、
いうことになります。
し、知らなかったんだお……。
FreshPortsでしか見られないと思っていたんだお……。
「その程度のレベル」なんだお……。
「This port and its pre-built binaries」って、そもそもi386-wineは、
バイナリ配布だったのか。jailか何かで、32bit版も同時にmakeしていると
思っていた（注）。
じゃあ、FreeBSDのWOW64なWineで、/home以下に展開される32bit版Wineが
バイナリ配布なのも当然なのか。
しかも、i386-wineが、WineHQ公式Versionに追従するのが遅かったのも、
今のWOW64版Wineの追従が、やや遅いのも、バイナリ待ち、すりあわせ、
などの理由で、当然なのか。
>>38 で執筆者は、i386-wineがwineに「吸収」と書きましたが、
今のFreeBSDのWineは、単にwineとi386-wineをたばねたもの、という感じで、
>>183 の印象は正しいようです。
FreeBSDのWineでは、「wow64」の名称は、本物のWOW64ではなく、
単に「どっちも使えますよ」って意味なのかもしれません。
注：
i386-wineで32bitなATOKを使う場合、32bitなファイル（imm32.dll.so）に
wimeのパッチをあてる必要がありますが、i386-wineは、バイナリ配布の
ため、i386-wineのportsでwimeのパッチをあてるのは、そもそも無理だった、
ということになります（手作業でi386-wineと同じ事をするなら別ですが）。
>>14 で、執筆者は、
＞※i386-wineで、wimeのパッチがあたるかは、執筆者は未検証。
と、書きましたが、この迂遠な手抜き手法は、そうするしかなかった、と、
いうことになります。
2022/08/08(月) 20:59:38.99
「wine: could not load」の件は、
cgit.freebsd.orgによると、
i386-wineでは、以下のように、2021/07/上旬以降、
直近の動きがないので、すでに対応済みだった可能性があります。
i386-wine-devel
2021-07-08 Update to 6.12
2021-09-30 cleanup: drop support for EOL FreeBSD 11.X
i386-wine
2021-07-19 emulators/i386-wine: Update to 6.0.1
2021-09-30 cleanup: drop support for EOL FreeBSD 11.X
FreshPortsによると、Wine（i386-wineでないほう）では、
以下あたりで対応されたのかもしれません。
wine-devel
22 Jul 2021(2021/07/22) 6.13,1
wine
26 Jul 2021(2021/07/26) 6.0.1,1
cgit.freebsd.orgによると、
i386-wineでは、以下のように、2021/07/上旬以降、
直近の動きがないので、すでに対応済みだった可能性があります。
i386-wine-devel
2021-07-08 Update to 6.12
2021-09-30 cleanup: drop support for EOL FreeBSD 11.X
i386-wine
2021-07-19 emulators/i386-wine: Update to 6.0.1
2021-09-30 cleanup: drop support for EOL FreeBSD 11.X
FreshPortsによると、Wine（i386-wineでないほう）では、
以下あたりで対応されたのかもしれません。
wine-devel
22 Jul 2021(2021/07/22) 6.13,1
wine
26 Jul 2021(2021/07/26) 6.0.1,1
2022/08/08(月) 21:02:31.20
2022/08/08(月) 21:04:50.29
この件について、執筆者自身も、i386からamd64に移行したため、
また、Wine6.x系というくくりなら、必ず発生する、と、思いこんで
いたため、混乱していますが、おそらく、
Wine（Alexander88207氏がかかわっていないほう）では、
WINEDLLPATHを設定しないと動かなかったと思われます。
理由は >>200 。
しかし、執筆者の環境のi386-wineでは、WINEDLLPATHを設定しないと
動かなかった、という理由は、たんにprocをmountしていなかったため、
と推測できます。
なぜなら、i386-wine-devel-6.12は、このスレでは >>6 (2021/10/14)氏が、
特に設定せずに動いているから。>>6 の方はprocをmountしていたのだと
思います。
執筆者は >>28 >>29 (2021/11/12)の時点では、procをmountして
いませんでした。
さっ！ 「死んだ子の年を数える」より、FreeBSDのWOW64なWineの現状を
試さないといけないな。時間ができたら試します。
また、Wine6.x系というくくりなら、必ず発生する、と、思いこんで
いたため、混乱していますが、おそらく、
Wine（Alexander88207氏がかかわっていないほう）では、
WINEDLLPATHを設定しないと動かなかったと思われます。
理由は >>200 。
しかし、執筆者の環境のi386-wineでは、WINEDLLPATHを設定しないと
動かなかった、という理由は、たんにprocをmountしていなかったため、
と推測できます。
なぜなら、i386-wine-devel-6.12は、このスレでは >>6 (2021/10/14)氏が、
特に設定せずに動いているから。>>6 の方はprocをmountしていたのだと
思います。
執筆者は >>28 >>29 (2021/11/12)の時点では、procをmountして
いませんでした。
さっ！ 「死んだ子の年を数える」より、FreeBSDのWOW64なWineの現状を
試さないといけないな。時間ができたら試します。
2022/08/08(月) 21:16:23.56
>>208
あ、連続レス中にはさんでしまった。
＞multilib をサポートしてないからという発言に
ああ。そういう意味、そういうこと、だったのか。
なんの話だろう、特殊なライブラリ？ とか思っていました。
すいません、forumsの内容も、英語のため、精読していませんでした。
あ、連続レス中にはさんでしまった。
＞multilib をサポートしてないからという発言に
ああ。そういう意味、そういうこと、だったのか。
なんの話だろう、特殊なライブラリ？ とか思っていました。
すいません、forumsの内容も、英語のため、精読していませんでした。
2116
2022/08/08(月) 21:21:25.71 そう言えばprocfsはふつうにマウントしてましたねえ
と言うか sysutils/desktop-installer でDE入れると勝手に設定されるので
と言うか sysutils/desktop-installer でDE入れると勝手に設定されるので
2022/08/15(月) 00:08:53.38
>>211
ああ、やっぱり。
「wine: could not load」の件は、まさに「おま環」（お前の環境特有）
だった、ということでした。大騒ぎしてすいませんでした。
fstabの見直しで、procfsの設定に追加して、tmpfsに128MBを設定したという、
あつものに懲りてなますを吹くかのような執筆者君です。
あと、i386-wineが出てきた直後ぐらいに、2chで、i386-wineが待てない人用、
として手作業の方法をレスしていた方が、Portsはユーザが、makeしてinstall
することができないので、i386-wine的なものに対応しづらい、と
読んだことがあったような気がする。
※技評のWebの後藤大地氏のFreeBSDの記事で読んだのかもしれない。
Linuxもバイナリ配布が主で、ports的な仕組みからバイナリを作って
いるんだろうけど、どうしているのかなあ。
ああ、やっぱり。
「wine: could not load」の件は、まさに「おま環」（お前の環境特有）
だった、ということでした。大騒ぎしてすいませんでした。
fstabの見直しで、procfsの設定に追加して、tmpfsに128MBを設定したという、
あつものに懲りてなますを吹くかのような執筆者君です。
あと、i386-wineが出てきた直後ぐらいに、2chで、i386-wineが待てない人用、
として手作業の方法をレスしていた方が、Portsはユーザが、makeしてinstall
することができないので、i386-wine的なものに対応しづらい、と
読んだことがあったような気がする。
※技評のWebの後藤大地氏のFreeBSDの記事で読んだのかもしれない。
Linuxもバイナリ配布が主で、ports的な仕組みからバイナリを作って
いるんだろうけど、どうしているのかなあ。
2022/08/15(月) 00:10:31.92
手順の再まとめをする時用にアンカーを打っておこう。 >>12
まず、wime最新の、wime4.1.5の件。
「wime-4.1.5/exe/apisup.c:680: undefined reference to `mempcpy'」
としてgmakeが通りません。
以下、「wime-4.1.5/lib/freebsd.h」より引用。
＞#ifndef FREEBSD_MEMPCMP
＞//いつからかは分からないが、13.1には存在する。
とのことで、組み合わせを試しましたが
FreeBSD13.1R/i386ではwime4.1.4のgmakeは通らない。
FreeBSD13.0R/i386ではwime4.1.5のgmakeは通らない。
FreeBSD13.1R/i386でgmakeを通したければwime4.1.5を選択する。
FreeBSD13.0R/i386でgmakeを通したければwime4.1.4を選択する。
という結果になりました。
まず、wime最新の、wime4.1.5の件。
「wime-4.1.5/exe/apisup.c:680: undefined reference to `mempcpy'」
としてgmakeが通りません。
以下、「wime-4.1.5/lib/freebsd.h」より引用。
＞#ifndef FREEBSD_MEMPCMP
＞//いつからかは分からないが、13.1には存在する。
とのことで、組み合わせを試しましたが
FreeBSD13.1R/i386ではwime4.1.4のgmakeは通らない。
FreeBSD13.0R/i386ではwime4.1.5のgmakeは通らない。
FreeBSD13.1R/i386でgmakeを通したければwime4.1.5を選択する。
FreeBSD13.0R/i386でgmakeを通したければwime4.1.4を選択する。
という結果になりました。
2022/08/15(月) 00:13:36.79
>>45 などのように、以下のようなエラーが出ることがあります。
gmake[1]: *** 'wimeapi.o' に必要なターゲット 'X11/keysym.h' を make するルールがありません. 中止.
gmake[1]: ディレクトリ '/usr/home/ユーザ名/work/wime-4.1.5/so' から出ます
gmake: *** [Makefile:12: so] エラー 2
この件は、解決しました。
執筆者の低スキルに由来するはずですが、pkg(8)から入れたWineの
バイナリだけでは、wimeは、gmakeが通りません。
PortsでWineをmakeだけ（make installしていない）した場合は、
gmakeが通ります。
おそらく、Wineのmake作業に必要な、依存する何かのパッケージの
ある、なし、で、通る、通らない、があるのだと思います。
FreshPortsなどから、依存関係を追っかけると、何が足りずに
wimeのgmakeでエラーが出るのか、が判明すると思いますが、
執筆者には知識がないので、これ以上の追求は無理とさせてください。
注意：
FreeBSD13.1Rでの一般的な用途で、pkg(8)から各種ソフトウェアを
入れた場合、llvm13が入りますが、Wine7系をPortsからmakeする
場合は、llvm12に依存していますので、あらかじめpkg(8)で入れて
おくとよいでしょう。
手順の再まとめ >>12
gmake[1]: *** 'wimeapi.o' に必要なターゲット 'X11/keysym.h' を make するルールがありません. 中止.
gmake[1]: ディレクトリ '/usr/home/ユーザ名/work/wime-4.1.5/so' から出ます
gmake: *** [Makefile:12: so] エラー 2
この件は、解決しました。
執筆者の低スキルに由来するはずですが、pkg(8)から入れたWineの
バイナリだけでは、wimeは、gmakeが通りません。
PortsでWineをmakeだけ（make installしていない）した場合は、
gmakeが通ります。
おそらく、Wineのmake作業に必要な、依存する何かのパッケージの
ある、なし、で、通る、通らない、があるのだと思います。
FreshPortsなどから、依存関係を追っかけると、何が足りずに
wimeのgmakeでエラーが出るのか、が判明すると思いますが、
執筆者には知識がないので、これ以上の追求は無理とさせてください。
注意：
FreeBSD13.1Rでの一般的な用途で、pkg(8)から各種ソフトウェアを
入れた場合、llvm13が入りますが、Wine7系をPortsからmakeする
場合は、llvm12に依存していますので、あらかじめpkg(8)で入れて
おくとよいでしょう。
手順の再まとめ >>12
2022/08/15(月) 00:17:44.71
wimeの件の続き。
wime4.1.5の現在も「wime-4.1.5/io/Makefile」には、
＞#amd64でi386-wineを動かしているとき
＞ifeq "$(WOW64)" "1"
＞override CC:=$(CC32_ENV) $(CC)
＞override CFLAGS+=-m32
＞override LDFLAGS+=-m32
＞#さらにfreebsdのとき。LDFLAGSのlibX11.soのパスを
＞/usr/local/libから/usr/local/lib32にする。
とありますので、amd64のi386-wineでもgmakeが通ると思います。
いや、まあ、i386-wineは、なくなったんですけどね。
手順の再まとめ >>14
wime4.1.5の現在も「wime-4.1.5/io/Makefile」には、
＞#amd64でi386-wineを動かしているとき
＞ifeq "$(WOW64)" "1"
＞override CC:=$(CC32_ENV) $(CC)
＞override CFLAGS+=-m32
＞override LDFLAGS+=-m32
＞#さらにfreebsdのとき。LDFLAGSのlibX11.soのパスを
＞/usr/local/libから/usr/local/lib32にする。
とありますので、amd64のi386-wineでもgmakeが通ると思います。
いや、まあ、i386-wineは、なくなったんですけどね。
手順の再まとめ >>14
2022/08/15(月) 00:21:48.92
Wineの試行で環境がぐちゃぐちゃになり、不審な動きをするように
なったので、「pkg delete -a」でpkg(8)を入れ直しました。
一部はPortsから入れるのですが、以下のようなメッセージが
出ていました。
＊現在のFreeBSD13.1R/amd64のpkg(8)の場合
# pkg install virtualbox-ose-kmod-6.1.36
（中略）
To avoid crashes due to kernel incompatibility, this module will only
load on FreeBSD 13.0 kernels.
＊現在のFreeBSD13.1R/amd64のPortsの場合
virtualbox-ose-kmod # make install
（中略）
To avoid crashes due to kernel incompatibility, this module will only
load on FreeBSD 13.1 kernels.
ちゃんとメッセージが出ていましたね。
>>170,174,178,184 の助言と経験のおかげで書くのですが、
新バージョン公開から３か月で、旧バージョンはEnd of Lifeと
なりますので、あと少しで、pkg(8)から入るKernelModuleは、
13.1でmakeされたものが提供されることになるでしょう。
なったので、「pkg delete -a」でpkg(8)を入れ直しました。
一部はPortsから入れるのですが、以下のようなメッセージが
出ていました。
＊現在のFreeBSD13.1R/amd64のpkg(8)の場合
# pkg install virtualbox-ose-kmod-6.1.36
（中略）
To avoid crashes due to kernel incompatibility, this module will only
load on FreeBSD 13.0 kernels.
＊現在のFreeBSD13.1R/amd64のPortsの場合
virtualbox-ose-kmod # make install
（中略）
To avoid crashes due to kernel incompatibility, this module will only
load on FreeBSD 13.1 kernels.
ちゃんとメッセージが出ていましたね。
>>170,174,178,184 の助言と経験のおかげで書くのですが、
新バージョン公開から３か月で、旧バージョンはEnd of Lifeと
なりますので、あと少しで、pkg(8)から入るKernelModuleは、
13.1でmakeされたものが提供されることになるでしょう。
2022/08/15(月) 00:47:38.25
FreeBSDでWOW64みたいな動きをするようになったWineとwimeの話です。
現在のFreeBSD13.1R/amd64でのwine-devel7.14(WOW64)で、
32bitなATOKを動かすために、FreeBSD13.1R/i386上でwimeのパッチを
あてて、Portsからmakeしても、imm32.dll.soでなく、imm32.dllしか
できていないので、amd64のWineには、imm32.dllを持ってきて
配置することになります。
FreeBSD13.1R/amd64のWine7.14では、imm32.dllがある場所は、以下です。
~/.i386-wine-pkg/usr/local/lib/wine/fakedlls/imm32.dll
~/.wine/drive_c/windows/system32/imm32.dll
※以前にはあった「wine/i386-windows」「wine/i386-unix」は
なくなっています。>>29 >>71
そのどちらに置いてもwimeは動きません（パッチがあたっていない状態）。
ただし、FreeBSD13.1R/i386には、
「wine/i386-windows」「wine/i386-unix」があり、
/usr/local/lib/wine/i386-windowsの下にはimm32.dllがある（注）
ので、（試していませんが）i386では動くと思われます。
注：
pkg(8)標準のimm32.dll(135168byte)と、wimeのpatchを当てた
Portsのものとでは、サイズは同じですが、md5は違いました。
現在のFreeBSD13.1R/amd64でのwine-devel7.14(WOW64)で、
32bitなATOKを動かすために、FreeBSD13.1R/i386上でwimeのパッチを
あてて、Portsからmakeしても、imm32.dll.soでなく、imm32.dllしか
できていないので、amd64のWineには、imm32.dllを持ってきて
配置することになります。
FreeBSD13.1R/amd64のWine7.14では、imm32.dllがある場所は、以下です。
~/.i386-wine-pkg/usr/local/lib/wine/fakedlls/imm32.dll
~/.wine/drive_c/windows/system32/imm32.dll
※以前にはあった「wine/i386-windows」「wine/i386-unix」は
なくなっています。>>29 >>71
そのどちらに置いてもwimeは動きません（パッチがあたっていない状態）。
ただし、FreeBSD13.1R/i386には、
「wine/i386-windows」「wine/i386-unix」があり、
/usr/local/lib/wine/i386-windowsの下にはimm32.dllがある（注）
ので、（試していませんが）i386では動くと思われます。
注：
pkg(8)標準のimm32.dll(135168byte)と、wimeのpatchを当てた
Portsのものとでは、サイズは同じですが、md5は違いました。
レスを投稿する
ニュース
- 日本行き空路４９万件キャンセル 中国自粛呼びかけ 日本行きチケット予約の約３２％に相当 ★2 [ぐれ★]
- 【中国局長】両国関係に「深刻な影響」 首相発言の撤回要求 [蚤の市★]
- 【卓球】早田ひな、「総額100万スられた」「ずっと憧れていたスペインとイタリア…」ヨーロッパ旅行で悲劇 スリ被害を告白 [muffin★]
- 外務省局長は無言で厳しい表情…日中の高官協議終了か 高市首相“台湾”発言で中国が強硬対応 発言撤回求めたか…★3 [BFU★]
- 【インバウンド】中国人観光客の日本での消費額は年間約2兆円超…中国政府は公務員の出張取り消し [１ゲットロボ★]
- 日経平均の下落率３％超す、財政懸念で長期金利上昇 ★2 [お断り★]
- 【実況】博衣こよりのえちえち歌枠🧪★2
- 【画像】外務省局長「この度はうちの🦎がすみません…」中国「……」 [165981677]
- 産経新聞「高市早苗の答弁さぁ……思慮が足りてなくね？官僚と詰めずに思いつきで話しているでしょ」 [175344491]
- 【高市速報】日本人の３割「中国への武力行使に踏み切る必要がある」ANN世論調査 [931948549]
- 【雑談】暇人集会所part18
- 外務省局長、よくわからないまま帰国へ [834922174]