BSD/LinuxでのOffice/Desktop環境を語れ！　Part03

1 ：名無しさん＠お腹いっぱい。：2021/10/06(水) 20:57:41.76 .net

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/

116 ：名無しさん＠お腹いっぱい。：2022/04/25(月) 16:35:41.14 .net

>>112
13-stableでpkgのwine6を使ってjanestyle4は動いた。この書き込みはそこから。

117 ：115：2022/04/25(月) 20:07:21.24 .net

>>116
確かに動いた　あっさりと
https://i.imgur.com/uWiXdbE.jpg

それも i386-wine-devel で使ってたやつがそのまんま
wime氏、116氏、ありがとう　そのうち私も何らかの成果があればご報告差し上げます

118 ：112と117：2022/04/25(月) 20:09:47.40 .net

>>117
自分のレス番間違えてしまった
とにかく感謝してます

119 ：名無しさん＠お腹いっぱい。：2022/04/26(火) 11:52:14 .net

wineは使わないけどV2Cだって13-stableで動くよ。
自分はV2C-Rを使ってて最近V2C/2に移行した。

120 ：名無しさん＠お腹いっぱい。：2022/04/26(火) 12:05:21 .net

これ？確かディスコンになったパッケージを使うやつ
https://mevius.5ch.net/test/read.cgi/unix/1632283136/79

121 ：名無しさん＠お腹いっぱい。：2022/04/26(火) 12:47:16.31 .net

そうそれ。
JAILで古いportsをビルドしてパッケージだけメイン環境に突っ込んだ。
スクリプトエンジンが変わってて動かんから古いエンジンを突っ込む必要があったり
ちょっと手間だったけどV2C/2が快適に動いててこの書き込みしてる。

122 ：名無しさん＠お腹いっぱい。：2022/04/28(木) 10:11:27.28 .net

>>74
これをベースにした合成フォントがportsに来たみたいですよ
FreshPorts -- japanese/font-udev-gothic: UDEV Gothic
https://www.freshports.org/japanese/font-udev-gothic/

123 ：FreeBSDでwimeを使っている君：2022/04/28(木) 20:24:05.14 .net

>>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/

124 ：名無しさん＠お腹いっぱい。：2022/04/28(木) 20:52:12.95 .net

>>123
上流リポジトリ
https://github.com/yuru7/udev-gothic

HackGenの作者さんの様でテキストエディタや端末エミュレータ用の等幅フォントですね
ナードフォントというやつは絵文字グリフが充実したフォントらしいです

125 ：名無しさん＠お腹いっぱい。：2022/04/29(金) 03:45:46.68 .net

>>113
この方妙に入力システムにこだわりがあるらしいんですけどどう思いますか？
https://mevius.5ch.net/test/read.cgi/win/1648180114/681
https://mevius.5ch.net/test/read.cgi/win/1648180114/683

126 ：FreeBSDでwimeを使っている君：2022/04/29(金) 22:19:21.18 .net

>>124
わざわざレスすいません。
モリサワの「BIZ UD」フォントからのPorts化なのでなく、
「yuru7」氏の二次的成果物（BIZ UD+JetBrains Mono）からの
Ports化なんですね。

127 ：FreeBSDでwimeを使っている君：2022/04/29(金) 22:23:29.31 .net

>>125
と、言われても……、なあ。
連日の長レスの後の短レスの投稿数の多さが恐いと思います。

Windowsは、「データを持って行って」ぐらいでしか
使ったことがないので、理解できませんでした。

今でこそ、Windowsが対応しておかないといけないキーボードは、
日本語か、英語か、ぐらいの選択ですが、昔は、Windowsが対応して
おくべきキーボードがたくさんありました。
101/104英語、106/109日本語、PC9801系、AX、J3100（ATコネクタ）、
FM-TOWNS、親指シフト（最近まで現役だったみたい）、かなあ。
Controlキーが、左にしかない場合もあるし、Windowsさんには歴史が
あるんだから、ぐちゃぐちゃとは言えないよね。

大昔（MS-DOS時代の話かもしれない）に読んだ、ATOKのバグ出し
チーム（だったかな？）の記事。
バグ出しチームは、標準のキー割り当てで変換し（当たり前ですが）、
しかも、変換結果の漢字が何番目に出るかも記憶しているため、
即、変換結果を選ぶことができ、漢字変換が正確で速いのは良いが、
学習機能を使わない状態（無意識に学習機能を使わないようにしていた）
だったため、学習機能の向上の役に立たない、ということに気づいた、
という話。

