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/
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
216 :FreeBSDでwimeを使っている君 :2022/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 の助言と経験のおかげで書くのですが、 新バージョン公開から3か月で、旧バージョンはEnd of Lifeと なりますので、あと少しで、pkg(8)から入るKernelModuleは、 13.1でmakeされたものが提供されることになるでしょう。
217 :FreeBSDでwimeを使っている君 :2022/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を使っている君 :2022/08/15(月) 00:48:58.62 .net 再まとめ用: 「wimeのパッチはリネームも編集もせずにそのまま置けばよい」>>11 「Wine7系からはパッチを当てても、imm.c.origとリネームされた オリジナルのソースファイルは残らなくなった」
219 :FreeBSDでwimeを使っている君 :2022/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 :名無しさん@お腹いっぱい。 :2022/08/15(月) 00:56:56.20 .net >>219 そこは /usr/local/share/wine/pkg32.sh install wine-devel mesa-dri だろ
221 :FreeBSDでwimeを使っている君 :2022/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を使っている君 :2022/08/15(月) 01:03:40.90 .net >>219 >>220 あ゛! あ゛! あ゛! 間違っていた! そりゃあ、そうですよね! pkgのメッセージをそのままコピペしただけなんですけどね! いや、言い訳にはならないな! 間違ってました! すいませんでした!
223 :FreeBSDでwimeを使っている君 :2022/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 :名無しさん@お腹いっぱい。 :2022/08/15(月) 01:19:28.89 .net 知らないかもしれないので書いとくが amd64でi386-wineはビルドできる https://wiki.freebsd.org/i386-Wine
225 :FreeBSDでwimeを使っている君 :2022/08/15(月) 01:29:49.96 .net >>224 その記事は、昔から知っていたんですが、 ほぼ、理解できていませんでした。 今は、うっすら理解できます。
226 :FreeBSDでwimeを使っている君 :2022/08/15(月) 01:32:26.53 .net 今のところ、Windows用のフリーのIMEはGoogle日本語入力しかなく、 それなら、mozcを使うだろうしなあ。 関係ないけど、販売版のWnn8もFreeBSDへの対応は遅すぎますし。 WXGも古すぎて動かしづらいしなあ。 まあ、手持ちのWindows用のIME(注)があれば、 ぜひ、wimeを使ってみてください。 wimeへのWineへのパッチは、ほぼATOK用ですから、素のWineで wimeが使える?、との期待が持てます。 注: http://www4.airnet.ne.jp/koabe/com_inet/im/feature4.html http://www4.airnet.ne.jp/koabe/com_inet/im/feature5.html 上記記事によると、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を使っている君 :2022/08/16(火) 00:44:57.40 .net >>219-222 現在のWineの「versions do not match!」の件。 たしかに、>>98 の時は、wineでも、wine-develでも ダメだったような気がする。 執筆者のスキルは怪しいですから、どなたか、お手すきの時で 結構ですから、Wineを試す時に、32bit環境展開の追試行を してみてくださいませんか。 これからは、i386-wine的なものを実現したければ、 以下のように、自分でなんとかするしかありませんね。 >>224 の https://wiki.freebsd.org/i386-Wine >>212 の「待てない人用」のレス https://peace.5ch.net/test/read.cgi/unix/1390323139/91-n https://toro.5ch.net/test/read.cgi/unix/1371050502/104-n
228 :FreeBSDでwimeを使っている君 :2022/08/16(火) 01:07:40.43 .net >>227 に追加。 2009年12月16日 FreeBSD/amd64でWineを実行する方法(回避策に近い) https://gihyo.jp/admin/clip/01/fdt/200912/16 ※技評のサイト、見た目が今風に変わりましたね。 Wine on FreeBSD/amd64 - kszk’s blog https://kszk-beta.hatenadiary.org/entry/20111207/1323221938 ※ここも昔、見たような気がする。 FreeBSD Wine Configuration https://linuxhint.com/freebsd-wine-configuration/ ※ここも昔、見たような気がする。 Installing wine under FreeBSD 8 amd64 - jan0schs deck https://makandracards.com/jan0sch/13429-installing-wine-under-freebsd-8-amd64 ※初見のような気がする。 Installing wine under FreeBSD 8 amd64 https://www.jan0sch.de/post/installing-wine-under-freebsd-8-amd64/ ※初見のような気がする。 いつも思うんですが、amd64でi386環境をbuildworldするなら、 単純に、インストーラから、i386のbaseを持ってきて、 展開してもいいのではないかと思う。
229 :名無しさん@お腹いっぱい。 :2022/08/16(火) 08:22:02.20 .net スキル云々以前に先ずサラの環境で試してみろよ
230 :名無しさん@お腹いっぱい。 :[ここ壊れてます] .net スクショも見たい
231 :FreeBSDでwimeを使っている君 :2022/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のプロパティを表示しながら、漢字変換はできないので、 2枚になりました。 いま気づきましたが、二重敬語の補正の指摘が、左上に出ますが、 表示されるだけなので、指示通りのキー打鍵をしても、 自動的に補正されません。表示されるだけです。 確定などの、次の動作をすると、指摘は消えてくれます。 ※imgurはアカウントを取るのが面倒なのでimepicで。 http://imepic.jp/20220818/059700 http://imepic.jp/20220818/061470
232 :名無しさん@お腹いっぱい。 :2022/08/18(木) 03:38:54.54 .net そう言うズレた事やるなら今後俺が何かを手助けする事は無い
233 :名無しさん@お腹いっぱい。 :2022/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 :名無しさん@お腹いっぱい。 :2022/08/18(木) 06:09:46.95 .net だけど libX11 は mesa-dri の依存関係でインストールされる筈だよな
235 :名無しさん@お腹いっぱい。 :2022/08/18(木) 08:38:14.19 .net > versions do not match! もし、パッケージマネージャに複数のリポジトリを登録してるなら pkg32.shを呼ぶときにリポジトリを指定しないと混ざって不整合起こす可能性があるよ。 こっちの環境でそれ喰らって少し悩んだけど結局pkgを呼んでるわけだからオプション付けるだけ。 wine-devel 7.8.1でjanestyleの通信回りが動かなかった悲しみ。
236 :名無しさん@お腹いっぱい。 :2022/08/18(木) 12:17:46.80 .net >>227 これでいいんか? https://i.imgur.com/gobPqEo.jpg >>231 ここまでの流れをざっと見てみると何がしたいのかサッパリわからんな おまかん自慢?
237 :名無しさん@お腹いっぱい。 :2022/08/18(木) 12:31:47.24 .net ちゃんと読まないからwineじゃなくてwine-develの事だと分からないんだろ
238 :名無しさん@お腹いっぱい。 :2022/08/18(木) 12:46:11.29 .net ちゃんと読めば「既存パッケージで32bitアプリも64bitアプリも同時に動かせるのに何故過去の遺産に拘っているのか」 と首を傾げているって事では
239 :名無しさん@お腹いっぱい。 :2022/08/18(木) 12:54:05.82 .net それは消えた i386-wine-devel のほうが今の wine よりバージョンが上だからでは そして wine-devel(7系?)では imm32.dll.so が無くなったせいなのか wime が動かないと
240 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:06:55.34 .net バージョンが上とかじゃないな wimeの作成環境に書いてあるのがwineのstableじゃなくて開発版だから wine-develなのか
241 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:16:54.17 .net 検証不可能だが要はこれが望む環境で使えんライブラリであると https://i.imgur.com/JtkfBpN.png 何をゴチャゴチャビルドだのdevelだの書いていると思ったわ /procがどうのこうのだの切り分けが半端だったんだから先ずは不満な人が 既存パッケージで作れる環境でいちから試せば少しでも前進するんじゃね
242 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:25:16.41 .net パッチ当てが必要とか書いてるみたいだけど必要ならソースあるよ https://github.com/wine-mirror/wine/tree/oldstable/dlls/imm32
243 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:30:26.82 .net >wine-devel(7系?)では imm32.dll.so が無くなったせいなのか https://github.com/wine-mirror/wine/tree/master/dlls/imm32
244 :名無しさん@お腹いっぱい。 :2022/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 :名無しさん@お腹いっぱい。 :2022/08/18(木) 13:54:20.83 .net ソース置き場まとめ wime君がつかってるやつ https://github.com/wine-mirror/wine/tree/wine-6.14/dlls/imm32 現行pkgのやつ(wine-6.0.4) https://github.com/wine-mirror/wine/tree/oldstable/dlls/imm32 quarterlyのwine-develのやつ(wine-devel-7.8) https://github.com/wine-mirror/wine/tree/wine-7.8/dlls/imm32
246 :名無しさん@お腹いっぱい。 :2022/08/18(木) 14:04:24.57 .net ソースが無いって話はしてないぞ imm32.dll.so が無くなった でも imm32.dll.so なんて言ってるのはwime君で作者じゃない linux でも7系では imm32.dll.so は無いようだ
247 :名無しさん@お腹いっぱい。 :2022/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 :名無しさん@お腹いっぱい。 :2022/08/18(木) 14:24:36.64 .net >imm32.dll.so あるよ latestの wine-devel-7.14,1 i386のパッケージを展開し確認 quarterly の7.8に同梱されているかはしらん
249 :248 :2022/08/18(木) 14:26:16.81 .net >>248 あ、微妙に違ってた imm32.dll はあるが imm32.dll.so というファイルは無い
250 :248 :2022/08/18(木) 14:29:49.29 .net >>249 >imm32.dll マジックナンバー文字列は「MZ」
251 :名無しさん@お腹いっぱい。 :2022/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 :名無しさん@お腹いっぱい。 :2022/08/18(木) 15:05:31.79 .net > i386 の quarterly の wine-devel-7.8,1.pkg > には無い +MANIFEST にも無い コレでええの?elfバイナリでは無い様だが https://i.imgur.com/944HNI4.png > latest の wine-devel-7.8,1.pkg 現在pkgに存在しないバージョンの様だが更新していないportsでもつかってんのかな
253 :名無しさん@お腹いっぱい。 :2022/08/18(木) 15:15:11.74 .net > 現在pkgに存在しないバージョンの様だが更新していないportsでもつかってんのかな コピペミス wine-devel-7.14,1.pkg
254 :名無しさん@お腹いっぱい。 :2022/08/18(木) 15:22:14.31 .net こちらもelfじゃないみたいだけど https://i.imgur.com/TnxdLCD.png
255 :名無しさん@お腹いっぱい。 :2022/08/18(木) 15:37:35.04 .net >>231 twm愛好家なんだ よかったらあっちのスレも盛り上げてよ
256 :名無しさん@お腹いっぱい。 :2022/08/18(木) 16:48:03.06 .net 13.1-RELEASE-p1 quarterly いつの間にか sysutils/fusefs-smbnetfs がふつうに使える様になっとる クライアントマシンとしてSMB2以降を使いたい人にはオススメ
257 :名無しさん@お腹いっぱい。 :2022/08/18(木) 23:05:18.33 .net 時代はarmやで
258 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:13:23.86 .net >>232 ん? よく意味が分からないです……。 悪いところがあれば直します。 助言者が欲しくて書いているようなものですから。 >>255 「あっち」?
259 :FreeBSDでwimeを使っている君 :2022/08/19(金) 02:14:57.99 .net あらやだ、すごいことになってるわ、困ったわね(意味深)。 画像のチカラってすごいのかな(意味深)。 ※こんなボケを書く雰囲気ではないんですけれど一応。
260 :FreeBSDでwimeを使っている君 :2022/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系の時に、 まったく動かなかったことが、2度あっただけで、 数日後に即、修正版が出ましたから、 Wineの「開発版」とはいえ、信頼しているから、です。 日本語入力メソッド総合スレッド@Linux@5ch掲示板 https://mao.5ch.net/test/read.cgi/linux/1472658083/30 でも勧めましたし。
261 :FreeBSDでwimeを使っている君 :2022/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を使っている君 :2022/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を使っている君 :2022/08/19(金) 02:38:08.60 .net 〔前からの続き〕 i386で作った(パッチをあてた)imm32.dllの場合、 C言語は読めませんが、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を使っている君 :2022/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を使っている君 :2022/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を使っている君 :2022/08/19(金) 02:44:48.25 .net >>233 >>235 >/usr/local/share/wine/pkg32.sh add 「パッケージのファイル名」 i386で作ったパッケージを「/home/ユーザ名/.i386-wine-pkg」 として持って来られるとは思っていませんでした。
267 :名無しさん@お腹いっぱい。 :2022/08/19(金) 02:46:02.99 .net >>263 pkg がビルドされているのは13.0R、13.1Rとはコンパイラのバージョンが違うので md5が違うのは当然
268 :名無しさん@お腹いっぱい。 :2022/08/19(金) 06:07:56.91 .net これは面白くなってきたぞ 乞うご期待
269 :FreeBSDでwimeを使っている君 :2022/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 :名無しさん@お腹いっぱい。 :2022/08/20(土) 07:58:43.18 .net いつまで続くのかじっくり見物させて頂くとしよう
271 :FreeBSDでwimeを使っている君 :2022/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を使っている君 :2022/08/21(日) 16:29:31.54 .net (注)基本に戻るのは大事だと痛感しました。 https://docs.freebsd.org/ja/books/porters-handbook/slow/ によると、やはりパッチは、ファイル名の頭に「patch」とつけ、 「patch-imm-magic-1.7.3」とし、内容も文頭の「wine-1.7.3」 のバージョンを削ったほうがよいようです make後、imm32.c.origが残っており、「+」の行が追加され 「-」の行が削除されていました。 コメント行も追加されていました。>>218 は間違いです。 ※ >>11 再まとめの際は注意。
273 :FreeBSDでwimeを使っている君 :2022/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 :名無しさん@お腹いっぱい。 :2022/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を使っている君 :2022/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を使っている君 :2022/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を使っている君 :2022/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 :名無しさん@お腹いっぱい。 :2022/08/21(日) 17:38:46.26 .net 32bit の libX11.so.6 があるディレクトリを ldconfig -32 で追加したら
279 :名無しさん@お腹いっぱい。 :2022/08/21(日) 17:40:48.50 .net https://github.com/chriswells0/freebsd-scripts ここの portsfetch で quarterly の ports tree が取得できる wine-devel も 7.8,1
280 :FreeBSDでwimeを使っている君 :2022/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を使っている君 :2022/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を使っている君 :2022/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からの慣れで、 「ウインドウを消すバツ(Xのロゴ)が最右端でないと、 使いにくいな」と、思ったことがあり、バツを最右端に する設定を、ググり中に見つけたが、バツを最右端にすると リサイズボタンが使いにくくなるのに気づいて、最右端は リサイズボタンなのだなあ、と、思ったことがあります。 よくあるウインドウのように隅っこでリサイズできると いいんだけど、窓枠が太くなるしなあ。 まあ、気をつけておきます。
285 :FreeBSDでwimeを使っている君 :2022/08/21(日) 20:33:20.83 .net それで思い出したけど、最近のGNOME系かな、 ユーザーサイド側の窓の装飾ってどうなの、と思う。 Window Manager を考えなくてもよいので、 管理の負担が減るとか、アプリケーション内の入れ子で 表示しやすい、というのが、あるのかもしれないけれど、 X Window Systemの考え方からは、逆行しているように思う。 もし、ユーザーサイド側の窓の装飾を、流行などで、 コロコロと変えられたら、ユーザ側からは地獄でしょ。 それに、そういう事をすると、逆に古びると思う。 「スマホ風のUIだって、プギャー」って時代も来るだろうし。
286 :名無しさん@お腹いっぱい。 :2022/08/22(月) 04:36:00.32 .net >>281 使ってないから知らなかったが net/gitup 見たら gitup.conf.sample に quarterly の設定もあるな ports の更新もこれ使えばいいんじゃね
287 :名無しさん@お腹いっぱい。 :[ここ壊れてます] .net portsfetch でも更新できるから どちらでもいいが
288 :FreeBSDでwimeを使っている君 :2022/08/23(火) 23:04:25.61 .net 「portsfetch」の、ご紹介ありがとうございました。 ありがたいShellScriptですね。 VirtualBox6.1.36内のFreeBSD13.1R/i386で、portsfetchを 動かしたところ、動作中にリブートがかかりました。 portsfetch内から追加パッケージをインストールしたまま 動かしていたからなのか、負荷がかかりすぎたのか、は 不明です。 ですが、リブート後、再度、portsfetch したら (何かを取得し直しになりましたが)、PortsTreeが quarterlyになりました。
289 :FreeBSDでwimeを使っている君 :2022/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を使っている君 :2022/08/23(火) 23:08:37.37 .net 〔前からの続き〕 Wineは、7系から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を使っている君 :2022/08/23(火) 23:10:33.94 .net Wine7.x系で、64bitで動くソフトウェアからの印刷は 試していませんが、32bitWine側で、 「lpd_enable="YES"」とか「/etc/printcap」 みたいなことができれば、使えるような気もします。 参考: Wine - ArchWiki https://wiki.archlinux.jp/index.php/Wine#.E5.8D.B0.E5.88.B7 >win32 prefix で wine アプリケーション (例: MS Word) を使って >プリンター (ローカル・ネットワーク両方) を使用するには >lib32-libcups パッケージをインストールしてください。 ※ArchWikiは良いですよね。 大昔によくあったXでの設定も、ちゃんと載っていますし。
292 :名無しさん@お腹いっぱい。 :2022/08/24(水) 11:18:10.74 .net 素直に pkg32.sh で cups インストールして設定すればいいと思うが
293 :名無しさん@お腹いっぱい。 :[ここ壊れてます] .net wime君育成ゲームスレっぽくなってきた
294 :FreeBSDでwimeを使っている君 :2022/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を使っている君 :2022/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設定手順 ブラウザで「http://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を使っている君 :2022/09/12(月) 00:34:36.18 .net □いまさらながらCUPSを試す 3/3 以上の手順で、CUPSで印刷できます。 実際に、leafpadと、libreofficeで、印刷できました。 印刷キューは「http://localhost:631/jobs/ 」で見えました。 参考にしたサイト: HL-5380DN, Debian http://bm.skr.jp/linux/5380dn.html Linux上で印刷する (CUPSを設定する) - Let's Try It! https://www.letstryit.net/2010/03/linux-cups.html FreeBSD10.0システムインストール http://web.cc.yamaguchi-u.ac.jp/~hiroshi/FreeBSD/OKI-C610dn.html 5.5 プリンタの設定 | あらかると https://www.starlink.jp/freebsd/freebsd-cups/
297 :FreeBSDでwimeを使っている君 :2022/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を使っている君 :2022/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 :名無しさん@お腹いっぱい。 :2022/12/29(木) 07:50:25.01 .net Wineなんか使わん
300 :FreeBSDでwimeを使っている君 :2023/01/08(日) 22:04:08.77 .net 備忘録。 タイミングで該当バージョンに当たった人がいるかもしれませんが firefox-105は避けた方がよいようです。 Firefox-ESRが105固定になりませんように。 https://mevius.5ch.net/test/read.cgi/unix/1632283136/154-171
301 :名無しさん@お腹いっぱい。 :2023/01/09(月) 00:42:11.77 .net Firefoxは常に最新使ってるが105の時も落ちた事はないな なおESRになるバージョンは決まってる https://wiki.mozilla.org/Release_Management/Calendar
302 :FreeBSDでwimeを使っている君 :2023/01/10(火) 00:59:24.05 .net あ、やっぱり、1つだけの報告の場合、 判断は保留したほうがいいのか。 つい、飛びついちゃうな。 ReleaseCalendarは知りませんでした。 ありがとうございました。
303 :FreeBSDでwimeを使っている君 :2023/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を、 たばねた(注1)ような状態(注2)であるのは、 Wineの開発方向を把握した上で、将来的に対応しやすいように 配慮してあるのかもしれません。 「/usr/local/share/wine/pkg32.sh install wine mesa-dri」として、 pkg(8)の指示による、ユーザ実行のShellScriptで、 32bit版のWineを、ユーザのホームディレクトリに インストールしなくてもよくなる方向か、と思います。 注1:別々に存在する物を同時に使えるようにしてある。 注2:Linux版も同様の状態かもしれませんが、執筆者は Linuxを知らないのでわかりません。 ※投稿時に、書き込みの末尾に、自動的にゴミがつくので twitterURLの先頭部分をカットしています。
304 :FreeBSDでwimeを使っている君 :2023/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 https://www.winehq.org/announce/8.0 「Wine 8.0」がリリース 〜LinuxでWindowsのGUIアプリを直接実行できる互換レイヤー - 窓の杜 https://forest.watch.impress.co.jp/docs/news/1473266.html 今夜も Wine で乾杯! - 23本目 https://mao.5ch.net/test/read.cgi/linux/1585198566/744-n >このリファクタリングが完全に完了すると、 >基幹のkernel32.dllやgdi32.dll、user32.dllすら >wineのからwindowsのに差し替えても動作するはずなので、 >理屈の上では互換性がさらに向上するはず (中略) >従来の64bit Linuxで32bitバイナリを動かす仕組みではなく、 >64bitWindowsと同様の仕組みで32bit windowsバイナリを実行できる >新しいWOW64が実装された
305 :FreeBSDでwimeを使っている君 :2023/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が修正される可能性も、あるかと思われます。 (備考1) 大昔の事で、どこで読んだか忘れましたが、 既知情報として、MicrosoftOffice付属などのMicrosoftIMEは、 Wine環境下にInstallできない(エラー停止)、とされています。 (備考2) Wine8系のportが進まないのか、FreeBSDのVersionUpのタイミングに 合わせるのか、一般ユーザには事情が分かりかねますが、FreshPortsに よると、現時点で、FreeBSDのwine-develは、7.22,1です。
215 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200
本文 スレッドタイトル 投稿者