BSD/LinuxでのOffice/Desktop環境を語れ! Part03 (400レス)
上下前次1-新
179: FreeBSDでwimeを使っている君 2022/08/05(金)01:15 AAS
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 ※注
注 外部リンク[html]: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の評価あたりで、画面出力が
なくなる。
モニターの電源ランプは、画面出力が「ある」状態だが、
実際の画面出力は「ない」。 で、リセットボタン。
まさか、「1分くらい待つと画面出力が始まる」とかじゃないで
しょうね。
いえね、i386を使っていた頃は、VGA表示から精細な表示に
切り替わるのに10秒くらいかかっていたので。
180(1): 2022/08/05(金)01:25 AAS
2chスレ:unix
出力先が切り替わってるとかはないか
181(1): 2022/08/05(金)06:52 AAS
うろ覚えだがgpu firmwareみたいな名前のpkgもportsで作り直しが必要だったような。
182(2): 2022/08/05(金)13:09 AAS
本当にその程度のレベルの人かと言う話でもある
183(2): 2022/08/05(金)13:34 AAS
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(2): 2022/08/05(金)15:31 AAS
Athlon Athlon5350なのにgpu-firmware-amd-kmod をインストールしているのが間違い
必要なのはgpu-firmware-radeon-kmodの方
分からないのならMeta ports の gpu-firmware-kmod
あと -kmod なのだから pkg ではなく ports から試すように(特にトラブってる時には)
185(1): 2022/08/05(金)15:35 AAS
amdなんて使ってないけどwikipedia見て調べてみた
180 書いたの俺だけどこれは関係無かったか
186(1): 2022/08/05(金)16:13 AAS
wine 等とまるで関係ないんだがCinnamonが割とまともにつかえる
足りないと思ったものは適宜追加しながらお好きな人はどうぞ
ただし画面ロックとシステム情報おまえらはまだダメか ヤらねばヤられる
187: FreeBSDでwimeを使っている君 2022/08/06(土)00:53 AAS
>>175
すいません。
Linux板のWineスレで、すでに「FreeBSDでwimeを使っている君」で
書いていました。
2chスレ:linux
>>186
Wineのスレではないので、良さげっぽかったり、便利っぽかったり、な
情報は書いてください。
スレタイは「Office/Desktop環境」となっていますが、
Unix系OSでOfficeソフトを使うような日常生活環境を構築するための
情報交換をしたい、人柱報告(>>4など)も読みたい、というのが
スレの趣旨です。
Desktop環境にしても、LinuxのDistributionにしても、構築する個人や、
コミュニティの好みで構築されているので、長短がありますから。
188: FreeBSDでwimeを使っている君 2022/08/06(土)00:59 AAS
>>180 >>185
それ、サーバなマザーボードでの構成でしょ。
おそらく、後載せのRadeonR7は、「ダミーが刺さって」とのことから、
ビデオ出力に使わずに、演算に使っているのではないか、と感じました。
執筆者君の環境の場合、VGAを複数認識するような高価な環境ではなく、
ビデオカードをさすと、APU側のビデオ機能は無効になるマザーボードが
ある、という、ローエンド環境に、ありがちな環境です。
もちろん、この試行中でも、いちいちビデオカードを外しながら
試していました。
おかげで、アルミ筐体の拡張スロットのネジがゆるくなってきました。
189(1): FreeBSDでwimeを使っている君 2022/08/06(土)01:02 AAS
>>183
>64bitと32bitを同時に使えるようにしただけなんじゃ
たぶん、そうだと思います。 >>38 >>67 あたりに書きました。
FreeBSDのWOW64なWineとはいっても、FreeBSD/amd64の場合、
そのままでは、64bitなWindowsソフトウェアしか使えません。
32bitなWindowsソフトウェアを使いたい場合は >>69 に
書いたように、シェルスクリプトを走らせて、
ユーザのホームディレクトリの下に
32bitなWine(バイナリ提供の様子)を展開しないと
いけませんから。
以下のURLは参考まで。
2chスレ:linux
2chスレ:linux
2chスレ:linux
190: FreeBSDでwimeを使っている君 2022/08/06(土)01:16 AAS
なんだか、入門者の犬小屋スレみたいになっていますが、
みなさん、ありがとうございます。
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(1): 2022/08/06(土)01:29 AAS
>>189
Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると
~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ
(emulators/i386-wine(含-devel)の頃には起こらなかった挙動)
192(1): 2022/08/06(土)17:28 AAS
>>182
その程度のレベルだったな
193(1): FreeBSDでwimeを使っている君 2022/08/06(土)23:59 AAS
>>182 >>192
執筆者が「その程度のレベル」なのは、
前スレ当時から自己紹介しております。キリッ。
自分でKernelをReConfigureした場合、Ports由来のKernelModuleを
再makeしないといけない、というのは知っていましたが、
「まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる」、
というのは知りませんでしたし、さらに、標準のKernelで「.1」の差が
問題になる、というのも認識していませんでした。
この後に「その程度のレベル」な、謝罪のレスがあります。
194: FreeBSDでwimeを使っている君 2022/08/07(日)00:00 AAS
>>191
執筆者の試行では、32bit環境の.wineのまま(新規生成していない)で、
WOW64なWineで32bitなソフトウェアが動きました。
WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が
できていました。
195(2): FreeBSDでwimeを使っている君 2022/08/07(日)00:01 AAS
まずは、おわびです(ガバッ、土下座)。
お散歩がてら「さがわ@sagawa_aki」氏のTwitterを見ていると
以下のようなTweetがReTweetされていました。
Twitterリンク:scp1979
>晋太郎@scp1979
>FreeBSD13.1でWineを起動したら「wine: could not load 外部リンク:ntdll.so:(null)」と出て起動しなかった。
>ググても解決方法が見つからなかった...
>pkg info -D wine を確認したところ、procファイルシステムが必要と書いてあったのでmountしたら起動した。
>#FreeBSD #Wine #備忘録
>8:39 AM ・ Jul 13, 2022・Twitter Web App
執筆者は青ざめました。
「wine: could not load 外部リンク:ntdll.so:(null)」で
このTweetより先に、大騒ぎした張本人だからです。
※大騒ぎの初出は、以下のURL、2020/12/11(金)。
2chスレ:unix
2chスレ:unix
2chスレ:unix
2chスレ:linux
Twitterリンク:5chan_nel (5ch newer account)
196(1): FreeBSDでwimeを使っている君 2022/08/07(日)00:04 AAS
で、前スレ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 AAS
あれれ?
>>195 のWineのエラーメッセージ引用のかぎカッコ中に
「 h t t p : / / 」とありますが、執筆者は書いておりません。
投稿時に自動的についたものと思われます。
198(1): 2022/08/07(日)00:54 AAS
>>196
インストールのメッセージくらい読めというところだが
貴方が前スレの992に貼ったFreeBSD Forumsでも
そのエラーの回避法としてprocのことが書いてある
199(1): 2022/08/07(日)03:52 AAS
>>193
そうか ならばもう大体把握した
200(2): 2022/08/07(日)07:49 AAS
>>195
当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。
ついでにそれがportsに反映された時期も。
四ヶ月後に再度見に行くか?ったらまあしないだろうし
そもそも当時の作業者が初耳!してるくらいだから。
あとprocマウントしてても多分そのエラーは当時は出てたと思う。
なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。
201: FreeBSDでwimeを使っている君 2022/08/07(日)22:03 AAS
>>198-200
○「wine: could not load ntdll . so : (null)」と出る件
※5chに書き込んだ時点でゴミがつくので1byte空白をはさみました
前スレ919(2020/12/11)の執筆者のレス時点では、
外部リンク: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(1): FreeBSDでwimeを使っている君 2022/08/07(日)22:05 AAS
〔前からの続き〕
前スレ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 AAS
〔前からの続き〕
外部リンク[cgi]:bugs.freebsd.org
で、「wine: could not load」の件が報告され、
外部リンク[cgi]:bugs.freebsd.org
と、関係があると思われていたが、違うようだ、と、なったようだ。
「id=257105」は閉じられて、その後、どうなったかは分からない。
外部リンク: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(1): 2022/08/08(月)04:07 AAS
>>202
> もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して
> 検証することができないのですが。
パッケージを保存しておいた実機で各種検証する人の書く事とも思えんが
205(1): 2022/08/08(月)04:41 AAS
何でfreshportsなのかという疑問はあるが
外部リンク:cgit.freebsd.org
外部リンク:cgit.freebsd.org
206(1): FreeBSDでwimeを使っている君 2022/08/08(月)20:52 AAS
>>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 AAS
「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(1): 2022/08/08(月)21:02 AAS
>>206
それが Forum とかでの freebsd の ports は multilib をサポートしてないから
という発言につながるわけですな
上下前次1-新書関写板覧索設栞歴
あと 192 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ
ぬこの手 ぬこTOP 0.013s