128 ：FreeBSDでwimeを使っている君：2022/04/29(金) 22:28:44.94 .net

>>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」には戻れません。

129 ：名無しさん＠お腹いっぱい。：2022/04/30(土) 16:58:54.71 .net

>>74
参考画像

定番Takao
https://i.imgur.com/t7lUV7Q.png

BIZ UD
https://i.imgur.com/mtaDaHV.png

130 ：名無しさん＠お腹いっぱい。：2022/05/01(日) 02:28:56.20 .net

>>127
もしご本人が読んだらどんな反応があるか目に浮かぶ様なご回答ですな

131 ：FreeBSDでwimeを使っている君：2022/05/01(日) 22:57:53.03 .net

>>130
恐いのは恐いんですが、悪口ではないんですよ。

ただ、キー割り当てやソフトウェアの挙動には、人間側として
不満があったとしても、よかれと思って考えられた設計思想や、
俗に語られる、タイプライターの配列の話などの、
いまさら変えられない歴史があるし、あえて、人間側が標準状態に
合わせるのも考え方として「ある」という話です。

ATOKのバグ出しチームの話も、「へえ、変換学習をさせなければ
変換先の順番が変わらないのだから、変換作業が速くなるね」と
感心したので、憶えていたのだと思います。

ATOKのスレで、ATOKの新規インストールをしたので、
「これから（自分流の入力をして）辞書を鍛える」というレスが
並んでいた中に、「短文でなく、長文で変換をしたら、文脈に
応じた変換結果になりやすいのに」というレスを見てからは、
執筆者も、文脈を読み取りやすい長さのタイミングで
変換するようになりました。そのレスには感謝しています。

132 ：FreeBSDでwimeを使っている君：2022/05/01(日) 23:00:08.42 .net

そのスレで言及があった「窓使いの憂鬱」は知っていましたが、
共同使用のPCには入れられないし（共同使用相手がUnix系とは
限らない）、「窓使いの憂鬱」を入れられる環境なら、
Emacsな人なら、xyzzyを入れて「メモ帳」代わりに使っても
よいだろうし、Windowsのダイアログ入力のコピペなどの
すべてまでも、を、Unixっぽくするのも、どうなのか、
Windowsにおいて、「絶対にマウスを使たくないでござる」は、
難しいだろうな、人間には慣れる能力もあるのに、と、
思ったことがあります。

『UNIXという考え方−その設計思想と哲学』を読んで、
マウス操作もアリ（操作は、なるべく楽をしろ）なのだな、と、
考えを改めた執筆者君でしたー（きょうのわんこ風）。

133 ：名無しさん＠お腹いっぱい。：2022/05/02(月) 10:00:39.94 .net

ありきたりな環境で人並みに過ごすのか、楽をする為に人並み外れた途方も無い時間と労力を費やすのか
まさに人それぞれと言う話でござるな

134 ：名無しさん＠お腹いっぱい。：2022/05/02(月) 12:23:55.75 .net

まあどっちかというとWindowsならマウス無しのオペレーションも無くはないんだけどね。

135 ：名無しさん＠お腹いっぱい。：2022/05/03(火) 02:13:54.53 .net

> BSD/LinuxでのOffice/Desktop環境を語れ！　Part03

136 ：名無しさん＠お腹いっぱい。：2022/05/03(火) 06:07:53.55 .net

ちんちんシュッ!シュッ!シュッ!

137 ：名無しさん＠お腹いっぱい。：2022/05/03(火) 08:38:34.79 .net

お題にはちんちんなんか生えて無いが

138 ：名無しさん＠お腹いっぱい。：2022/05/06(金) 01:20:47.43 .net

GhostBSDのデザイン割と好きなんですが
OpenRCに馴染めないのでパーツだけ拝借してそれっぽくしてみました
https://i.imgur.com/HmjeR0v.jpg

139 ：FreeBSDでwimeを使っている君：2022/05/08(日) 00:39:11.24 .net

みなさん、フツーにリッチなデスクトップ環境を使っているのね。

計算機資源は、makeやコンパイルに振り向けるべきだよ、
それなら自作PCも安価で済むしね、という貧乏性な執筆者です。

