22/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を使っている君
22/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」を追記。
出典：URLﾘﾝｸ(running-dog.net)
結果：状況変わらず。
〔次に続く〕
168:FreeBSDでwimeを使っている君
22/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:名無しさん＠お腹いっぱい。
22/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:名無しさん＠お腹いっぱい。
22/08/03 23:50:56.79 .net
あと 13.0 から 13.1 にアップグレードしたのなら -kmod は ports で make し直す必要があるかと
171:FreeBSDでwimeを使っている君
22/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:名無しさん＠お腹いっぱい。
22/08/04 08:30:07.58 .net
そもそもこれだけ熱心にレポート書いてる人が
あんなしょうもない釣りやるとも思えんよね
ここの嫌儲民はどちらかと言えばあの
173:名無しさん＠お腹いっぱい。
22/08/04 11:44:50 .net
>>171
> ・xorg.confに「Driver "modesetting"」
modesetting じゃなくて "amdgpu" ではどうなるの？
174:名無しさん＠お腹いっぱい。
22/08/04 12:05:37 .net
>>171
まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる
>>165のリンク先にも書いてある
> カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。
-kmod は pkg じゃなく ports からインストールするように
175:FreeBSDでwimeを使っている君
22/08/05 00:52:11.29 .net
ん？ 何か嫌疑が、かかってます？
古くさい釣りAAが貼られていたのも、それがらみですか？
世の中、ヒマ人が多いんですね。
嫌儲板には書いたことはありません。閲覧のみです。
そんなことよりも、wimeを、以下略。
執筆者は、UNIX板では「FreeBSDでwimeを使っている君」で
書き込みをしています。※他の板では書いていません。
仮に、初歩的な質問をする場合で、通りすがりのフリを
したくても、即バレてしまう文体なので、恥を忍んで固定名に
するつもりです。
Linux板に書く場合も、これからは同様にするつもりです。
それもこれも、すべてwimeの宣伝のためです。
なぜ宣伝するかというと、wimeを、以下略。
176:FreeBSDでwimeを使っている君
22/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を使っている君
22/08/05 01:02:54.85 .net
日本語入力メソッド総合スレッド＠Linux＠5ch掲示板
ｽﾚﾘﾝｸ(linux板: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を使っている君
22/08/05 01:05:31.18 .net
>>174
＞まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる
そういうものとは、まったく知りませんでした。
今までカーネルモジュールを使うソフトウェアは、あまり使っておらず、
意識していませんでした。
＞>>165のリンク先にも書いてある
まことにすいませんでした。
英語なもので、さらっと読み飛ばして、ポイントっぽいところだけを
読んでいました。
>>173
CUIのコンソールの出力がなくなり、CUIのloginまでいけない状態なので、
xorg.confの評価までは、いけていないのです。
179:FreeBSDでwimeを使っている君
22/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 ※注
注 URLﾘﾝｸ(running-dog.net)に
書いてあったのだが、すでに入っていた。
○以下の設定をした。
・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:名無しさん＠お腹いっぱい。
22/08/05 01:25:20.23 .net
ｽﾚﾘﾝｸ(unix板:152番)-153
出力先が切り替わってるとかはないか
181:名無しさん＠お腹いっぱい。
22/08/05 06:52:41.45 .net
うろ覚えだがgpu firmwareみたいな名前のpkgもportsで作り直しが必要だったような。
182:名無しさん＠お腹いっぱい。
22/08/05 13:09:12.38 .net
本当にその程度のレベルの人かと言う話でもある
183:名無しさん＠お腹いっぱい。
22/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:名無しさん＠お腹いっぱい。
22/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:名無しさん＠お腹いっぱい。
22/08/05 15:35:38.52 .net
amdなんて使ってないけどwikipedia見て調べてみた
180 書いたの俺だけどこれは関係無かったか
186:名無しさん＠お腹いっぱい。
22/08/05 16:13:19 .net
wine 等とまるで関係ないんだがCinnamonが割とまともにつかえる
足りないと思ったものは適宜追加しながらお好きな人はどうぞ
ただし画面ロックとシステム情報おまえらはまだダメか ヤらねばヤられる
187:FreeBSDでwimeを使っている君
22/08/06 00:53:08.52 .net
>>175
すいません。
Linux板のWineスレで、すでに「FreeBSDでwimeを使っている君」で
書いていました。
ｽﾚﾘﾝｸ(linux板:449番)
>>186
Wineのスレではないので、良さげっぽかったり、便利っぽかったり、な
情報は書いてください。
スレタイは「Office/Desktop環境」となっていますが、
Unix系OSでOfficeソフトを使うような日常生活環境を構築するための
情報交換をしたい、人柱報告（>>4など）も読みたい、というのが
スレの趣旨です。
Desktop環境にしても、LinuxのDistributionにしても、構築する個人や、
コミュニティの好みで構築されているので、長短がありますから。
188:FreeBSDでwimeを使っている君
22/08/06 00:59:17.91 .net
>>180 >>185
それ、サーバなマザーボードでの構成でしょ。
おそらく、後載せのRadeonR7は、「ダミーが刺さって」とのことから、
ビデオ出力に使わずに、演算に使っているのではないか、と感じました。
執筆者君の環境の場合、VGAを複数認識するような高価な環境ではなく、
ビデオカードをさすと、APU側のビデオ機能は無効になるマザーボードが
ある、という、ローエンド環境に、ありがちな環境です。
もちろん、この試行中でも、いちいちビデオカードを外しながら
試していました。
おかげで、アルミ筐体の拡張スロットのネジがゆるくなってきました。
189:FreeBSDでwimeを使っている君
22/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は参考まで。
ｽﾚﾘﾝｸ(linux板:51-番)n
ｽﾚﾘﾝｸ(linux板:442番)-n
ｽﾚﾘﾝｸ(linux板:679番)-n
190:FreeBSDでwimeを使っている君
22/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:名無しさん＠お腹いっぱい。
22/08/06 01:29:59.85 .net
>>189
Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると
~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ
(emulators/i386-wine(含-devel)の頃には起こらなかった挙動)
192:名無しさん＠お腹いっぱい。
22/08/06 17:28:29.19 .net
>>182
その程度のレベルだったな
193:FreeBSDでwimeを使っている君
22/08/06 23:59:32 .net
>>182 >>192
執筆者が「その程度のレベル」なのは、
前スレ当時から自己紹介しております。キリッ。
自分でKernelをReConfigureした場合、Ports由来のKernelModuleを
再makeしないといけない、というのは知っていましたが、
「まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる」、
というのは知りませんでしたし、さらに、標準のKernelで「.1」の差が
問題になる、というのも認識していませんでした。
この後に「その程度のレベル」な、謝罪のレスがあります。
194:FreeBSDでwimeを使っている君
22/08/07 00:00:32 .net
>>191
執筆者の試行では、32bit環境の.wineのまま（新規生成していない）で、
WOW64なWineで32bitなソフトウェアが動きました。
WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が
できていました。
195:FreeBSDでwimeを使っている君
22/08/07 00:01:51 .net
まずは、おわびです（ガバッ、土下座）。
お散歩がてら「さがわ@sagawa_aki」氏のTwitterを見ていると
以下のようなTweetがReTweetされていました。
URLﾘﾝｸ(twitter.com)
＞晋太郎@scp1979
＞FreeBSD13.1でWineを起動したら「wine: could not load URLﾘﾝｸ(ntdll.so:)<) (null)」で
このTweetより先に、大騒ぎした張本人だからです。
※大騒ぎの初出は、以下のURL、2020/12/11(金)。
ｽﾚﾘﾝｸ(unix板:919番)-921
ｽﾚﾘﾝｸ(unix板:951番)
ｽﾚﾘﾝｸ(unix板:952番)-953
ｽﾚﾘﾝｸ(linux板:449番)
(deleted an unsolicited ad)
196:FreeBSDでwimeを使っている君
22/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を使っている君
22/08/07 00:16:44 .net
あれれ？
>>195 のWineのエラーメッセージ引用のかぎカッコ中に
「 h t t p : / / 」とありますが、執筆者は書いておりません。
投稿時に自動的についたものと思われます。
198:名無しさん＠お腹いっぱい。
22/08/07 00:54:25.07 .net
>>196
インストールのメッセージくらい読めというところだが
貴方が前スレの992に貼ったFreeBSD Forumsでも
そのエラーの回避法としてprocのことが書いてある
199:名無しさん＠お腹いっぱい。
22/08/07 03:52:07.25 .net
>>193
そうか ならばもう大体把握した
200:名無しさん＠お腹いっぱい。
22/08/07 07:49:48.49 .net
>>195
当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。
ついでにそれがportsに反映された時期も。
四ヶ月後に再度見に行くか？ったらまあしないだろうし
そもそも当時の作業者が初耳！してるくらいだから。
あとprocマウントしてても多分そのエラーは当時は出てたと思う。
なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。
201:FreeBSDでwimeを使っている君
22/08/07 22:03:53.46 .net
>>198-200
○「wine: could not load ntdll . so : (null)」と出る件
※5chに書き込んだ時点でゴミがつくので1byte空白をはさみました
前スレ919(2020/12/11)の執筆者のレス時点では、
URLﾘﾝｸ(forums.freebsd.org)
の、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を使っている君
22/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を使っている君
22/08/07 22:07:33.37 .net
〔前からの続き〕
URLﾘﾝｸ(bugs.freebsd.org)
で、「wine: could not load」の件が報告され、
URLﾘﾝｸ(bugs.freebsd.org)
と、関係があると思われていたが、違うようだ、と、なったようだ。
「id=257105」は閉じられて、その後、どうなったかは分からない。
URLﾘﾝｸ(www.freshports.org)
では、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:名無しさん＠お腹いっぱい。
22/08/08 04:07:14.04 .net
>>202
> もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して
> 検証することができないのですが。
パッケージを保存しておいた実機で各種検証する人の書く事とも思えんが
205:名無しさん＠お腹いっぱい。
22/08/08 04:41:56.49 .net
何でfreshportsなのかという疑問はあるが
URLﾘﾝｸ(cgit.freebsd.org)
URLﾘﾝｸ(cgit.freebsd.org)
206:FreeBSDでwimeを使っている君
22/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を使っている君
22/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:名無しさん＠お腹いっぱい。
22/08/08 21:02:31.20 .net
>>206
それが Forum とかでの freebsd の ports は multilib をサポートしてないから
という発言につながるわけですな
209:FreeBSDでwimeを使っている君
22/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を使っている君
22/08/08 21:16:23.56 .net
>>208
あ、連続レス中にはさんでしまった。
＞multilib をサポートしてないからという発言に
ああ。そういう意味、そういうこと、だったのか。
なんの話だろう、特殊なライブラリ？ とか思っていました。
すいません、forumsの内容も、英語のため、精読していませんでした。
211:6
22/08/08 21:21:25.71 .net
そう言えばprocfsはふつうにマウントしてましたねえ
と言うか sysutils/desktop-installer でDE入れると勝手に設定されるので
212:FreeBSDでwimeを使っている君
22/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を使っている君
22/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を使っている君
22/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を使っている君
22/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
216:FreeBSDでwimeを使っている君
22/08/15 00:21:48.92 .net
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されたものが提供されることになるでしょう。
217:FreeBSDでwimeを使っている君
22/08/15 00:47:38.25 .net
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は違いました。
218:FreeBSDでwimeを使っている君
22/08/15 00:48:58.62 .net
再まとめ用：
「wimeのパッチはリネームも編集もせずにそのまま置けばよい」>>11
「Wine7系からはパッチを当てても、imm.c.origとリネームされた
オリジナルのソースファイルは残らなくなった」
219:FreeBSDでwimeを使っている君
22/08/15 00:51:39.18 .net
FreeBSD13.1R/amd64で、wine-devel7.14(WOW64)を入れて、
「/usr/local/share/wine/pkg32.sh install wine mesa-dri」
としてホームディレクトリ以下にWineの32bit環境を展開しよう
としたら、なぜか、wine-6.0.4_1,1.pkgをfetchしています。
もちろん、
＞wine [wine-6.0.4] and wine64 [wine-7.14] versions do not match!
と言われました。「pkg32.sh upgrade」してもupgrade済みとなります。
FreeBSD13.1R/amd64にwine-6.0.4を入れ、同様に32bit環境を展開したら
正常に展開されました。
これだと、wineとi386-wineに分かれていた時と変わりませんね。
Alexander88207氏は、どう思っているのだろう。
220:名無しさん＠お腹いっぱい。
22/08/15 00:56:56.20 .net
>>219
そこは
/usr/local/share/wine/pkg32.sh install wine-devel mesa-dri
だろ
221:FreeBSDでwimeを使っている君
22/08/15 00:57:11.65 .net
>>128 に、
＞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表示がされる。
という謎の現象を書きましたが、その後も、ちょくちょく、
その現象は発生していました。
FreeBSD13.1R/amd64
Wine(i386-wine-devel-6.12)(13.0のもの)
wime4.1.5(FreeBSD13.1R/i386でgmake)
ATOK17(2004)
emacs-canna-28.1
の環境下では、今のところ出ていません。
222:FreeBSDでwimeを使っている君
22/08/15 01:03:40.90 .net
>>219 >>220
あ゛！ あ゛！ あ゛！
間違っていた！
そりゃあ、そうですよね！
pkgのメッセージをそのままコピペしただけなんですけどね！
いや、言い訳にはならないな！
間違ってました！ すいませんでした！
223:FreeBSDでwimeを使っている君
22/08/15 01:12:12.96 .net
執筆者としては、
FreeBSD13.1R/amd64とwimeによるimm32.dllの問題 >>217 で、
FreeBSDが14などになって、今、取り置きしている、i386-wineが
動かなくなったら、amd64からi386に戻るかもしれません。
Windowsの32bitソフトウェアを使いたいがために、
FreeBSDをi386(Tier2)に戻すのは執筆者ぐらいかと思います。
もっと、FreeBSDでwimeを使う方が増えてくれれば、
執筆者は質問者側に回れるのですが（昔からの野望）。
ただし、以前、試したのですが、Microsoft Office2000添付の
IME2000はWineにはインストールできませんでした。
※wime公式と同じ結果。
224:名無しさん＠お腹いっぱい。
22/08/15 01:19:28.89 .net
知らないかもしれないので書いとくが
amd64でi386-wineはビルドできる
URLﾘﾝｸ(wiki.freebsd.org)
225:FreeBSDでwimeを使っている君
22/08/15 01:29:49.96 .net
>>224
その記事は、昔から知っていたんですが、
ほぼ、理解できていませんでした。
今は、うっすら理解できます。
226:FreeBSDでwimeを使っている君
22/08/15 01:32:26.53 .net
今のところ、Windows用のフリーのIMEはGoogle日本語入力しかなく、
それなら、mozcを使うだろうしなあ。
関係ないけど、販売版のWnn8もFreeBSDへの対応は遅すぎますし。
WXGも古すぎて動かしづらいしなあ。
まあ、手持ちのWindows用のIME（注）があれば、
ぜひ、wimeを使ってみてください。
wimeへのWineへのパッチは、ほぼATOK用ですから、素のWineで
wimeが使える？、との期待が持てます。
注：
URLﾘﾝｸ(www4.airnet.ne.jp)
URLﾘﾝｸ(www4.airnet.ne.jp)
上記記事によると、Windows用の 3rd PartyのIMEは、
あまり、ないですね。
Windows3.1時代のIMEだと、16bitコードがあると、Wineだけでなく、
DOSBoxも必要になるうえ、動くかどうかも分かりませんし。
そもそも変換効率を上げたいがための、Wine+wime+AOTKなのに、
Windows3.1時代のIMEを試すくらいなら、今どきのUnixな
かな漢字変換を使いますよね。
まあ、FepBridgeでDOSのFEPをUnixで、の時代があったとはいえ、
ですが。
>>219 の件、すいませんでした。
※なぜか、>>98 では wine-develで走らせているのに
「versions do not match!」と言われているな。なぜだろう。
じゃ、夜食を食べてきます。
227:FreeBSDでwimeを使っている君
22/08/16 00:44:57.40 .net
>>219-222
現在のWineの「versions do not match!」の件。
たしかに、>>98 の時は、wineでも、wine-develでも
ダメだったような気がする。
執筆者のスキルは怪しいですから、どなたか、お手すきの時で
結構ですから、Wineを試す時に、32bit環境展開の追試行を
してみてくださいませんか。
これからは、i386-wine的なものを実現したければ、
以下のように、自分でなんとかするしかありませんね。
>>224 の URLﾘﾝｸ(wiki.freebsd.org)
>>212 の「待てない人用」のレス
ｽﾚﾘﾝｸ(unix板:91番)-n
ｽﾚﾘﾝｸ(unix板:104番)-n
228:FreeBSDでwimeを使っている君
22/08/16 01:07:40.43 .net
>>227 に追加。
2009年12月16日 FreeBSD/amd64でWineを実行する方法（回避策に近い）
URLﾘﾝｸ(gihyo.jp)
※技評のサイト、見た目が今風に変わりましたね。
Wine on FreeBSD/amd64 - kszk’s blog
URLﾘﾝｸ(kszk-beta.hatenadiary.org)
※ここも昔、見たような気がする。
FreeBSD Wine Configuration
URLﾘﾝｸ(linuxhint.com)
※ここも昔、見たような気がする。
Installing wine under FreeBSD 8 amd64 - jan0schs deck
URLﾘﾝｸ(makandracards.com)
※初見のような気がする。
Installing wine under FreeBSD 8 amd64
URLﾘﾝｸ(www.jan0sch.de)
※初見のような気がする。
いつも思うんですが、amd64でi386環境をbuildworldするなら、
単純に、インストーラから、i386のbaseを持ってきて、
展開してもいいのではないかと思う。
229:名無しさん＠お腹いっぱい。
22/08/16 08:22:02.20 .net
スキル云々以前に先ずサラの環境で試してみろよ
230:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
スクショも見たい
231:FreeBSDでwimeを使っている君
22/08/18 01:53:45.55 .net
やだぁ。こういうこと？ しようがないわね（意味深）。
環境：FreeBSD13.1R/amd64
：Wine(i386-wine-devel-6.12)(13.0のもの)
：wime4.1.5(FreeBSD13.1R/i386でgmake)
：Windows用ATOK17(2004)
：emacs-canna-28.1/ng-canna/kinput2 -canna
Cannaとして使っているだけなので、ATOKのIMEのパレットは出ません。
もちろん、ATOKが出す変換候補のGUI表示も出ません。
両方とも、むかしは、何かのタイミングで出ることがありましたが、
描画されるだけで機能しません。
この描画は勝手に消えてくれないので、ATOKのプロパティを
表示（wimectrl -s）して終了すると、一緒に消えます。
※ごくごく、まれに起こる、この現象のためにも、ATOKのプロパティは
機能しないと困るのです（>>95 の理由）。
ATOKのプロパティを表示しながら、漢字変換はできないので、
２枚になりました。
いま気づきましたが、二重敬語の補正の指摘が、左上に出ますが、
表示されるだけなので、指示通りのキー打鍵をしても、
自動的に補正されません。表示されるだけです。
確定などの、次の動作をすると、指摘は消えてくれます。
※imgurはアカウントを取るのが面倒なのでimepicで。
URLﾘﾝｸ(imepic.jp)
URLﾘﾝｸ(imepic.jp)
232:名無しさん＠お腹いっぱい。
22/08/18 03:38:54.54 .net
そう言うズレた事やるなら今後俺が何かを手助けする事は無い
233:名無しさん＠お腹いっぱい。
22/08/18 03:54:40.58 .net
libX11.so.6 が無いのは解決してなかったのか
これは x11/libX11 でインストールされる
libxcb, libXau, libXdmcp にも依存してるけど
試してないけど
/usr/local/share/wine/pkg32.sh install libX11
で解決しないか
あとimm32だけどi386のwineをpkg32.shでインストールした後
パッチをあてたimm32.dllをコピーするんじゃなくて
i386のportsで make package でパッチをあてたwineのパッケージをつくって
そのi386のwineを
/usr/local/share/wine/pkg32.sh add 「パッケージのファイル名」
でインストールしてみたらどうなるの
234:名無しさん＠お腹いっぱい。
22/08/18 06:09:46.95 .net
だけど libX11 は mesa-dri の依存関係でインストールされる筈だよな
235:名無しさん＠お腹いっぱい。
22/08/18 08:38:14.19 .net
> versions do not match!
もし、パッケージマネージャに複数のリポジトリを登録してるなら
pkg32.shを呼ぶときにリポジトリを指定しないと混ざって不整合起こす可能性があるよ。
こっちの環境でそれ喰らって少し悩んだけど結局pkgを呼んでるわけだからオプション付けるだけ。
wine-devel 7.8.1でjanestyleの通信回りが動かなかった悲しみ。
236:名無しさん＠お腹いっぱい。
22/08/18 12:17:46.80 .net
>>227
これでいいんか？
URLﾘﾝｸ(i.imgur.com)
>>231
ここまでの流れをざっと見てみると何がしたいのかサッパリわからんな
おまかん自慢？
237:名無しさん＠お腹いっぱい。
22/08/18 12:31:47.24 .net
ちゃんと読まないからwineじゃなくてwine-develの事だと分からないんだろ
238:名無しさん＠お腹いっぱい。
22/08/18 12:46:11.29 .net
ちゃんと読めば「既存パッケージで32bitアプリも64bitアプリも同時に動かせるのに何故過去の遺産に拘っているのか」
と首を傾げているって事では
239:名無しさん＠お腹いっぱい。
22/08/18 12:54:05.82 .net
それは消えた i386-wine-devel のほうが今の wine よりバージョンが上だからでは
そして wine-devel(7系？)では imm32.dll.so が無くなったせいなのか wime が動かないと
240:名無しさん＠お腹いっぱい。
22/08/18 13:06:55.34 .net
バージョンが上とかじゃないな
wimeの作成環境に書いてあるのがwineのstableじゃなくて開発版だから
wine-develなのか
241:名無しさん＠お腹いっぱい。
22/08/18 13:16:54.17 .net
検証不可能だが要はこれが望む環境で使えんライブラリであると
URLﾘﾝｸ(i.imgur.com)
何をゴチャゴチャビルドだのdevelだの書いていると思ったわ
/procがどうのこうのだの切り分けが半端だったんだから先ずは不満な人が
既存パッケージで作れる環境でいちから試せば少しでも前進するんじゃね
242:名無しさん＠お腹いっぱい。
22/08/18 13:25:16.41 .net
パッチ当てが必要とか書いてるみたいだけど必要ならソースあるよ
URLﾘﾝｸ(github.com)
243:名無しさん＠お腹いっぱい。
22/08/18 13:30:26.82 .net
>wine-devel(7系？)では imm32.dll.so が無くなったせいなのか
URLﾘﾝｸ(github.com)
244:名無しさん＠お腹いっぱい。
22/08/18 13:39:59.71 .net
imm32.dll.so と書いてるのはwime君であってwimeの作者じゃないけどな
作者は imm.c にパッチをあてろと書いてるだけ
>>242
wine-devel でも imm.c はある
というか>>217-218見るとパッチがあたって無い
wine-devel/files に置くんじゃなくて
make patch の後手作業でファイルを変更してみたら
245:名無しさん＠お腹いっぱい。
22/08/18 13:54:20.83 .net
ソース置き場まとめ
wime君がつかってるやつ
URLﾘﾝｸ(github.com)
現行pkgのやつ(wine-6.0.4)
URLﾘﾝｸ(github.com)
quarterlyのwine-develのやつ(wine-devel-7.8)
URLﾘﾝｸ(github.com)
246:名無しさん＠お腹いっぱい。
22/08/18 14:04:24.57 .net
ソースが無いって話はしてないぞ
imm32.dll.so が無くなった
でも imm32.dll.so なんて言ってるのはwime君で作者じゃない
linux でも7系では imm32.dll.so は無いようだ
247:名無しさん＠お腹いっぱい。
22/08/18 14:14:21.91 .net
つまり氏のコレは早とちりか何かと
206 名前：FreeBSDでwimeを使っている君 []： 2022/08/08(月) 20:52:30.49
注：
i386-wineで32bitなATOKを使う場合、32bitなファイル（imm32.dll.so）に
wimeのパッチをあてる必要がありますが、i386-wineは、バイナリ配布の
ため、i386-wineのportsでwimeのパッチをあてるのは、そもそも無理だった、
ということになります
248:名無しさん＠お腹いっぱい。
22/08/18 14:24:36.64 .net
>imm32.dll.so
あるよ latestの wine-devel-7.14,1 i386のパッケージを展開し確認
quarterly の7.8に同梱されているかはしらん
249:248
22/08/18 14:26:16.81 .net
>>248
あ、微妙に違ってた
imm32.dll はあるが imm32.dll.so というファイルは無い
250:248
22/08/18 14:29:49.29 .net
>>249
>imm32.dll
マジックナンバー文字列は「MZ」
251:名無しさん＠お腹いっぱい。
22/08/18 14:36:24.10 .net
作者が書いてるのは imm.c にパッチをあてろ(wime-4.1.5 の環境は wine 7.7)
wime君はパッチが影響するのは imm32.dll.so と判断した
6系まではそれでよかったのかもしれないが
7系では imm32.dll.so は無くなった
だからファイルをコピーするんじゃなくてパッチをあてた wine 全体をインストールするように>>233
でもよく読んだら wine-devel(7系)ではパッチがあたってない
だからとりあえず手作業でファイルを変更してみては >>244
>>248-249
i386 の quarterly の wine-devel-7.8,1.pkg、latest の wine-devel-7.8,1.pkg
には無い +MANIFEST にも無い
252:名無しさん＠お腹いっぱい。
22/08/18 15:05:31.79 .net
> i386 の quarterly の wine-devel-7.8,1.pkg
> には無い +MANIFEST にも無い
コレでええの？elfバイナリでは無い様だが
URLﾘﾝｸ(i.imgur.com)
> latest の wine-devel-7.8,1.pkg
現在pkgに存在しないバージョンの様だが更新していないportsでもつかってんのかな
253:名無しさん＠お腹いっぱい。
22/08/18 15:15:11.74 .net
> 現在pkgに存在しないバージョンの様だが更新していないportsでもつかってんのかな
コピペミス
wine-devel-7.14,1.pkg
254:名無しさん＠お腹いっぱい。
22/08/18 15:22:14.31 .net
こちらもelfじゃないみたいだけど
URLﾘﾝｸ(i.imgur.com)
255:名無しさん＠お腹いっぱい。
22/08/18 15:37:35.04 .net
>>231
twm愛好家なんだ よかったらあっちのスレも盛り上げてよ
256:名無しさん＠お腹いっぱい。
22/08/18 16:48:03.06 .net
13.1-RELEASE-p1 quarterly
いつの間にか sysutils/fusefs-smbnetfs がふつうに使える様になっとる
クライアントマシンとしてSMB2以降を使いたい人にはオススメ
257:名無しさん＠お腹いっぱい。
22/08/18 23:05:18.33 .net
時代はarmやで
258:FreeBSDでwimeを使っている君
22/08/19 02:13:23.86 .net
>>232
ん？ よく意味が分からないです……。
悪いところがあれば直します。
助言者が欲しくて書いているようなものですから。
>>255
「あっち」？
259:FreeBSDでwimeを使っている君
22/08/19 02:14:57.99 .net
あらやだ、すごいことになってるわ、困ったわね（意味深）。
画像のチカラってすごいのかな（意味深）。
※こんなボケを書く雰囲気ではないんですけれど一応。
260:FreeBSDでwimeを使っている君
22/08/19 02:29:34.04 .net
個別にレスできませんが、誤解を解きたいです。
>>239 の通りで、執筆者が今のところ、i386-wine-devel(6.12)を
使うのは、pkg(8)も、Portsも、現在のWineは6.0.4だからです。
なぜ、Wineのdevel版なのか、は、さがわ@sagawa_aki氏の修正が、
即、入っていたりして、新しいからです。
今までWineの「devel」で困ったことは、Wine1系の時に、
まったく動かなかったことが、２度あっただけで、
数日後に即、修正版が出ましたから、
Wineの「開発版」とはいえ、信頼しているから、です。
日本語入力メソッド総合スレッド＠Linux＠5ch掲示板
ｽﾚﾘﾝｸ(linux板:30番)
でも勧めましたし。
261:FreeBSDでwimeを使っている君
22/08/19 02:32:34.73 .net
>>217 の試行では、wine-devel(7.14)がPortsのVersion
でしたので、pkg(8)も、一時的に、latestにしました。
>>244
＞imm32.dll.so と書いてるのはwime君であって
その通りで、imm32.dll.soとか、imm32.dllとか、
のことを書いているのは執筆者本人のみです。
「wime」ではパッチをあてろとしか言っていません。
262:FreeBSDでwimeを使っている君
22/08/19 02:34:20.13 .net
>>246 >>251 の通りです。>>217 の繰り返しになりますが、
amd64のpkg(8)のwine-devel(7.14)では、imm32.dllは、
ホームディレクトリ以下の、
~/.i386-wine-pkg/usr/local/lib/wine/fakedlls/imm32.dll
~/.wine/drive_c/windows/system32/imm32.dll
の下にしかなく、ファイルサイズもかなり小さいうえ、
サイズも同じでした。「fakedlls」だからでしょうか。
※i386のPortsのwine-devel(7.14)では、以下に存在します。
/usr/local/lib/wine/i386-windows/imm32.dll
※アンカーをつけすぎると書き込めないので細切れになります。
〔次に続く〕
263:FreeBSDでwimeを使っている君
22/08/19 02:38:08.60 .net
〔前からの続き〕
i386で作った（パッチをあてた）imm32.dllの場合、
Ｃ言語は読めませんが、imm32.cにパッチ内の文字列が
含まれていたので、imm32.dllには正常にパッチがあたって
いると判断しました。
※以前は、FreeBSDのPortsで「imm.c」にパッチをあてると
「imm.c.orig」などと元のファイルが残りましたが、
今は、残りません。
>>217 の（注）でも書きましたが、i386上での話ですが、
pkg(8)標準のimm32.dll(135168byte)と、wimeのパッチを
当てたPortsのものとでは、サイズは同じですが、md5が
違ったので、正常にパッチがあたったものと考えています。
imm32.dll.soがなくなったのは、Wine7系以降、
「分離作業が行われているから」か、と思います。
264:FreeBSDでwimeを使っている君
22/08/19 02:41:19.31 .net
>>69 の時点で、
FreeBSD13.0R/amd64で、Wine7.0.r2(WOW64対応版)で
wimeを動かそうと試行しました。
>>67 で、
Wineにwimeのパッチ（imm-magic-1.7.3）をあてたのは、
FreeBSD13.0R/i386上のWine7.2(WOW64対応版)です。
その時点で、「imm32.dll.so」でなく、「imm32.dll」が
できるようになっていました。
できた「imm32.dll」を、FreeBSD13.0R/amd64上の
Wine7.0.r2(WOW64対応版)に持ってきました
（少しぐらいのバージョン違いは気にしません）。
〔次に続く〕
265:FreeBSDでwimeを使っている君
22/08/19 02:43:01.87 .net
〔前からの続き〕
その結果が、>>71 です。
「imm32.dll」は、
/home/ユーザ名/.i386-wine-pkg/usr/local/lib/wine/i386-windows/imm32.dll
として置き、wimeにより、ATOKは動きました。
ただし、以下のような問題が生じました。>>95 >>99
・wimeのwimectrlが（"libX11.so.6" not found）のエラーを
出して動かない。
・文節区切りの変更でWineがエラーを出して停止。詳細は >>96
Wineの64bit/32bitの「versions do not match!」の件は、
Wine7.4(devel版)の時点でも起こっています。>>98
266:FreeBSDでwimeを使っている君
22/08/19 02:44:48.25 .net
>>233 >>235
＞/usr/local/share/wine/pkg32.sh add 「パッケージのファイル名」
i386で作ったパッケージを「/home/ユーザ名/.i386-wine-pkg」
として持って来られるとは思っていませんでした。
267:名無しさん＠お腹いっぱい。
22/08/19 02:46:02.99 .net
>>263
pkg がビルドされているのは13.0R、13.1Rとはコンパイラのバージョンが違うので
md5が違うのは当然
268:名無しさん＠お腹いっぱい。
22/08/19 06:07:56.91 .net
これは面白くなってきたぞ
乞うご期待
269:FreeBSDでwimeを使っている君
22/08/20 02:35:35.89 .net
>>262 では、肝心なことを書き忘れていました。
ホームディレクトリ以下に展開される32bit環境では、
Wine7.14では、「lib/wine/fakedlls」しかなく、
「lib/wine/i386-windows」はなくなっています。
しかし、Wine7.14をi386でmakeすると、
「i386-windows」は存在します。
>>267
ああ、そうなのか。知りませんでした。
パッチをあてて、オリジナルファイルを残さないのは
おかしいですから、なんとなくですが、
そもそも、パッチがあたっていない可能性があります。
270:名無しさん＠お腹いっぱい。
22/08/20 07:58:43.18 .net
いつまで続くのかじっくり見物させて頂くとしよう
271:FreeBSDでwimeを使っている君
22/08/21 16:27:53.43 .net
FreeBSD13.1R/amd64のpkg(8)は、quarterlyですので、wine-devel-7.8,1で
試したかったのですが、PortsTreeでは、wine-devel-7.14になっています。
portdowngradeをしたのですが、wine-devel-6.4が最新で、7.8には
戻れませんので、wine-6.0.4,1で試行する事にします。
VirtualBOXの、FreeBSD13.1R/i386のPortsから、wine-6.0.4_1,1を
makeします。もちろん、wimeのimm-magic-1.7.3をあてます（注）。
make packageし、wine-6.0.4_1,1.pkgをamd64側に持って来ました。
amd64のpkgはwine-6.0.4,1です。
amd64で、pkg installし、>>233の助言の通り、pkg32.shを走らせます。
/usr/local/share/wine/pkg32.sh add /フルパス/wine-6.0.4_1,1.pkg
すると足りないpkg(8)が、たくさんありました。
メッセージで言われる「mesa-dri」の他は、以下、列挙します。
FAudio,desktop-file-utils,fontconfig,gcc11,gnutls,jpeg-turbo,
lcms2,libGLU,libXcomposite,openal-soft,vkd3d
これだけ入れると自作のwine-6.0.4_1,1.pkgが
ホームディレクトリ以下に入りました。
272:FreeBSDでwimeを使っている君
22/08/21 16:29:31.54 .net
（注）基本に戻るのは大事だと痛感しました。
URLﾘﾝｸ(docs.freebsd.org)
によると、やはりパッチは、ファイル名の頭に「patch」とつけ、
「patch-imm-magic-1.7.3」とし、内容も文頭の「wine-1.7.3」
のバージョンを削ったほうがよいようです
make後、imm32.c.origが残っており、「+」の行が追加され
「-」の行が削除されていました。
コメント行も追加されていました。>>218 は間違いです。
※ >>11 再まとめの際は注意。
273:FreeBSDでwimeを使っている君
22/08/21 16:34:31.21 .net
FreeBSD13.1R/amd64
・pkg(8)からのwine-6.0.4,1
・ホームディレクトリ以下の32bitのWineは、
i386でmake packageしたwimeのパッチが
あたったwine-6.0.4_1,1.pkg
この環境で、32bitなxyzzy.exeが動くのを確認しました。
※.wineの新規生成はしていない。
この環境で、i386でgmakeしたwime-4.1.5の動作確認です。
・wimeでの漢字変換はOK。
・wineの引数でATOK17UT.EXEを指定しての辞書Utilityの起動はOK。
・「wimectrl -s」による、ATOKのプロパティの起動はダメ。
ld-elf32.so.1: Shared object "libX11.so.6" not found,
required by "wimectrl" ※桁折り済み
>>233 の助言による、「pkg32.sh install」での
libX11,libxcb,libXau,libXdmcp は「already installed」でした。
274:名無しさん＠お腹いっぱい。
22/08/21 16:37:52.95 .net
>>273
wime-4.1.5/io/Makefile の
ifneq "$(OS)" "Linux"
override LDFLAGS:=$(subst local/lib,local/lib32,$(LDFLAGS))
endif
を消してみたらどうなる？
275:FreeBSDでwimeを使っている君
22/08/21 16:38:20.35 .net
wimeのバイナリをi386で作ったのが問題かと、
wimeを、wine-6.0.4と32bit環境が入ったamd64で、gmakeし直しました。
wimeのconf.mkで「"WOW64?=1"」にした場合、
ld: error: unable to find library -lX11
clang: error: linker command failed with exit code 1
(use -v to see invocation) ※桁折り済み
となり、gmakeが通りませんでした。
wimeのconf.mkで「"WOW64?=0"」にした場合、gmakeが通りました。
amd64（wine-6.0.4と自前の32bit環境）で、gmakeした
wime-4.1.5の動作確認です。
・「wime -e atok」での起動（CannaServerの起動と同じ）で
以下のように言われる。
0148:err:process:exec_process failed to load L
"W:\\bin\\wime.exe.so" error c000035a ※桁折り済み
・wineの引数でATOK17UT.EXEを指定しての辞書Utilityの起動はOK。
・「wimectrl -s」による、ATOKのプロパティの起動はOK。
amd64で作った「wime.exe.so」は、以下でした。
%file wime.exe.so
wime.exe.so: ELF 64-bit LSB shared object, x86-64, version 1
(FreeBSD), dynamically linked, for FreeBSD 13.1, with debug_info,
not stripped ※桁折り済み
276:FreeBSDでwimeを使っている君
22/08/21 16:39:52.87 .net
では、と、amd64で、gmakeした、wimeのwime.exe.soを、
i386でgmakeしたもの（動作確認済み）に差し替えてみては
どうか、と試しましたが、
「W:\\bin\\wime.exe.so" not supported on this system」
と言われました。
なぜなの？
Wine側の64bit/32bitの切り替えに何かがあるのかなあ。
「ld-elf32.so.1: Shared object "libX11.so.6" not found,」
の件がなんとかなれば、とも思います。
i386-wine-develとi386でgmakeしたwime-4.1.5に戻ってきました。
277:FreeBSDでwimeを使っている君
22/08/21 17:31:04.04 .net
>>274
wime-4.1.5/io/Makefile の
ifneq "$(OS)" "Linux"
override LDFLAGS:=$(subst local/lib,local/lib32,$(LDFLAGS))
endif
をコメントアウトし、i386でgmakeしたバイナリを
amd64のWOW64なwine-6.0.4に持ってきました。
・wimeでの漢字変換はOK。
・「wimectrl -s」
ld-elf32.so.1: Shared object "libX11.so.6" not found,
required by "wimectrl" ※桁折り済み
と >>273 と同じ結果となりました。
278:名無しさん＠お腹いっぱい。
22/08/21 17:38:46.26 .net
32bit の libX11.so.6 があるディレクトリを
ldconfig -32 で追加したら
279:名無しさん＠お腹いっぱい。
22/08/21 17:40:48.50 .net
URLﾘﾝｸ(github.com)
ここの portsfetch で quarterly の ports tree が取得できる
wine-devel も 7.8,1
280:FreeBSDでwimeを使っている君
22/08/21 18:39:40.17 .net
○漢字変換はできるが、「wimectrl -s」（ATOKのプロパティ起動）で
ld-elf32.so.1: Shared object "libX11.so.6" not found, required by "wimectrl"
となり、ATOKのプロパティが起動できない件。
環境は >>273と同じで以下。
FreeBSD13.1R/amd64
・pkg(8)からのwine-6.0.4,1(WOW64のもの)
・ホームディレクトリ以下の32bitのWineは、i386でmake packageした
wimeのパッチがあたったwine-6.0.4_1,1.pkgを
/usr/local/share/wine/pkg32.sh add /フルパス/wine-6.0.4_1,1.pkg
とした
・wimeはFreeBSD13.1R/i386でgmakeしたwime-4.1.5
〔次に続く〕
281:FreeBSDでwimeを使っている君
22/08/21 18:42:15.76 .net
〔前からの続き〕
>>278
動きました。
執筆者はwimeを手作業でホームディレクトリに置いて
運用しているのですが、
env LD_32_LIBRARY_PATH=/home/ユーザ名/wime/lib\
:/home/ユーザ名/.i386-wine-pkg/usr/local/lib \
/home/ユーザ名/wime/bin/wimectrl -s
※バックスラッシュで続いています
として「.i386-wine-pkg/usr/local/lib」を追加することで、
「wimectrl -s」でATOKのプロパティが起動しました。
FreeBSD特有の話なので、wimeの作者に手間を取らせる質問を
しなくて済みました。
みなさん、辛抱強い助言を、ありがとうございました。
本当にありがとうございました。
>>279 知りませんでした。後日、Wine7.x系をやってみます。
282:FreeBSDでwimeを使っている君
22/08/21 19:02:35.01 .net
書き忘れていました。
>>269 で、
＞ホームディレクトリ以下に展開される32bit環境では、
＞Wine7.14では、「lib/wine/fakedlls」しかなく、
＞「lib/wine/i386-windows」はなくなっています。
と書きましたが、
Wine6.0.4でも「lib/wine/fakedlls」しかありませんでした。
執筆者は、安直に「imm32.dll.so」や「imm32.dll」の
ファイルだけを持って来ていましたが、
「パッケージで持ってくればよい」という知見が、
このスレで与えられました。
みなさんありがとうございました。
283:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
辛抱した代わりと言ってはなんだがよかったらtwmスレもちょいちょい書いてくれると嬉しい
284:FreeBSDでwimeを使っている君
[ここ壊れてます] .net
twmというか、ctwmだから、おじゃま虫だなあ。
執筆者君は、ctwm特有のカスタマイズはしないようにして、
すぐにtwmに切り替えられるような.ctwmを書いています。
twmのスレ、見てはいますが、特に書くネタはないなあ。
Windows3.1や、FreeBSDのAfterStep1.4からの慣れで、
「ウインドウを消すバツ（Ｘのロゴ）が最右端でないと、
使いにくいな」と、思ったことがあり、バツを最右端に
する設定を、ググり中に見つけたが、バツを最右端にすると
リサイズボタンが使いにくくなるのに気づいて、最右端は
リサイズボタンなのだなあ、と、思ったことがあります。
よくあるウインドウのように隅っこでリサイズできると
いいんだけど、窓枠が太くなるしなあ。
まあ、気をつけておきます。
285:FreeBSDでwimeを使っている君
22/08/21 20:33:20.83 .net
それで思い出したけど、最近のGNOME系かな、
ユーザーサイド側の窓の装飾ってどうなの、と思う。
Window Manager を考えなくてもよいので、
管理の負担が減るとか、アプリケーション内の入れ子で
表示しやすい、というのが、あるのかもしれないけれど、
X Window Systemの考え方からは、逆行しているように思う。
もし、ユーザーサイド側の窓の装飾を、流行などで、
コロコロと変えられたら、ユーザ側からは地獄でしょ。
それに、そういう事をすると、逆に古びると思う。
「スマホ風のUIだって、プギャー」って時代も来るだろうし。
286:名無しさん＠お腹いっぱい。
22/08/22 04:36:00.32 .net
>>281
使ってないから知らなかったが net/gitup 見たら
gitup.conf.sample に quarterly の設定もあるな
ports の更新もこれ使えばいいんじゃね
287:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
portsfetch でも更新できるから
どちらでもいいが
288:FreeBSDでwimeを使っている君
22/08/23 23:04:25.61 .net
「portsfetch」の、ご紹介ありがとうございました。
ありがたいShellScriptですね。
VirtualBox6.1.36内のFreeBSD13.1R/i386で、portsfetchを
動かしたところ、動作中にリブートがかかりました。
portsfetch内から追加パッケージをインストールしたまま
動かしていたからなのか、負荷がかかりすぎたのか、は
不明です。
ですが、リブート後、再度、portsfetch したら
（何かを取得し直しになりましたが）、PortsTreeが
quarterlyになりました。
289:FreeBSDでwimeを使っている君
22/08/23 23:06:53.01 .net
さて、FreeBSDのWine7.8(WOW64)を試しました。
環境：FreeBSD13.1R/amd64
・pkg(8)からのwine-devel-7.8,1(WOW64)
・HomeDirectory以下の32bitのWine環境(.i386-wine-pkg)は、
i386のPortsでwimeのPatchをあてたwine-devel-7.8,1を
make packageし、amd64に持ってきたもの
・wime4.1.5は、FreeBSD13.1R/i386でgmakeしたもの
amd64で、pkg(8)から、wine-devel-7.8を入れ、
%/usr/local/share/wine/pkg32.sh install
mesa-dri FAudio desktop-file-utils fontconfig gcc11
gnutls jpeg-turbo lcms2 libGLU libXcomposite
openal-soft vkd3d
%/usr/local/share/wine/pkg32.sh add
/フルパス/wine-devel-7.8,1.pkg
とし、無事、wime4.1.5は動き、漢字変換できました。
ATOKのプロパティも以下のように
「.i386-wine-pkg/usr/local/lib」を追加して
起動しました。
env LD_32_LIBRARY_PATH=/home/ユーザ名/wime/lib\
:/home/ユーザ名/.i386-wine-pkg/usr/local/lib \
/home/ユーザ名/wime/bin/wimectrl -s
〔次に続く〕
290:FreeBSDでwimeを使っている君
22/08/23 23:08:37.37 .net
〔前からの続き〕
Wineは、７系からUI(winecfg)が、昔のWindowsのような
灰色から、白に変わったんですね。
普通に漢字変換でき、xyzzyなども起動するのですが、
xyzzy内から、印刷をクリックすると、
「通常使うプリンタが設定されていません」です。
Wineでは、FreeBSD側で正常に印刷できる状態なら、
Wineでも印刷できます。
※執筆者は昔ながらの「/usr/bin/lp」を使っています。
Wine7.x系からは、変わったようです。
初めて、Wine7.0を試したとき（>>94-96）も
「通常使うプリンタが設定されていません」
だったのもあり、即、i386-wine-develに戻ったことを
思い出しました。
いろいろとググりましたが、Wine7.x以降での
プリンタまわりの変更点は分かりませんでした。
※Wineのコントロールパネルでは設定できませんしね。
で、Win6.0.4に戻りました。
Win6.0.4では、プリンタは、printcapの設定通りに見えて、
印刷できました。
291:FreeBSDでwimeを使っている君
22/08/23 23:10:33.94 .net
Wine7.x系で、64bitで動くソフトウェアからの印刷は
試していませんが、32bitWine側で、
「lpd_enable="YES"」とか「/etc/printcap」
みたいなことができれば、使えるような気もします。
参考：
Wine - ArchWiki
URLﾘﾝｸ(wiki.archlinux.jp)
＞win32 prefix で wine アプリケーション (例: MS Word) を使って
＞プリンター (ローカル・ネットワーク両方) を使用するには
＞lib32-libcups パッケージをインストールしてください。
※ArchWikiは良いですよね。
大昔によくあったXでの設定も、ちゃんと載っていますし。
292:名無しさん＠お腹いっぱい。
22/08/24 11:18:10.74 .net
素直に pkg32.sh で cups インストールして設定すればいいと思うが
293:名無しさん＠お腹いっぱい。
[ここ壊れてます] .net
wime君育成ゲームスレっぽくなってきた
294:FreeBSDでwimeを使っている君
22/09/12 00:30:56.15 .net
□いまさらながらCUPSを試す 1/3
※これからは、文章中で人物を「方（かた）」でなく「人（ひと）」と
呼称します。「方（ほう）」と、まぎらわしいためです。
まれに表記の「ゆらぎ」があるかと思いますが、ご容赦願います。
環境：FreeBSD13.1R/amd64 , cups-2.4.2
：LAN接続したBrother社のPostScript互換言語のBR-Script3搭載の
複合機に昔ながらの「/usr/bin/lp」から印刷するという形です。
※他メーカでも、PostScript互換言語搭載機が存在します。
現在、執筆者は、昔ながらの「/usr/bin/lp」（以下「LPR」とする）を
使って印刷しています。
PostScript互換言語搭載機だと、「/etc/printcap」を
ちょこっと書くだけで使えるので便利です。
実際に、Wine6.x系や、libreoffice-7.3.5.2で印刷できる状態です。
「今どきはCUPSだよね」という事で、重い腰を上げ、CUPSを試しました。
○rc.conf
lpd_enable="YES"(/usr/bin/lpの起動)を、CommetOut。
「cupsd_enable="YES"」「cups_browsed_enable="YES"」を追加。
○サーチパス
CUPSが起動しないように、変更してあるパスの
「/usr/bin /usr/local/bin」を
「/usr/local/bin /usr/bin」の、本来の形に変更。
※CUPSの存在に困って、この入れ替え設定をしている人は、
それなりにおられると思います。
295:FreeBSDでwimeを使っている君
22/09/12 00:33:06.72 .net
□いまさらながらCUPSを試す 2/3
○機種名.ppd
Brotherのサイトから、MacOS用のppdファイルとされるものを
ダウンロードし、
機種名など.dmg→機種名など.pkg→機種名.gz→機種名、の
ファイルを抽出します。ついでに機種名.ppdとReNameしておきます。
執筆者はMacOSには、うといので、「機種名など.dmg」から
Windows版の「7-Zip Ver22.00」を使用してppdファイルを
抽出しました。
※ppdファイルは必ず必要というわけではありませんが、
類似型番の機種設定で使うより、気持ちいいと思います。
※ppdファイルの内容を見て、文書頭にあるパスっぽい部分は
MacOS特有のようなので削除しました。
○CUPS設定手順
ブラウザで「URLﾘﾝｸ(localhost:631)」を開き、
上のバー状メニューの「Administration」から指定してゆきます。
途中でloginが求められますが、root様を指定してください。
「add」でプリンタが見えますが、「Discovered」で見えた機種名を
選ばないでください。※後でネットワーク接続の設定をするため。
「LPD/LPR Host or Printer」を選び、
Connection:の、lpdと入っている部分を
「lpd://192.168.x.x/binary_p1」とIPアドレスを追加編集します。
下の方の「Or Provide a PPD File:」で、前述のMacOS用ファイルから
抽出したppdファイルを指定します。
296:FreeBSDでwimeを使っている君
22/09/12 00:34:36.18 .net
□いまさらながらCUPSを試す 3/3
以上の手順で、CUPSで印刷できます。
実際に、leafpadと、libreofficeで、印刷できました。
印刷キューは「URLﾘﾝｸ(localhost:631)」で見えました。
参考にしたサイト：
HL-5380DN, Debian
URLﾘﾝｸ(bm.skr.jp)
Linux上で印刷する (CUPSを設定する) - Let's Try It!
URLﾘﾝｸ(www.letstryit.net)
FreeBSD10.0システムインストール
URLﾘﾝｸ(web.cc.yamaguchi-u.ac.jp)
５．５ プリンタの設定 | あらかると
URLﾘﾝｸ(www.starlink.jp)
297:FreeBSDでwimeを使っている君
22/09/12 00:37:22.88 .net
□FreeBSDのWOW64な、Wine6.x系、Wine7.x系からの印刷 1/2
＊執筆者特有の条件
・Wine6.0.4、Wine7.8のどちらにもwimeのパッチをあてた
i386なpkg(8)を「pkg32.sh install」。
・Wine6.0.4、Wine7.8のどちらも、i386なpkg(8)の
makeオプションは標準のままなので
「CUPS=off: CUPS printing system support」のまま。
＊状態
・LPR(/usr/bin/lp)、CUPSのどちらも、
amd64ネィティブのlibreofficeなどから印刷できるのを
確認済みの状態。
＊目標
WOW64なWineで、32bitなWindowsソフトウェアからの印刷をめざす。
「%/usr/local/share/wine/pkg32.sh install」で、指定のpkg(8)を
ユーザのホームディレクトリ以下に、ユーザ権限でインストールした
うえで、追加として「cups」「cups-filters」をインストールしました。
298:FreeBSDでwimeを使っている君
22/09/12 00:38:48.85 .net
□FreeBSDのWOW64な、Wine6.x系、Wine7.x系からの印刷 2/2
＊Wine6.0.4
LPRで印刷できる。
CUPSでは「通常使うプリンタが設定されていません」。
※Wine6.0.4では、「lpd_enable="YES"」を切ってあっても
「/etc/printcap」の中身を見てプリンタ名を返しています。
＊Wine7.8(wine-devel)
LPRで「通常使うプリンタが設定されていません」。
CUPSでも「通常使うプリンタが設定されていません」。
という結果になりました。
32bitなWineを「CUPS=on」でmakeすればいいのかもしれませんが、
そこまでして「CUPS」を使いたいわけではないし……。
Wine7.x系に、特段の思い入れがあるわけでもないし……、
なので、Wineの安定版が7.xになってから試すことにします。
それを思えば、libreofficeは、LPRでも、CUPSでも、印刷できて
偉いなあ、と思います。
じゃ、お夜食を食べてきます。
299:名無しさん＠お腹いっぱい。
22/12/29 07:50:25.01 .net
Wineなんか使わん
300:FreeBSDでwimeを使っている君
23/01/08 22:04:08.77 .net
備忘録。
タイミングで該当バージョンに当たった人がいるかもしれませんが
firefox-105は避けた方がよいようです。
Firefox-ESRが105固定になりませんように。
ｽﾚﾘﾝｸ(unix板:154番)-171
301:名無しさん＠お腹いっぱい。
23/01/09 00:42:11.77 .net
Firefoxは常に最新使ってるが105の時も落ちた事はないな
なおESRになるバージョンは決まってる
URLﾘﾝｸ(wiki.mozilla.org)
302:FreeBSDでwimeを使っている君
23/01/10 00:59:24.05 .net
あ、やっぱり、１つだけの報告の場合、
判断は保留したほうがいいのか。
つい、飛びついちゃうな。
ReleaseCalendarは知りませんでした。
ありがとうございました。
303:FreeBSDでwimeを使っている君
23/01/29 19:02:48.86 .net
少し前にWine8.0がReleaceされました。
さがわ@sagawa_aki （sagawa_aki/status/1618968131002834944）
＞Wineの32bitライブラリがUnixシステムの32bitライブラリ
＞（FreeTypeやGstreamerなど）を使わなくなるので、
＞その分のディスクスペースを節約できます。
＞将来にディストリビューションがi386パッケージの提供をやめても、
＞32bitのコードセグメントを実行する機構を残してくれれば、へっちゃらです。
＞10:44 PM ・ Jan 27, 2023
FreeBSDのWOW64なWineが、64bit版Wineと、32bit版Wineを、
たばねた（注１）ような状態（注２）であるのは、
Wineの開発方向を把握した上で、将来的に対応しやすいように
配慮してあるのかもしれません。
「/usr/local/share/wine/pkg32.sh install wine mesa-dri」として、
pkg(8)の指示による、ユーザ実行のShellScriptで、
32bit版のWineを、ユーザのホームディレクトリに
インストールしなくてもよくなる方向か、と思います。
注１：別々に存在する物を同時に使えるようにしてある。
注２：Linux版も同様の状態かもしれませんが、執筆者は
Linuxを知らないのでわかりません。
※投稿時に、書き込みの末尾に、自動的にゴミがつくので
twitterURLの先頭部分をカットしています。
304:FreeBSDでwimeを使っている君
23/01/29 19:06:11.69 .net
>>303
参考URL
WineHQ - Wine Announcement - The Wine team is proud to announce that the stable release Wine 8.0
URLﾘﾝｸ(www.winehq.org)
「Wine 8.0」がリリース 〜LinuxでWindowsのGUIアプリを直接実行できる互換レイヤー - 窓の杜
URLﾘﾝｸ(forest.watch.impress.co.jp)
今夜も Wine で乾杯! - 23本目
ｽﾚﾘﾝｸ(linux板:744番)-n
＞このリファクタリングが完全に完了すると、
＞基幹のkernel32.dllやgdi32.dll、user32.dllすら
＞wineのからwindowsのに差し替えても動作するはずなので、
＞理屈の上では互換性がさらに向上するはず
（中略）
＞従来の64bit Linuxで32bitバイナリを動かす仕組みではなく、
＞64bitWindowsと同様の仕組みで32bit windowsバイナリを実行できる
＞新しいWOW64が実装された
305:FreeBSDでwimeを使っている君
23/03/25 20:50:29.09 .net
さがわ@sagawa_aki （sagawa_aki/status/1634408136709918725）
＞Wine 8以降のコミットをみると、IMM32によるIMEサポートを
＞加えようとしている様子がうかがえる。
＞方針がMLで共有されていないので、先行きは不明だけれど、
＞XIMと決別できるといいなあ。
1:17 PM ・ Mar 11, 2023
（全文引用）（改行位置は引用者）（twitterURLの先頭部分をカット）
との事で、
うまくゆけば、Wine環境下で動作するWindowsソフトウェアに対して
WindowsのIMEを使って入力する事が可能になるかもしれません。
そうなれば、wimeが修正される可能性も、あるかと思われます。
（備考１）
大昔の事で、どこで読んだか忘れましたが、
既知情報として、MicrosoftOffice付属などのMicrosoftIMEは、
Wine環境下にInstallできない（エラー停止）、とされています。
（備考２）
Wine8系のportが進まないのか、FreeBSDのVersionUpのタイミングに
合わせるのか、一般ユーザには事情が分かりかねますが、FreshPortsに
よると、現時点で、FreeBSDのwine-develは、7.22,1です。
306:FreeBSDでwimeを使っている君
23/06/16 01:29:38.84 .net
2023/05/31にwime4.1.6がリリースされていました。
「パッチの整理」との事です。
パッチファイルが、WineのVersion別（Wine7.x、Wine8.x）に
増加しています。
wime4.1.6のReadmeの「Wineへのパッチ」を見ると、
Wine7系、Wine8.4までは、必要に応じて各種パッチをあてる必要が
ありますが、Wine8.6以降では、パッチは必要なくなります。
ただし、
「wimegtkやwimeximでかな入力をする場合はパッチkanainputを適用」
とのことです。
※kanainputは、Wine5.8以降、Wine7.7以降、Wine8.3以降の別がある。
単純にCannaとして使う場合、Wine8.6以降の場合、
Wineを自前でmakeする必要がなくなりました。
執筆者としては、とてもうれしいです。
まあ、現在のFreeBSDのwine-develは7.22なんですが。
307:FreeBSDでwimeを使っている君
23/06/16 01:33:51.20 .net
FreeBSDの場合、64bit版ATOKは、Wine環境下にinstallできない、と、
執筆者は、どこかで読んだような気がするので、実際にその通りなら、
64bit版ATOK用のwimeのtransmsgパッチは、考えなくてもよいと
思います。
いずれ、64bit版ATOKがFreeBSDでの64bitなWine環境下にinstall
できるようになってから（ならないかもしれませんが）、
考えればよいでしょう。
いずれにしても、ATOKが32bit版をリリースしなくなったら、
FreeBSDではどうするか、という問題が残ります。
現時点では「ATOK Passport」には、32bit版があります（注）が、
おそらく、Windowsの動きに追従すると思いますので、
32bit版Windowsが完全に消えた場合、ATOKも32bit版が
新規に入手できなくなるかもしれません。
（注）
ATOK Passport32bit版のVersionUpが、2023/02/10に、
UpdateModuleが、2022/06/21に更新されている。
308:FreeBSDでwimeを使っている君
23/07/16 03:00:04.25 .net
前スレッドを事実上の占有状態で消費した事による贖罪の意味で、
執筆者は、次スレッドとして、このスレッドを作成しました。
別にスレッドのヌシというわけではありません。
5ch(2ch)専用ブラウザ分裂がらみの「talk」掲示板のUNIX板には、
このスレッドと同名のスレッド（>>1のみがある状態）が存在しますが、
執筆者が関与したものではありません。
>>1 のみが、コピーされた形でのスレッドのようです。
「出典」という形で、このスレッドのURLが表記されてはいますが、
著作権的にはどうなんでしょうね。
「出典」には、あたらないように思います。以上です。
309:名無しさん＠お腹いっぱい。
23/08/17 03:17:42.46 .net
32bitWineは少なくとも15、16では動くだろうけど先のことは分からない
15.0が出るとまた方針が変わるかもしれないよと
URLﾘﾝｸ(cgit.freebsd.org)
今の流れ的には32bitに関して考慮する必要があるのは主にarmとWineについてで
i386自体はもういいだろって感じ
310:名無しさん＠お腹いっぱい。
23/08/17 09:01:39.67 .net
14.0では32bitカーネルは非推奨で15.0で削除される可能性があると警告が出るようになった
でも最終決定はまだ
311:名無しさん＠お腹いっぱい。
23/08/18 16:44:15.23 .net
15.0ではサポートされるのはCOMPAT_FREEBSD32とlib32で
ネイティブな32bitプラットフォームは非推奨ということですな
そしてstable/14は一週間遅れ
312:FreeBSDでwimeを使っている君
23/08/21 01:17:59.70 .net
妙なスレ立てがあるようなのでsageたままにします。
「FreeBSDでwimeを使っている君」は、情弱です。
情報提供ありがとうございます。
FreeBSD/i386がTier2になって、すぐ感のあるいま、こういう話が
出ているんですね。人手、運用、設備を考えても仕方がないかなあ。
cgit.freebsd.org/src/commit/RELNOTE を翻訳にかけて読む限り、
Athlon64（AMD64・x86-64）以前の32bit機では、FreeBSDは
特定バージョンで打ち切りになるかもしれない、という事ですね。
Linuxでも32bit版を提供するDistributionが減っていますしね。
PAE_Kernelの記事でお世話になった「uyota 匠の一手」氏の反応は
どうか、と、思いましたが、いまのところ記事はないようです。
COMPAT_FREEBSD32と、lib32は、残るそうなので、32bitバイナリの
実行、32bitのソースコードのコンパイルはできますね。
そういうものがあるかどうかは知りませんが、ソース非公開の
商用などのソフトウェアで、それっきり更新されていない場合でも、
WXGの経緯（使い続けようとするユーザー側の努力）を参考にすると、
それなりの期間は安心かもしれません。
ドライバはソースを書き換えないと無理かもしれませんが、
その頃には、ハードウェア自体が腐っているかもしれませんし。
何かの事情で、COMPAT_FREEBSD32とlib32がベースシステムから、
なくなるとしても、純粋なcshがportsに移った経緯がありました
から、何とかなるかもしれません。
COMPAT_FREEBSD32とlib32、最終版Kernel、をベースに
独自のi386版としてフォークする動きがあるとおもしろいんですが、
ないでしょうね。
313:FreeBSDでwimeを使っている君
23/08/21 01:21:00.60 .net
それで、Wineの場合です。
Wineの場合、Windows業界に蓄積された膨大なソフトウェア資産を
Unix系でも使いたい、というのが、もともとの趣旨でもあります。
そういうエロゲがあるかどうかは知りませんが、32bit版Windows向けの、
他機種に移植されていない特定バージョンのゲームがしたい、
などの要望は、性癖に関わりそうな話ですので、
Wineに対して、きわめて強い要望がありそうです。
ですが、>>303 に「さがわ@sagawa_aki」氏の引用をしましたが、
Wine8.0以降ならば、将来的に問題とは、ならなさそうです。
314:FreeBSDでwimeを使っている君
23/08/21 01:24:26.03 .net
未来の話ですが、FreeBSDでのWine＋wime＋ATOKの場合、です。
現在、FreeBSD/amd64の64bit版のWineでは、64bit版ATOKが
インストールできませんが、インストールでき、動作すれば、
問題はありませんし、さがわ氏の引用に依ると、32bit版ATOKも
Wine側で対応できそうです。
余談ですが、大昔の一太郎では関連モジュール的なものに
16bitなWindowsバイナリが残っていたそう（公式に依るとそれを
更新したという記述がありました）なので、
一太郎の完全な64bit化は遅いかもしれません。
執筆者は、32bit版ATOK用のwimeのバイナリを仮想環境下の
FreeBSD/i386でgmakeしているのですが、この作業が、
どう変わるか、と思っています。
wimeのMakeFileに記述が入ればよいのですが、
wime作者のthomas氏はLinuxなので……。
執筆者は、wimeのPorts化すらできないので、修正する能力は、
当然ながらありません。キリッ！
315:FreeBSDでwimeを使っている君
23/08/22 23:08:33.74 .net
FreeBSDでwimeを使っている君は、タイミングが悪いです。
i386wineの時も、書いた直後に新情報（統合する）を見つけ、
追加のレスをした記憶があります。
Wine公式のWineHQによると、以下の通りで、安定版と開発版の
両方とも、メジャーバージョンは８系に上がっています。
まあ、それが普通ですね。
Stable : Wine 8.0.2
Development : Wine 8.14
316:FreeBSDでwimeを使っている君
23/08/22 23:10:21.39 .net
FreshPortsによると、以下の通りですが、
FreeBSDでは、安定版と開発版のメジャーバージョンに
ズレが生じています。まあ、よくある事なんですが。
執筆者的には、wine-develが8.11に上がっており、>>306 の理由で
非常にうれしいです。
さらに、新規に「wine7」ができていました。
FreeBSDでの安定版が、Wine8系に上がっても、明示的にWine7系を
使い続けたければ、「wine7」を使用する、という事かと思います。
wine 7.0.2_5,1
Last Update: 2023-08-18 21:57:12
wine-devel 8.11_1,1
Last Update: 2023-08-20 08:07:09
wine7 7.0.2_1
Port Added: 2023-07-30 22:00:06
Last Update: 2023-08-19 11:19:32
317:FreeBSDでwimeを使っている君
23/08/22 23:15:20.91 .net
FreshPortsでの、Wine8.11の流れですが、wine-devel8.11,1時点では、
32bit版Wineに問題が生じていたようですが、8.11_1,1では、
問題ないようです。
「bump」とは、「stuck」に対応して「プログラムを実行する」
という意味なんでしょうか。
○8.11,1 13 Aug 2023 13:29:15
＞Finally, Wine 8.x so far does not appear to work on FreeBSD/i386,
＞so mark as BROKEN. Still better to progress than being stuck.
○8.11,1 15 Aug 2023 21:57:36
＞emulators/wine-devel: Fix 32-bit pkg invocation for WoW64
（中略）
＞Do not bump PORTREVISION since 32-bit builds are broken right now.
○8.11_1,1 20 Aug 2023 08:07:09
＞Bump PORTREVSION accordingly.
318:名無しさん＠お腹いっぱい。
23/08/23 06:59:19.96 .net
PORTREVISIONを増やすのは元のバージョンは変わってないけど
ports/pkgに変更があったので再インストールさせたい時
319:FreeBSDでwimeを使っている君
23/08/24 22:45:24.61 .net
>>318
知りませんでした。非常に勉強になりました。
「PORTREVSION」そのものも、まったく理解していませんでした。
「_1」「_1,1」は、単純なmakeのやり直しや、リンクされる物などの
バージョンが上がった場合、だと思っていました。
「Bump」は、１段階引き上げる、という意味か。
単純翻訳の語意イメージと合致します。
質問スレ125の209に書きましたが、その分野を理解していないと
単純翻訳だけではダメだ、という例ですね。
320:FreeBSDでwimeを使っている君
23/08/24 22:55:21.73 .net
ググって、以下を知りました。
5.2.2.3. Example of PORTREVISION and PORTEPOCH Usage
URLﾘﾝｸ(people.freebsd.org)
PORTREVISIONは「never decreases」とは知りませんでした。
FreeBSDへ移植する場合、移植元ソフトウェアにバージョンが
ない場合などでも、PORTVERSIONに単純な日付をつけるのは、
数値の大小問題が出るかもしれないので避けたほうがよいの
ですね。