BSD/LinuxでのOffice/Desktop環境を語れ! Part03 (401レス)
上下前次1-新
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 をサポートしてないから 
 という発言につながるわけですな 
209: FreeBSDでwimeを使っている君 2022/08/08(月)21:04 AAS
 この件について、執筆者自身も、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 AAS
 >>208 
 あ、連続レス中にはさんでしまった。 
  
 >multilib をサポートしてないからという発言に 
  
 ああ。そういう意味、そういうこと、だったのか。 
 なんの話だろう、特殊なライブラリ? とか思っていました。 
 すいません、forumsの内容も、英語のため、精読していませんでした。 
211(1): 6 2022/08/08(月)21:21 AAS
 そう言えばprocfsはふつうにマウントしてましたねえ 
 と言うか sysutils/desktop-installer でDE入れると勝手に設定されるので 
212(1): FreeBSDでwimeを使っている君 2022/08/15(月)00:08 AAS
 >>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 AAS
 手順の再まとめをする時用にアンカーを打っておこう。 >>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 AAS
 >>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 AAS
 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を使っている君 2022/08/15(月)00:21 AAS
 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 の助言と経験のおかげで書くのですが、 
 新バージョン公開から3か月で、旧バージョンはEnd of Lifeと 
 なりますので、あと少しで、pkg(8)から入るKernelModuleは、 
 13.1でmakeされたものが提供されることになるでしょう。 
217(5): FreeBSDでwimeを使っている君 2022/08/15(月)00:47 AAS
 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(2): FreeBSDでwimeを使っている君 2022/08/15(月)00:48 AAS
 再まとめ用: 
 「wimeのパッチはリネームも編集もせずにそのまま置けばよい」>>11 
 「Wine7系からはパッチを当てても、imm.c.origとリネームされた 
 オリジナルのソースファイルは残らなくなった」 
219(4): FreeBSDでwimeを使っている君 2022/08/15(月)00:51 AAS
 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(2): 2022/08/15(月)00:56 AAS
 >>219 
 そこは 
 /usr/local/share/wine/pkg32.sh install wine-devel mesa-dri 
 だろ 
221(1): FreeBSDでwimeを使っている君 2022/08/15(月)00:57 AAS
 >>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(1): FreeBSDでwimeを使っている君 2022/08/15(月)01:03 AAS
 >>219 >>220 
 あ゛! あ゛! あ゛! 
  
 間違っていた! 
  
 そりゃあ、そうですよね! 
  
 pkgのメッセージをそのままコピペしただけなんですけどね! 
 いや、言い訳にはならないな! 
  
 間違ってました! すいませんでした! 
223: FreeBSDでwimeを使っている君 2022/08/15(月)01:12 AAS
 執筆者としては、 
 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(2): 2022/08/15(月)01:19 AAS
 知らないかもしれないので書いとくが 
 amd64でi386-wineはビルドできる 
 外部リンク:wiki.freebsd.org 
225: FreeBSDでwimeを使っている君 2022/08/15(月)01:29 AAS
 >>224 
 その記事は、昔から知っていたんですが、 
 ほぼ、理解できていませんでした。 
 今は、うっすら理解できます。 
上下前次1-新書関写板覧索設栞歴
あと 176 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ
ぬこの手 ぬこTOP 0.020s