大昔、初めてWindow Managerの仮想デスクトップを使った時は、
「わー、すげー」とか言って、いくつかの窓を仮想デスクトップへ
移動させたが、存在を忘れてシャットダウン。

仮想デスクトップマネージャみたいなものがあっても、
「見えていない物は忘れてしまう」という事に気づいて、
そもそも、仮想デスクトップは使わなくなった。

XのWindow Managerは、ソフトウェアを位置指定（-geometry）して
起動ができるので、「わー、すげー」とか言って、
「Emacsはこの位置で」などと、設定に夢中になったが、
同じソフトウェアを複数起動すると、ピッタリと同じ位置に
起動するので、先に起動していたのを忘れてしまう、という事で、
位置指定もやめた。ダメダメじゃん。

といっても、タイル型のWindow Managerへ行くほどでもないです。

140 ：名無しさん＠お腹いっぱい。：2022/05/08(日) 07:22:02.21 .net

> ※執筆者はC言語もMakefileも理解していない

141 ：FreeBSDでwimeを使っている君：2022/05/09(月) 22:51:06.79 .net

>>140
あははー。
執筆者のスキルを明示するためにサラッと書いたんですが。

前スレにwimeネタを初めて書いた時点で書きましたが、
執筆者は、C言語も、Makefileも、理解していません。
いちおう、見るには見ますが、修正する能力はありません。
ケアレスミス程度なら修正しますが。
さらに言えば、シェルスクリプトも、こみいったものだと、
追いきれず、途中で迷子になります。
wimeや、Wineに対して、*BSD業界の高スキルユーザさんに
興味を持ってほしい、というのは、それが理由なんです。

「FreeBSDでは、動かないんですが」
「さあ？　Linuxでは普通に動いてるし」
「え゛え゛！」

って、ありそうでしょ。

142 ：名無しさん＠お腹いっぱい。：2022/05/12(木) 07:23:45.98 .net

https://livedoor.blogimg.jp/akira2016/imgs/4/e/4e7cc039.jpg

143 ：FreeBSDでwimeを使っている：2022/06/01(水) 23:33:10.45 .net

執筆者しか、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
(deleted an unsolicited ad)

144 ：名無しさん＠お腹いっぱい。：2022/06/05(日) 04:35:01.14 .net

FreeBSDの使い手でケンモメンねえ
まさかとは思うが可能性はゼロじゃねえ

145 ：名無しさん＠お腹いっぱい。：2022/06/19(日) 11:19:27.74 .net

LINEはwineで動くんかな？　(他力本願)

146 ：名無しさん＠お腹いっぱい。：2022/06/21(火) 01:05:51 .net

vncやxrdpで入ろうとするとconsolekit-daemonがエラー吐きながら1分から2分くらい待たせやがるんだが何事かわかる？

147 ：名無しさん＠お腹いっぱい。：2022/06/21(火) 06:49:29.05 .net

なぜその吐いたエラーを貼らんのか？

148 ：名無しさん＠お腹いっぱい。：2022/06/21(火) 07:33:32.12 .net

例えばこんなの
console-kit-daemon[7641]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device

> なぜその吐いたエラーを貼らんのか？
寝起きで思い出した様に書いたから

149 ：名無しさん＠お腹いっぱい。：2022/06/21(火) 08:57:19.40 .net

あと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が吐いたタイムアウトエラーの後に一応繋がりはするんだけどさ

150 ：146：2022/06/22(水) 01:08:18.49 .net

結局手直しは諦め新規インストール用データセットへinstallworld、設定複製、
chrootして各種パッケージ入れて再起動し一応解決
リフレッシュ出来たと思う事にしました

151 ：名無しさん＠お腹いっぱい。：2022/06/22(水) 14:20:58.00 .net

Desktop環境の話なのか？

152 ：名無しさん＠お腹いっぱい。：2022/06/22(水) 15:35:56.93 .net

デスクトップ環境にリモートアクセスし操作する為のプログラム
そんなこと言い出したらwineの話もアウツでは

153 ：名無しさん＠お腹いっぱい。：2022/06/29(水) 16:31:07.07 .net

amd64、i386共に wine-devel-7.8
6.0では起動しなかったbecky2が起動
https://i.imgur.com/4lfNo2n.jpg

互換性が良くなってきている模様

154 ：名無しさん＠お腹いっぱい。：2022/07/01(金) 06:33:31.92 .net

おお～Becky!動くんだね～(^_^)

155 ：名無しさん＠お腹いっぱい。：2022/07/02(土) 15:54:11.47 .net

winnyとかFLMASKはwineで動くのかな？
当時？はFLMASKのためだけに、vmwareを入れたりしてたけど

156 ：名無しさん＠お腹いっぱい。：2022/07/02(土) 17:58:32.96 .net

https://www.winehq.org/search?q=winny
https://www.winehq.org/search?q=FLMASK

157 ：名無しさん＠お腹いっぱい。：2022/07/05(火) 21:43:23 .net

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

この辺を野良ビルドで入れるのオススメ

158 ：名無しさん＠お腹いっぱい。：2022/07/07(木) 02:59:54.89 .net

github使うのヤメレ、ってニュースがあったな

159 ：名無しさん＠お腹いっぱい。：2022/07/07(木) 09:08:34.60 .net

これのことか
GitHubの利用をやめるようオープンソースソフトウェア非営利団体が強く呼びかけ - GIGAZINE
https://gigazine.net/news/20220704-software-freedom-conservancy-give-up-github/

ギガジンを鵜呑みにしてしまう人っているのか

160 ：名無しさん＠お腹いっぱい。：2022/07/07(木) 23:09:55 .net

Software Freedom Conservancyがどんな団体なのか
の方がgigazine云々より重要じゃないか？

161 ：名無しさん＠お腹いっぱい。：2022/07/08(金) 09:45:59.63 .net

余所でやってください。

162 ：FreeBSDでwimeを使っている君：2022/08/03(水) 22:10:45.53 .net

>>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で動作するという報告は見あたりませんが。

日本語利用者がこのデータベースを参考にする可能性は、
比較的に低いと思われますが、誤解を生む登録だなあ、
と思います。
日本語を常用利用していない方が登録したのかなあ。

163 ：FreeBSDでwimeを使っている君：2022/08/03(水) 22:19:31.21 .net

すでに、ずいぶん前から使っている方からすれば、いまさらでしょうが、
Emacs28.1で、文書中の全角空白（2byte空白）が赤のアンダーバーで
表示されるようになりました。
まあ、昔から設定によって全角空白などを表示させることはできましたが、
四角い形状で表示されたりして、執筆者的にはイマイチ感があり、
アンダーバー表示の控えめ感は、ありがたいと感じています。

ただ、Emacsのエコー領域に表示されるCannaの変換候補でも表示されます。
※emacs-cannaで、canna.elを使用。

不思議なことに、全角漢字の候補のうしろにも表示されています。
漢字は全角なので、まあ、おかしくはないけれど、意味がない、と
思うのですが……、ああーっ！分かったー！
変換候補の一単語ごとの区切りの空白に全角空白を使用しているので、
それに反応して赤のアンダーバーが表示されているんだ！

164 ：FreeBSDでwimeを使っている君：2022/08/03(水) 22:31:33.19 .net

(ヽ´ん`) それぼく

ごぶさたしております。
ニュー速(嫌儲)のキャラクターがカワイイので、つい見に行って
しまう執筆者君です。

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を試してみます。

165 ：FreeBSDでwimeを使っている君：2022/08/03(水) 22:38:16.29 .net

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」を入れておきました。
〔次に続く〕

166 ：FreeBSDでwimeを使っている君：2022/08/03(水) 22:52:27.66 .net

〔前からの続き〕
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

とのメッセージが出ます。

167 ：FreeBSDでwimeを使っている君：2022/08/03(水) 22:58:38.04 .net

執筆者は、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
　結果：状況変わらず。
〔次に続く〕

168 ：FreeBSDでwimeを使っている君：2022/08/03(水) 23:09:41.27 .net

〔前からの続き〕
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」にしていなかったからかなあ？　、ぐらいです。
こんな風に変わっているよ、という助言などがあれば、
よろしくお願いします。

じゃ、お夜食、食べてきます。

169 ：名無しさん＠お腹いっぱい。：2022/08/03(水) 23:45:22.27 .net

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 はインストールしていたのか

170 ：名無しさん＠お腹いっぱい。：2022/08/03(水) 23:50:56.79 .net

あと 13.0 から 13.1 にアップグレードしたのなら -kmod は ports で make し直す必要があるかと

171 ：FreeBSDでwimeを使っている君：2022/08/04(木) 00:55:00.22 .net

あわわ。即レス驚きました。ありがとうございます。
>>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」も
試しましたが状況は変わりませんでした。

172 ：名無しさん＠お腹いっぱい。：2022/08/04(木) 08:30:07.58 .net

そもそもこれだけ熱心にレポート書いてる人が
あんなしょうもない釣りやるとも思えんよね
ここの嫌儲民はどちらかと言えばあの

173 ：名無しさん＠お腹いっぱい。：2022/08/04(木) 11:44:50 .net

>>171
> ・xorg.confに「Driver "modesetting"」
modesetting じゃなくて "amdgpu" ではどうなるの？

174 ：名無しさん＠お腹いっぱい。：2022/08/04(木) 12:05:37 .net

>>171
まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる
>>165のリンク先にも書いてある

> カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。
-kmod は pkg じゃなく ports からインストールするように

175 ：FreeBSDでwimeを使っている君：2022/08/05(金) 00:52:11.29 .net

ん？　何か嫌疑が、かかってます？
古くさい釣りAAが貼られていたのも、それがらみですか？
世の中、ヒマ人が多いんですね。
嫌儲板には書いたことはありません。閲覧のみです。
そんなことよりも、wimeを、以下略。

執筆者は、UNIX板では「FreeBSDでwimeを使っている君」で
書き込みをしています。※他の板では書いていません。

仮に、初歩的な質問をする場合で、通りすがりのフリを
したくても、即バレてしまう文体なので、恥を忍んで固定名に
するつもりです。
Linux板に書く場合も、これからは同様にするつもりです。
それもこれも、すべてwimeの宣伝のためです。
なぜ宣伝するかというと、wimeを、以下略。

176 ：FreeBSDでwimeを使っている君：2022/08/05(金) 00:56:09.74 .net

さらに書き忘れていた。

執筆者が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
［終了］

ファイルの差し替え処理のようです。

177 ：FreeBSDでwimeを使っている君：2022/08/05(金) 01:02:54.85 .net

日本語入力メソッド総合スレッド＠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を追加のこと、と。

178 ：FreeBSDでwimeを使っている君：2022/08/05(金) 01:05:31.18 .net

>>174
＞まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる
そういうものとは、まったく知りませんでした。
今までカーネルモジュールを使うソフトウェアは、あまり使っておらず、
意識していませんでした。

＞>>165のリンク先にも書いてある
まことにすいませんでした。
英語なもので、さらっと読み飛ばして、ポイントっぽいところだけを
読んでいました。

>>173
CUIのコンソールの出力がなくなり、CUIのloginまでいけない状態なので、
xorg.confの評価までは、いけていないのです。

179 ：FreeBSDでwimeを使っている君：2022/08/05(金) 01:15:10.58 .net

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秒くらいかかっていたので。

180 ：名無しさん＠お腹いっぱい。：2022/08/05(金) 01:25:20.23 .net

http://mevius.5ch.net/test/read.cgi/unix/1632283136/152-153
出力先が切り替わってるとかはないか

181 ：名無しさん＠お腹いっぱい。：2022/08/05(金) 06:52:41.45 .net

うろ覚えだがgpu firmwareみたいな名前のpkgもportsで作り直しが必要だったような。

182 ：名無しさん＠お腹いっぱい。：2022/08/05(金) 13:09:12.38 .net

本当にその程度のレベルの人かと言う話でもある

183 ：名無しさん＠お腹いっぱい。：2022/08/05(金) 13:34:41.24 .net

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とは違うはずだから

184 ：名無しさん＠お腹いっぱい。：2022/08/05(金) 15:31:16.04 .net

Athlon Athlon5350なのにgpu-firmware-amd-kmod をインストールしているのが間違い
必要なのはgpu-firmware-radeon-kmodの方
分からないのならMeta ports の gpu-firmware-kmod

あと -kmod なのだから pkg ではなく ports から試すように（特にトラブってる時には）

185 ：名無しさん＠お腹いっぱい。：2022/08/05(金) 15:35:38.52 .net

amdなんて使ってないけどwikipedia見て調べてみた
180 書いたの俺だけどこれは関係無かったか

186 ：名無しさん＠お腹いっぱい。：2022/08/05(金) 16:13:19 .net

wine 等とまるで関係ないんだがCinnamonが割とまともにつかえる
足りないと思ったものは適宜追加しながらお好きな人はどうぞ
ただし画面ロックとシステム情報おまえらはまだダメか　ヤらねばヤられる

187 ：FreeBSDでwimeを使っている君：2022/08/06(土) 00:53:08.52 .net

>>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にしても、構築する個人や、
コミュニティの好みで構築されているので、長短がありますから。

188 ：FreeBSDでwimeを使っている君：2022/08/06(土) 00:59:17.91 .net

>>180 >>185
それ、サーバなマザーボードでの構成でしょ。
おそらく、後載せのRadeonR7は、「ダミーが刺さって」とのことから、
ビデオ出力に使わずに、演算に使っているのではないか、と感じました。

執筆者君の環境の場合、VGAを複数認識するような高価な環境ではなく、
ビデオカードをさすと、APU側のビデオ機能は無効になるマザーボードが
ある、という、ローエンド環境に、ありがちな環境です。

もちろん、この試行中でも、いちいちビデオカードを外しながら
試していました。
おかげで、アルミ筐体の拡張スロットのネジがゆるくなってきました。

189 ：FreeBSDでwimeを使っている君：2022/08/06(土) 01:02:30.02 .net

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

190 ：FreeBSDでwimeを使っている君：2022/08/06(土) 01:16:46.45 .net

なんだか、入門者の犬小屋スレみたいになっていますが、
みなさん、ありがとうございます。

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」もね！　（田中みな実さんぽくキリッとキメ顔）

191 ：名無しさん＠お腹いっぱい。：2022/08/06(土) 01:29:59.85 .net

>>189
Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると
~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ
(emulators/i386-wine(含-devel)の頃には起こらなかった挙動)

192 ：名無しさん＠お腹いっぱい。：2022/08/06(土) 17:28:29.19 .net

>>182
その程度のレベルだったな

193 ：FreeBSDでwimeを使っている君：2022/08/06(土) 23:59:32 .net

>>182 >>192
執筆者が「その程度のレベル」なのは、
前スレ当時から自己紹介しております。キリッ。

自分でKernelをReConfigureした場合、Ports由来のKernelModuleを
再makeしないといけない、というのは知っていましたが、
「まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる」、
というのは知りませんでしたし、さらに、標準のKernelで「.1」の差が
問題になる、というのも認識していませんでした。

この後に「その程度のレベル」な、謝罪のレスがあります。

194 ：FreeBSDでwimeを使っている君：2022/08/07(日) 00:00:32 .net

>>191
執筆者の試行では、32bit環境の.wineのまま（新規生成していない）で、
WOW64なWineで32bitなソフトウェアが動きました。
WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が
できていました。

195 ：FreeBSDでwimeを使っている君：2022/08/07(日) 00:01:51 .net

まずは、おわびです（ガバッ、土下座）。

お散歩がてら「さがわ@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
(deleted an unsolicited ad)

196 ：FreeBSDでwimeを使っている君：2022/08/07(日) 00:04:36 .net

で、前スレ951氏助言の
「setenv WINEDLLPATH /usr/local/lib32/wine」との設定をコメントし、

/etc/fstabに「proc /proc procfs rw 0 0」と、設定をして、
winecfgを起動すると、普通にwinecfgが起動しました。

執筆者が、procをマウントしていれば、騒ぐ必要がなかったミスとなります。
前スレの951氏にはWineのソースを調べ、助言レスをさせる、という手間を
かけさせて、まことに申し訳ありませんでした。
Linux板のWineスレでも質問をして、申し訳ありませんでした
執筆者の不注意なミスにより、心配した方々に迷惑をかけて、
本当に申し訳ありませんでした。

197 ：FreeBSDでwimeを使っている君：2022/08/07(日) 00:16:44 .net

あれれ？

>>195 のWineのエラーメッセージ引用のかぎカッコ中に
「 h t t p : / / 」とありますが、執筆者は書いておりません。
投稿時に自動的についたものと思われます。

198 ：名無しさん＠お腹いっぱい。：2022/08/07(日) 00:54:25.07 .net

>>196
インストールのメッセージくらい読めというところだが
貴方が前スレの992に貼ったFreeBSD Forumsでも
そのエラーの回避法としてprocのことが書いてある

199 ：名無しさん＠お腹いっぱい。：2022/08/07(日) 03:52:07.25 .net

>>193
そうか　ならばもう大体把握した

200 ：名無しさん＠お腹いっぱい。：2022/08/07(日) 07:49:48.49 .net

>>195
当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。
ついでにそれがportsに反映された時期も。

四ヶ月後に再度見に行くか？ったらまあしないだろうし
そもそも当時の作業者が初耳！してるくらいだから。

あとprocマウントしてても多分そのエラーは当時は出てたと思う。
なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。

201 ：FreeBSDでwimeを使っている君：2022/08/07(日) 22:03:53.46 .net

>>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.」
と書かれました。（注）

〔次に続く〕

202 ：FreeBSDでwimeを使っている君：2022/08/07(日) 22:05:49.33 .net

〔前からの続き〕

前スレ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を閲覧して
　検証することができないのですが。

〔次に続く〕

203 ：FreeBSDでwimeを使っている君：2022/08/07(日) 22:07:33.37 .net

〔前からの続き〕

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 .net

>>202
> 　もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して
> 　検証することができないのですが。

パッケージを保存しておいた実機で各種検証する人の書く事とも思えんが

205 ：名無しさん＠お腹いっぱい。：2022/08/08(月) 04:41:56.49 .net

何でfreshportsなのかという疑問はあるが
https://cgit.freebsd.org/ports/log/emulators/i386-wine
https://cgit.freebsd.org/ports/tree/emulators/i386-wine?id=99af2239fc168cc980f622c3f98b6ab21af873aa

206 ：FreeBSDでwimeを使っている君：2022/08/08(月) 20:52:30.49 .net

>>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のパッチがあたるかは、執筆者は未検証。
と、書きましたが、この迂遠な手抜き手法は、そうするしかなかった、と、
いうことになります。

207 ：FreeBSDでwimeを使っている君：2022/08/08(月) 20:59:38.99 .net

「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

208 ：名無しさん＠お腹いっぱい。：2022/08/08(月) 21:02:31.20 .net

>>206
それが Forum とかでの freebsd の ports は multilib をサポートしてないから
という発言につながるわけですな

209 ：FreeBSDでwimeを使っている君：2022/08/08(月) 21:04:50.29 .net

この件について、執筆者自身も、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の現状を
試さないといけないな。時間ができたら試します。

210 ：FreeBSDでwimeを使っている君：2022/08/08(月) 21:16:23.56 .net

>>208
あ、連続レス中にはさんでしまった。

＞multilib をサポートしてないからという発言に

ああ。そういう意味、そういうこと、だったのか。
なんの話だろう、特殊なライブラリ？　とか思っていました。
すいません、forumsの内容も、英語のため、精読していませんでした。

211 ：6：2022/08/08(月) 21:21:25.71 .net

そう言えばprocfsはふつうにマウントしてましたねえ
と言うか sysutils/desktop-installer でDE入れると勝手に設定されるので

212 ：FreeBSDでwimeを使っている君：2022/08/15(月) 00:08:53.38 .net

>>211
ああ、やっぱり。
「wine: could not load」の件は、まさに「おま環」（お前の環境特有）
だった、ということでした。大騒ぎしてすいませんでした。

fstabの見直しで、procfsの設定に追加して、tmpfsに128MBを設定したという、
あつものに懲りてなますを吹くかのような執筆者君です。

あと、i386-wineが出てきた直後ぐらいに、2chで、i386-wineが待てない人用、
として手作業の方法をレスしていた方が、Portsはユーザが、makeしてinstall
することができないので、i386-wine的なものに対応しづらい、と
読んだことがあったような気がする。
※技評のWebの後藤大地氏のFreeBSDの記事で読んだのかもしれない。

Linuxもバイナリ配布が主で、ports的な仕組みからバイナリを作って
いるんだろうけど、どうしているのかなあ。

213 ：FreeBSDでwimeを使っている君：2022/08/15(月) 00:10:31.92 .net

手順の再まとめをする時用にアンカーを打っておこう。 >>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を選択する。

という結果になりました。

214 ：FreeBSDでwimeを使っている君：2022/08/15(月) 00:13:36.79 .net

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

215 ：FreeBSDでwimeを使っている君：2022/08/15(月) 00:17:44.71 .net

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