BSD/LinuxでのOffice/Desktop環境を語れ！ Part03
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/ >>1乙
メンテナにはなんとか頑張って頂いてwine復活すると良いですな この件に関してこちらの方が適切でしょうから
近日検証してこちらへご報告させて頂きます
https://mevius.5ch.net/test/read.cgi/unix/1630061644/67
> 67 名無しさん＠お腹いっぱい。 sage 2021/09/11(土) 19:39:29.55
> 今更かも知れんけど、FreeBSDでzoom視られんのな(firefox) >>3
Firefox93 にて zoom 試してみました
カメラはロジクールC505
/etc/rc.conf に以下を追記
kld_list="普段ロードしているもの cuse"
webcamd_enable="YES"
結果
https://i.imgur.com/i0fQopw.jpg
普通に使えますね
もしカメラ認識が芳しくない時は multimedia/webcamoid を入れてごにょごにょすると宜しいかと
webcamoid で映る時は zoom でも普通に映ったので >>3
そうそう
LinuxABI互換機能は有効にしておく必要があるでしょう https://mevius.5ch.net/test/read.cgi/unix/1107211157/992
> 992 名前：FreeBSDでwimeを使っている君 [sage]： 2021/10/06(水) 19:48:39.70
> ○FreeBSD(amd64)のi386-wineならVersion6以降でも動くかも？
latest の i386-wine-devel-6.12,1、なんか使えるみたいですよ
使えるようにする為に実施したことはこれだけです
% doas pkg install i386-wine-devel
% wineboot
notepad+ と JaneStyle をお試しでインスコし普通に使えてます >>4
テスト乙
Firefoxをバージョンアップするかな
その前にまずFreeBSDをバージョンアップしたいけどｗ >>7
FuryBSDだとデフォのまんまでWebカメ使えたんですが無くなっちゃいましたからね
ついでにESRでもテストしてみました 問題ないですね
https://i.imgur.com/yPgjG8m.jpg
> FreeBSDをバージョンアップしたい
サクッと make world イキますか wime
https://thomas66.web.fc2.com/wime/
4.1.4 2021年9月26日
まれではあるが、よくURLが貼られているので、自分として制限をしている
「wimeの公式URLは、迷惑にならないよう、むやみに貼らないよう、気をつける」を
解除する事とします。
https://mao.5ch.net/test/read.cgi/linux/1472658083/124
にも告知しました。 □FreeBSDにおけるwime導入手順の再まとめ(2021/10/18)
wimeとは、Wine環境下にインストールされたWindows用日本語IMEを
Cannaサーバに見せかけて、Unix界に蓄積されたCanna系ソフトウェアを
そのままで使えるようにする、というものです。
ここでは、もっともシンプルに、Cannaとして使う方法を記述します。
ただし、Wineが正常に動く事が大前提となります。
※初出 https://mevius.5ch.net/test/read.cgi/unix/1107211157/804-n
□環境 FreeBSD(i386)
ports : wine , wine-devel
どちらでもよい。ただし、現在のFreeBSDでは、
i386において、Wine5.8以降は、makeは通るが、バイナリは動作しない。
※https://mevius.5ch.net/test/read.cgi/unix/1107211157/919-n
amd64のi386-wineでは、メンテナのAlexander88207氏の対応により、
Wine6.0/Wine6.12は動作する。
※https://mevius.5ch.net/test/read.cgi/unix/1633521461/6
pkg : ja-canna-lib-3.7p3
wimeをmakeするために必要。
現在では、ja-canna-libが、ja-canna-serverに依存していないので
ja-canna-libだけを入れればよい。
pkg : gmake-4.x
wimeをmakeするために必要。
wime-4.x.x.tar.bz2
公式サイトより取得の事。 ■ portsのWineに、wimeのimm-magicパッチをあてる
1. % /usr/bin/tar xvzf wime-4.x.x.tar.bz2（ユーザ権限でよい）
2. ほどいた wime-4.x.x/patch/imm-magic-1.7.3 の記述内容を変更。
最初の２行の両行とも、以下のようにバージョン名を削除。
wine-1.7.3/dlls/imm32/imm.c → dlls/imm32/imm.c
※すべきかどうかわかりませんが、patchの文法を知らないので。
現在の判断（未検証）ですが、おそらく内容変更も、
ファイル名変更も、しなくてもよいと思います。
3. wimeのimm-magic-1.7.3 を、patch-imm-magic-173 などと
ファイル名を変更し、
/usr/ports/emulators/wine/files/patch-imm-magic-173
などとして置く。
※リネームはしなくてもよいと思いましたが、すでに置かれている
他のパッチの命名方法にならいました。パッチをあてる順番の
正解はわかりませんが、imm.cを見ると、C言語は分かりませんが
パッチ通りに変更されているように思えました。
4. ports/emulators/wine 下で、「# make ; make install」
私はmakeオプションは特に変えませんでした。
make install一発でも、portinstallとでも、お好きにどうぞ。
つまり、あらかじめ、wimeのパッチをwineのportsの
パッチ置き場（wine/files）の下に置いておくのがポイントです。 ■ wimeをmakeする ※gmakeが必要
1. wime-4.x.x/conf.mk を対象に、wimeのmake時の変数を変更。
PREFIX?=/usr/local ※FreeBSDでは、このままでよい。
WINEDIR?=/usr/local ※FreeBSDでは、このままでよい。
WOW64?=1 ※「WOW64?=0」へ変更。
※FreeBSD(i386)で32bitOSなので、Wineも32bit版となるため。
USE_CLANG?=0 ※FreeBSDでCLANGなので「USE_CLANG?=1」へ変更。
※「USE_CLANG?」の記述がない場合は、単なる書き落としです。
処理内容は、conf.mkの末尾に存在するので、書き足してください。
「USE_CLANG?=1」がない場合、gccでコンパイルされてしまい、
FreeBSDでは動作しないバイナリができます。
2. wime4.x.x下で、ユーザ権限でよいので「% gmake」。
3. root様で「# gmake install」し、root様で「# ldconfig」。
■ ATOKをWineへインストール
1. 「wine setup.exe」などとして、ATOKをWine環境下へインストール。
2. 「wine regedit.exe」し、
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts
の「E0020411」を「E0010411」に変更。
3. 上記レジストリキーの「Ime File」が、フルパスつきの「atok??w.ime」
であった場合、パス部分を削ってファイル名のみに変更する。
■ winecfgでの注意
「/usr/local」を W: ドライブなどのドライブに割り当てておく。
そうしないと、Wineからは「/usr/local」以下が見えないので
wime起動時に「wine:cannot find 'wime.exe.so'」と言われて
起動できません。 ■ wimeの実行
wime4.0.0以降では、「wime -e atok」で起動する。
■ wimeによるWindows版ATOKでの変換を試す
ng-canna（注１）は、設定せずに、直接Cannaが扱えるので、
ng-cannaなどで、ジャストシステムのサイトで例示されている
二重敬語の校正指摘の例文を変換してみるとよいでしょう。
変換候補が以下のように表示されればATOKが動いています。
「お読みになられる《二重敬語「→お読みになる」》」
あとは、canna.el（注２）でも、yc.el（注３）でも、
scim-canna（注４）でも、kinput2 -cannaでも、
あたかもCannaServerを使っているかのように使用できます。
もちろん、この場合は、.cannaも読んでくれますので、
.cannaで、変換候補を１回で開くような設定をしていても、
(setq romkana-table "KANAinput_JibunKeyBoard.kp")
みたいな設定をしていても大丈夫です。
（注１）Emacs like。pkg(8)では「ja-ng-canna」。
（注２）現在のほぼ公式と言ってよい、
https://ikumi.que.jp/cmp/emacs.html
での、canna.elは、執筆者としては、yc.elで
満足しているため未検証です。
昔ながら（Muleなど）のcanna.elは、ng-cannaで
いけるので大丈夫だと思います。
（注３）公式サイトは http://www.ceres.dti.ne.jp/~knak/yc.html 。
pkg(8)に「ja-yc.el-emacs27」などとして存在する。
（注４）https://mevius.5ch.net/test/read.cgi/unix/1107211157/993-n □FreeBSD(amd64)でwimeを使う場合
FreeBSD(amd64)でもwimeは使えますが、32bitなATOKの場合、
i386-wine , i386-wine-devel で使用する事になります。
また、wimeも32bit版をmakeしないといけませんので、
実機のi386機なり、仮想環境のi386でmakeし、ファイルコピーなどで
wimeのバイナリ群を持ってくる必要があります。
※amd64でwimeを32bitとしてクロスコンパイルできれば、
持ってくる必要はありません。
また、32bitなWineでパッチがあたった「imm32.dll.so」も、
amd64のi386-wineに持ってくる必要があります
※i386-wineで、wimeのパッチがあたるかは、執筆者は未検証。
i386でWineにパッチをあてた「imm32.dll.so」は、
i386-wineに持ってきても、単純なファイルコピーで動きます。
・imm32.dll.soを配置する場所。
amd64(i386-wine)/usr/local/lib32/wine/imm32.dll.so
i386(wine) /usr/local/lib/wine/imm32.dll.so
・makeされたimm32.dll.soのバイナリが置かれている場所。
※portsでは、該当ディレクトリのworkの下に
インストール前のバイナリが置かれている。
※以下は5.0でのパス。
emulators/wine/work/wine-5.0/dlls/imm32/imm32.dll.so
なお、thomas氏によると、FreeBSDでは、64bit版ATOKは
インストールできなかったそうです（公式サイト）。 □年度別のATOKのwimeでの動作状況
2004 ○ https://mevius.5ch.net/test/read.cgi/unix/1107211157/804-n
※執筆者によるCannaServerとしてのみの検証
2008 ○（公式）動作する
2010 ○（公式）動作する
2011 ○（公式）動作する
2012 ○（公式）動作する
2014 ×（公式）動作しない（詳しくは公式サイトで）
2015 ○（公式）動作する
2016 ○ https://mao.5ch.net/test/read.cgi/linux/1472658083/24-n
※おおむね動作する
2017 △（公式）動作するが（詳しくは公式サイトで）
※試用版と製品版では動作が異なる可能性があります。
※他年度版の動作状況があれば、報告していただけると幸いです。 □現在執筆者が把握する似たような手法としての他の成果物一覧
※URLは省略しました。ググれば出ます。
・えせかんな(esecanna)
商用のVJE3.0/2.5,Wnn6をCannaクライアントで使う。
現在もFreeBSDには存在する。
japanese/esecannaを参照の事。
・ximimm
Windows版ATOKをWine上で動かし、LinuxのX11上のXIMから使用する。
2010年の製品版で動作確認、
2014年の体験版はインストールできず、との事。
・canna2imm32
Cygwin環境下で、Cannaプロトコルにより、Windows側のIMEを使う。
・FepBridge
DOSエミュレータで、DOS/VのFEPを動かして、Unixから使う。
・(OMRON)Wnn8 for Linux/BSD ※似たような手法ではありませんが。
現在も販売されているLinux/BSD用の商用かな漢字変換。
IIIMF(wnn8le)、XIM、GTK2系。
有志によるWebの知恵によると、Wnn7Egg、esecanna、
tamago-tsunagi（修正すれば）で、使う事が出来るとの事。
※公式によると、FreeBSD12.1R以降ではamd64のみ対応、との事。 wimeで割り込んですいません。FreeBSDでwimeを使っている君です。
レスを見ていると、みなさんに支えられているなあ、と思います。
これからもよろしくお願いします。
「FreeBSDでwimeを使っている君」がセッセと書く理由は、
高スキルユーザ（パワーユーザ）さんなり、開発者さんなりの
目に止まり、事態が打開されて欲しいがためです。
今夜も Wine で乾杯! - 23本目＠Linux
https://mao.5ch.net/test/read.cgi/linux/1585198566/449
というレスも書きました。
（注）YAHOOのリアルタイム検索（事実上のTwitter検索）では
「wime」というアカウントが存在するようです。 >>3
FreeBSDを語れ Part54 の「zoom」のやりとりを見ていました。
動画が視られるだけでも、すごいと思います。
ただ、zoomでは音声が通らないという話でしたね。
>>6
ウッ、ブワッ（涙）。
わざわざ試していただき、ありがとうございます。
やはり、Wine6.x系は、i386-wineで動きましたか。
いっぱいググって、Alexander88207氏の生の声を
探し当てた甲斐がありました。 >>18
> zoomでは音声が通らない
うちの者の携帯電話との同室セッションでハウリングを起こすくらい問題ありませんでした
環境によりきりかも知れませんが
しかしさすがここの主wimeさん
スレが一気に本格的になりましたな >>19
但しこう言う事なのでしばらくはWebブラウザ版で利用する事になるでしょうね
% psearch -c net-im zoom
net-im/zoom Zoom videoconferencing client (CAVEAT: 【Sound doesn't yet work】) ここ「BSD/LinuxでのOffice/Desktop環境を語れ！」なんだが
「UNIXの定義」について語りたいの？めんどくさい人だね 「FreeBSDにおけるwime導入手順の再まとめ」
において誤りがあったと思います。
>>14 に、amd64のi386-wineに対して、
（i368でコンパイルした）「wimeのバイナリ群を持ってくる」
とか、
「クロスコンパイルできれば」
とか、
などと、書きましたが、誤っているのではないかと思います。
wime-4.x.x/io/Makefile には、「#amd64でi386-wineを」の
コメントがあるので、FreeBSDのamd64でi386-wineを
使用している場合、wime-4.x.x/conf.mkで変更する変数を
「WOW64?=1」にすれば、amd64でも、wimeを32bitでコンパイル
できるのではないかと思います。
https://mevius.5ch.net/test/read.cgi/unix/1107211157/836
で謝罪したのを忘れていました。
まことに申し訳ありませんでした。
※執筆者はC言語もMakefileも理解していないので、
はっきりと書けずに申し訳ありません。 本日とある用事でWebブラウザ版zoomをFirefoxから使用しました
序盤に音声の送信が滞ったものの少しごにょごにょして改善し普通に音声通話も可能になりました
ご使用の際はwebcamoidもインスコしておくと事前に送信映像の解像度も手軽に出来て便利です 執筆者が書く時だけは、目立つようにスレをageさせてください。
5chのクロールコピーっぽいサイトは、いっときより減ったものの、
まだまだ健在なので、情報が広がりやすいと思うのですが、
なかなか、「FreeBSDでWine6.xを使ったよ」「wimeはすごいねー」
という声は見かけませんね。
情報を広めるのは、大変なんですね。
そもそも一夜にして情報が広がるなんてオカシイですよね。
FreeBSDの公式サイトのリリーススケジュールが見つかりません。
昔は日付を入れて表になっていたような気がするんですが。
13.0Rの次のリリーススケジュールは、いつか分かりませんが、
あと半年ほどは、13.0Rのままだろう、今のうちに、と、
FreeBSD13.0R(i386)から、FreeBSD13.0R(amd64)に乗り換えました。
もちろん、目的はWine。
i386-wineの、Alexander88207氏の「回避策」に期待がかかります。
i386-wineですから、おそらく、次のFreeBSDのメジャーバージョンまで、
i386-wineのバージョンは、ほぼ固定状態になると思いますが、
なにより、確実に動くことが大切です。
結論から言うと、FreeBSD(amd64)で、Wine6.12(i386-wine-devel)は
動きました。
「ウヒョヒョヒョヒョヒョ」とスキップして踊りました。
みなさま、ありがとうございます。ありがとうございますう。 ただですね、>>6 氏の報告とは、やや、挙動が違いました。
FreeBSD13.0R(amd64)で、i386-wine-devel(Wine6.12)の
初回起動時に「%winecfg」（.wineの新規生成はせず）とすると
wine:could not load ntdll.so:(null)
と、言われますが、前スレであった助言
https://mevius.5ch.net/test/read.cgi/unix/1107211157/951
のように、以下のように環境変数を設定すると正常起動しました。
%env WINEDLLPATH=/usr/local/lib32/wine winecfg
Wineのビルトインコマンド的な、winecfgではよいのですが、
実際に、hoge.exeを動かす時に困ります。
%env WINEDLLPATH=/usr/local/lib32/wine wine hoge.exe
のように書かないといけない。
これはまずい。wimeの起動はどうすべきか。
けっきょく、.cshrc（.xinitrcなどでもいいけど）に
「setenv WINEDLLPATH /usr/local/lib32/wine」
と書く事にしました。 執筆者は、Wine6.12のimm32.dll.soとwime4.1.4は、
i386でコンパイルされたバイナリをファイルコピーで
持ってきました。
>>14 のまとめの修正ですが、
FreeBSD(amd64)のi386-wine-devel(Wine6.12)では、
imm32.dll.soを配置する場所が以下のように変わりました。
「/usr/local/lib32/wine/i386-unix/imm32.dll.so」
しかし、なんで >>6 氏と挙動がちがうのだろう。
・shか、cshの違い？
執筆者はtcshです。
・モダンなデスクトップか、昔ながらのWindowManagerの違い？
執筆者はctwmです。 以下の記事を読んで気づいたのですが、
今どきのWineの初回起動は、「%winecfg」でなく、
>>6 氏のように「%wineboot」とするもののようです。
Wineについては、あくまでもPlamoLinuxでの例ですが、
PlamoLinuxのメンテナ、こじまみつひろ氏が、
技術評論社で連載している記事が、理解を深めてくれます。
続・玩式草子 −戯れせんとや生まれけん−：連載｜gihyo.jp … 技術評論社
https://gihyo.jp/lifestyle/serial/01/ganshiki-soushi-2 GenericKernelでPAE_Kernelとなったi386(Tier2)から
amd64(Tier1)に乗り換えて思ったんですが。
・amd64は、startxでコンソールからXを起動するのに数秒。
i386みたいに、15秒待つなんてことはない。
・なんだか全体的に軽いような。キビキビしているような。
・そもそも、ブートからlogin表示までも、amd64の方が速いような。
・Conky読みだけど、メモリ総量が違う。i386は15.6G、amd64は15.5G。
※ビデオカードのメモリ量が512Mです。
・i386では、Firefox90以上で、「Gah. Your tab just crashed.」と
言われて、googleマップが見られなくなったり、アクセスによって
画面を生成するタイプ（うまく言えないですが、後面描画の後に前面
を描画するタイプ）のサイトが見られなくなったりしていたので、
FirefoxESR78にportdowgrade（戻れるバージョンがそれしかなかった）
していたが、amd64ではFirefoxESR91で普通にgoogleマップが見られる。
いや、ま、それが普通だよね。
・i386のFirefoxESR78の設定画面で、検索エンジンを選択する欄が
空っぽで、検索エンジンの追加もできなかったので、しかたがなく、
文字列をマウスでコピーして右クリックでgoogle検索をするadd-onsを
入れていたが、FirefoxESR91だと普通に検索エンジンがある。
EUとかの政治的な規制で検索エンジン欄が空になったんじゃないのか。
あれは何だったんだよお。
・i386のFirefoxESR78では、5chのスレで文字列をマウスでコピーして
右クリックをすると、ImageをSaveとか、Playだとか、Volumeだとかの
メニューが画面の上から下まで出ていた。ただのテキストを扱うのに
なんでマルチメディアなメニューが見境なく出て来ていたんだろう。
という感じです。 広大なメモリを使いたければ、amd64(64bit)が、普通の選択肢であり、
PAE_Kernelは「無理を承知でどうしても」のための物なのかも
しれません。
PAE_Kernelを追いかけていた「uyota 匠の一手」氏も、
そういう感じで使っているようですし。
そうそう、VZエディタライクなエディタの「ne」（pkgで入れた）は、
amd64ではセグメントエラーでした。
i386では動いていたような気がするけどなあ。
「PANIXのカタログに、そういう物がありますよ、って出てたなあ」
と、入れただけなんですが。
VZエディタのキーアサインで覚えているのは、
Ctrl-K-K、Ctrl-K-C、コマンドラインでESCでファイラ、
ぐらいで、Emacs歴のほうがずっと長くなりました。
FreeBSD13.0R(amd64)でi386-wine-devel(Wine6.12)が
動いて、回避策の対応をしていただいたMaintainerの
Alexander88207氏には大感謝です。
さーて、夜食でも食べてくるかなーあ。
うは、うほほーい。 長いことemacs+wanderlustを使ってたけど、キーバインドを覚えるor調べるのに疲れて、
thunderbirdに乗り換えちゃったよ >>33
グッジョブ！ コンピュータなんて楽できてなんぼだからね >>29
当方環境
OSバージョン：FreeBSD 13.0-RELEASE-p4 amd64(当時)
インタラクティブシェル：/bin/tcsh
GUI環境：Window Maker、Fluxbox 等
たまにモダンなデスクトップ環境も使用しております # pkg upgrade
Installed packages to be REINSTALLED:
dialog4ports-0.1.6_1 (option removed: CHINESE)
新しい冷戦が始まる（始まっている）と言われていますが、
米中新冷戦って意味合いでremovedなんでしょうか。 >>29
wimeの事を書き忘れていましたが、
FreeBSD(amd64)のi386-wine-devel(Wine6.12)において、
i386でコンパイルされたimm32.dll.soをファイルコピーで
持ってきて、
「/usr/local/lib32/wine/i386-unix/imm32.dll.so」に
置いたことにより、
Wine6.12 + wime4.1.4 + ATOK17(2004)で動いています。
>>35
6氏、ありがとうございます。
6氏もプロンプトに「%」を使っているので、csh系だと
思っていたのですが。
Wineの開発ターゲットはLinuxだから、bashだと問題ないのか？とか、
モダンなデスクトップだと勝手に設定を追加してくれるのか？などと、
考えたのですが、執筆者と、6氏 との間には、有意な差は、
ないような気がします。何かが違う「おま環」かもしれません。
まあ、私は、.wineの新規生成もしなかったですし。
もし、i386-wine(6.x以降)において、
「wine:could not load ntdll.so:(null)」
と、言われた場合（例はcsh系の場合）、
「%env WINEDLLPATH=/usr/local/lib32/wine winecfg」
としてください。 何気なくググってたら驚きました。
259587 emulators/i386-wine{-devel}: Delete ports (was: Fails to fetch: i386-wine-devel-6.12,1.txz: Not Found)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259587
D32322 emulators/i386-wine{-devel}: Delete ports
https://reviews.freebsd.org/D32322
Alexander氏によると、通常のWineで32bit、64bitが扱えるので、
i386-wine{-devel}は、削除要請されているとのこと。
ports/emulators/wine-devel/Makefile を見ると、
「a subset of emulators/i386-wine-devel」とか書いてあって、
i386-wineの成果が吸収されるのかもしれません。
これからは「３つのパートに分かれる」そうです。
wine 32bitなWineで32bitなEXE(FreeBSD/i386)
wine64 64bitなWineで64bitなEXE(FreeBSD/amd64)
wow64 64bitなWineで32bitなEXE(FreeBSD/amd64)
wine32 wow64が代替予定とのこと
と言うことですが、現状を把握していないので、よく分かりません。 FreeBSD13.0(amd64) ※以下レス用に1byte空白連続→2byte空白
# pkg remove i386-wine-devel
# pkg install wine-devel
% pkg info |grep wine
wine-devel-6.18,1 Microsoft Windows compatibility environment
% wine <TAB>
wine wineboot wineconsole winedump winegcc winepath
wine64 winebuild winecpp winefile winemaker wineserver
wine64.bin winecfg winedbg wineg++ winemine
% wineboot
/home/hoge/.i386-wine-pkg//usr/local/bin/wine doesn't exist!
Try installing 32-bit Wine with
/usr/local/share/wine/pkg32.sh install wine mesa-dri
% /usr/local/share/wine/pkg32.sh install wine mesa-dri
pkg -o ABI=FreeBSD:13:i386 -o INSTALL_AS_USER=true -o RUN_SCRIPTS=false --rootdir /home/hoge/.i386-wine-pkg install wine mesa-dri
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100% 163 B
Fetching packagesite.pkg: 100% 6 MiB
pkg: Error opening the trusted directory /usr/share/keys/pkg/trusted
pkg: Error loading trusted certificates
Unable to update repository FreeBSD
Error updating repositories!
# /usr/local/share/wine/pkg32.sh install wine mesa-dri
Don't run this script as root!
※rootで走らせるな、は、どこかに書いてありましたが、
一応やってみました。 259697 emulators/wine /usr/local/share/wine/pkg32.sh upgrade: pkg: wrong architecture: … pkg: repository poudriere contains packages with wrong ABI: FreeBSD:14:amd64
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259697
>>39 に関して上記のような記事もみつけましたが、微妙に違う気もします。
つい最近の話ですし、状況が落ち着くのを待ちます。
あー、FreeBSDの現在のWine事情を解説してくれる記事はないものか。
技術評論社のWebでのFreeBSDの連載は、とうの昔に終わったし、
紙媒体でなら、なんて、とても無理な話です。 >>37-38
大した用途に使っていない事もありますが今のところ正常動作ですね
i386-wine-develのdistfileに関しては驚きですね 確かにportsディレクトリで # make fetch しても落ちてきませんでした
取り敢えず # pkg create i386-wine-devel しておきました いつ入手不可になるかわからないので FreshPortsを、今、見るとi386-wine-develは、
もう無くなっています。
i386-wine、wine、wine-develは、
2021/11/16 14:33:56 に更新され、
更新内容は同じ文章です。
＞Emulator/i386-wine-devel. port removed.
＞This port and the pre-built binaries have not been updated recently.
＞emulators/wine-devel now supports i386 on amd64, so remove it.
との事です。
wine-devel-6.21なら正常に動くんでしょうか。
Wineに関わるMaintainerとして、Alexander88207氏、
以外の方は、にわかに信用しがたいのですが。
これ、
「動くようになったから、俺の役割は終わりだ。ヨカタ」
なのか、
「チッ！ じゃあ、i386-wine は、消せや！」
「distfiles も消してやる！ ザマーみろ！」
なのか、このへんの雰囲気が分からないので、困惑します。
distfilesで取得できるファイルが、即、消されて、
円満別れなのか、そうでないのか、ゾワゾワします。 Wine6.21時点での、emulators/wine{-devel}/files の
wow64.sh（長いものはレス用に桁折り）を見ると、
「I386_ROOT="${WINE_i386_ROOT:-$HOME/.i386-wine-pkg}"」
と、i386-wine-pkgをホームディレクトリの下に作り、
32bitなEXEは、
「exec "$I386_ROOT/$PREFIX/bin/wine" "$@"」
で起動するようです。
※執筆者の場合は、>>39 の試行で作りかけで止まっていた。
当たり前ですが、以下の引用のように
Wine64とWine32(WoW64)のバージョンは同一に保たれるようです。
「printf "wine [%s] and wine64 [%s] versions do not match!\n\n"
"$WINE32_VERSION" "$WINE64_VERSION"」
「printf "Try updating 32-bit wine with\n\t%s\n"
"$PREFIX/share/wine/pkg32.sh upgrade"」
まさか、i386-wine-pkgはバイナリ配布ではないでしょうね？
まあ、今は、数週間レベルでの本当の過渡期ですから、
Wine32からWoW64に完全移行してから試そうかと思っています。 FreeBSD(amd64)からi386-wine{-devel}がなくなり、
FreeBSDでのWineの、WoW64移行をふまえたうえでの、
wimeについて。
現状では、64bitなatokが、FreeBSDのWine64にインストールできない
（wime公式）ので、人柱の試行で発見されるなど、事態が変わらない限り、
FreeBSDのWineでは、atokは32bit版を使う事になります。
※今度のFreeBSDでのWineの変更で、Linuxのように、64bitなatokが
使えるようになっているかもしれません。
これまでのレスの内容をふまえると、32bitなimm32.dll.soは、置き場所が
変わるという事になります。
i386-wine-pkgが、バイナリ配布かどうかは、分かりませんが、
自前でportsからmakeできるのなら、
wimeのpatchをあてた32bitなimm32.dll.soが
amd64のWineで作れるのではないか、と、思います。 >>25 の追記。
FreeBSD(amd64)のi386-wine-devel(Wine6.12)では
「WOW64?=0」「WOW64?=1」どちらも、
wimeのgmakeが通りませんでした。
~/wime-4.1.4 % gmake
（略）
gmake[1]: ディレクトリ '/usr/home/hoge/wime-4.1.4/lib' から出ます
gmake -C so
gmake[1]: ディレクトリ '/usr/home/hoge/wime-4.1.4/so' に入ります
gmake[1]: *** 'wimeapi.o' に必要なターゲット 'X11/keysym.h' を make するルールがありません. 中止.
gmake[1]: ディレクトリ '/usr/home/hoge/wime-4.1.4/so' から出ます
gmake: *** [Makefile:12: so] エラー 2
libまではmakeできていますので、
~ % file /home/hoge/wime-4.1.4/lib/array.o
/home/hoge/wime-4.1.4/lib/array.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), with debug_info, not stripped
64bitなオブジェクトができてます……。
32bitなライブラリを見せてmakeすれば、32bitなバイナリが
できると思うのですが。 https://reviews.freebsd.org/D32322
＞gerald added a comment. Mon, Nov 15, 11:15 PM
＞For the actual commit, I'll list you as author anyway.
Alexander88207氏とgerald氏がケンカしている訳ではないようで
安心しました。
ただ、過渡期真っ最中のようで、低スキルの執筆者としては、
Wineのバージョンが、いくつか上がってこなれるまでは、
試せません。 i386-wine-develが、即、消えたのはともかく、
i386-wineは残っていたので、ある程度までは残しておくんだ、と、
思っていましたが、今、FreshPortsを見ると消えています。
https://reviews.freebsd.org/D32322
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259589
アメリカ時間だと思いますが、2021/11/19の昨日には、
i386-wine{-devel}は、なくなり、wine{-devel}へ、一本化されたようです。 前スレの「その２」に書いた、yc.elの話で、おわびと言うか、
「その後」に、かなり遅いタイミングではあるものの、
「気づいた」という話をします。
https://mevius.5ch.net/test/read.cgi/unix/1107211157/916
emacs27.1で、yc.elを起動すると「process-kill-without-query」の
エラーが出るが、twitterの「shg@shg」氏の説明と、助言により、
.emacsに以下のコードを書いて一応の解決を見たという話です。
＞(defun process-kill-without-query (process &optional flag)
＞(set-process-query-on-exit-flag process nil) 偶然、気づいたのですが、FreeBSDのyc.elのPorts（5.2.1_17,1）側で
修正が入っていました。
この場合、.emacs側で「のりきる」コードを書くより、yc.el側の修正の
ほうが、正しい解決方法であると思います。
FreshPorts -- japanese/yc.el: Yet another Canna client for Emacs
https://www.freshports.org/japanese/yc.el/
＞5.2.1_17,1
＞04 Dec 2020 12:41:09
＞The "process-kill-without-query" function was made
＞obsolete in emacs 27.1 [1]. Therefore the function
＞should be replaced in japanese/yc.el by
＞"set-process-query-on-exit-flag" function.
「Submitted by: Takayuki Nakao」とのことです。
執筆者が、レスを書いたのが、2020/12/11なので、レスをした時点では、
Ports側で、すでに修正が入っていた事になります。
執筆者は、yc.elを野良で使っていたので、Portsの修正に
気づきませんでした。
まるで（Portsでの）成果がないかのようなレスを書いた事を、
Portsでの修正にかかわった皆様にお詫びします。 YC's Room
http://www.ceres.dti.ne.jp/~knak/yc.html
yc.elの公式は開店休業状態なので、何かあれば、自分で何とか
するしかない、と思っていましたが、Ports側だけで修正が入る事が
あるのですね。
yc.elの公式に反映させないとLinuxユーザが困るな、と思うのですが、
yc.elの公式はどうなっているんでしょうね。
yc.elのFreeBSDのPortsのパッチを公開すれば、
yc.elで「process-kill-without-query」で困ったLinuxユーザも
対応できると思うので、以下にURLなどを書きます。 freebsd-ports/patch-yc.el at main・freebsd/freebsd-ports・GitHub
https://github.com/freebsd/freebsd-ports/blob/main/japanese/yc.el/files/patch-yc.el
※FreeBSDのPortsのPatchでは日本語コメントが読めるのですが、
githubでは、日本語コメント部分が化けています。
対照引用しようと思ったのですが、5chに書き込む際も、書き込み欄に
コピペした時点で、github側の引用が妙な化けかたをしており、
対照にならないので、日本語コメント部分のみを、FreeBSDのPortsの、
/usr/ports/japanese/yc.el/files/patch-yc.el から引用します。
以下、引用行を執筆者が明示し、次行の引用部分は、引用符をつけません。
03行
@@ -393,7 +393,9 @@ OBJ を返却する。"
14行
@@ -1736,6 +1738,7 @@ OBJ を返却する。"
22〜25行
@@ -2071,7 +2074,7 @@ OBJ を返却する。"
;; 文節を指定しない場合、現在の文節が対象となる
;; 読みを取得した文節はその読みをキャッシュする
;; cut が 非nil の場合、指定文節以降の読みを削除する
引用ここまで。
今回のyc.elネタは以上となります。
wimeの周知のためageさせてください。
じゃ、夜ゴハン食べてきます。 Python2の呪いにてportsから無くなってからしばらく経つccsm、アップストリームのソースから入れてみた
ちゃんと機能するもののアイコンに不満あり
https://i.imgur.com/VlXs9kc.jpg 何故かLinux板に書き込めないので質問
pcA USBメモリーからdebian11XFCELive起動
pcB ディスプレイ死亡で画面付かず(windows10起動可)
この状態でdebian11からshredコマンドでpcBのハードディスクを上書きしたいのだが、
どうやってpcAからpcBに繋げればいい?
LANケーブルだけでいける?
無線で繋ぐのは無理ね。 最近hyper-v環境にNetBSDを入れて遊んでいます。作法が良く分からずxdm→ctwmで日本語表示、入力を等を設定するために共有のXsessionで日本語入力デーモン起動とメニューのxtermに-ls付けて強引に.profileを読ませています。
.profileではif文でdisplayを見ています。
.xsessionがうまく動かないからですが普通はどうやるものなのでしょうか？ >>51
「22〜25行」は、「22〜25行」の
5chへの書き込み時の文字化けです。
別件。
「たしか、FreeBSDでは『正式表記』」があったはずだよなあ、と、
思っていましたが、正式表記を思い出せず、テケトーな表記を
していましたが、いろいろとドキュメントを見ているうちに
思い出しました。
短縮表記の場合、「FreeBSD13.0R/amd64」という表記が
正しかったのです。
ずーっと、テケトーな表記をしていた事をお詫びします。
>>57
NetBSDのスレか、FreeBSDの質問スレ（OS抜きで共通の話題だから）で
聞いた方が早いと思う。
「余所でやってください。[unix]」、
「もう新しいのにしましょ。」が出るので
書き込みテストがてらの書き込み。
User-AgentをWindows10(Chrome98)で書き込み。 やっぱり化けるな。
>>58は、「22全角波線25行」と書きました。 >>57
> 普通はどうやるもの
俺はこういうのをわざわざ書いた事がないな
↓
> .profileではif文でdisplayを見ています。
NetBSDスレで Xorg.*.log を交えて話題展開してみては？ 57ですが、とうとうhyperｰvのFreeBSD環境でYouTubeの音声をpaprefs使ってネット接続で聴ける様になりました。これで画面サイズの変更が出来れば良いのに。 いえhyperｰv環境で拡張セッションを使わずにubuntu、fedora、freebsd、netbsdで何処迄同じdesktop環境を作れるか？で遊んでいるので自分の中では変わっていません。
Windows側からsshで操作できる。
sambaサーバになる。
libreofficeで日本語ドキュメントを作り、sambaで公開して、Windows側から操作も出来る。
firefoxでYoutube配信の音楽をWindows側のスピーカーで聴きく。の内ubuntuとfreebsdはクリアしたので次はnetbsdです。fedoraはlib64とか言う変な所にpulseaudioが入れられるのでpipeWireからネットワークスピーカが動くか別途調べます。 Wine上で、ちょこっと日本語入力ができれば、ありがたい時が
あるよね、と思って設定をしてみたが、日本語入力ができない。
FreeBSDでも、Wine0.9系の頃から、できているようだが。
環境：FreeBSD13.0R/amd64
：i386-wine-devel-6.12,1
：ja-kinput2-3.1_13 ※「kinput2 -canna &」
：Wine上のxyzzy0.2.2.250
「~/.wine/user.reg」の「[Volatile Environment] 」の
上の行あたりに、「root」設定の場合は、以下を書き足す。
※「[Volatile Environment] 」の下に書き足すと、
Wineの次回起動時に、消されてしまうので注意。
[Software\\Wine\\X11 Driver]
"InputStyle"="root"
試行結果は次レスで。 >>64 の続き。
・「root」の場合
Shift+Spaceでkinput2を起動すると、［あ］が出現しないものの、
kinput2の変換窓が開き、変換ができるが、漢字を確定しても、
Wine上のxyzzyには空白行のみが入る。
・「onthespot」の場合
Shift+Spaceでkinput2を起動しても、［あ］が出現しない。
Wine上のxyzzyは、kinput2を終了するまで入力に反応しない。
・「offthespot」の場合
Shift+Spaceでkinput2を起動しても、［あ］が出現しない。
Wine上のxyzzyには、半角空白が入力される。
・「overthespot」の場合
Shift+Spaceでkinput2を起動すると、［あ］は出現するが、
Wine上のxyzzyは、kinput2を終了するまで入力に反応しない。
「できませんでした」という報告ですが、
解決方法をご存知の方は助言をお願いします、
というレスでした。
じゃ、お三時のオヤツ食べてきます。 >>63
ですが、fedoraでもpulseaudioを入れてpaprefsを使えばネットワークスピーカーが動きました。
これでubuntu21.10、fedora 35、FreeBSD9.2全てブラウザで「無修正」と入力してavを探し視聴出来る事が出来ました。officeツールも動くので十分使えると思います。
NetBSDはbmpまでは音が出るのですがfirefoxは音が出ません。officeツールが動くだけに残念です。
hyperｰvでなければもっと簡単かもしれません。 FreeBSD13.1Rのリリースを待ってから試そう、と、思っていましたが、
リビジョンアップでも、何かと変わるだろうし、低スキルの執筆者は、
リビジョンアップの対応で、ウオーサオーしそうなので、
あらかじめ試しておこう、と、Wine関係を試行しました。
現在、FreeBSDでは、i386-wineがwineに吸収（>>38）され、
通常の、wine、wine-develでは、WOW64対応なWineとなっています。
まず、執筆者としては、wimeの稼働も目的としていますので、
Wineにwimeのパッチをあてた32bitなimm32.dll.soを
作らないといけません。
生活環境のFreeBSD13.0R/amd64のVirtualBox6.1（注１・注２）に、
FreeBSD13.0R/i386をインストールし、その中で、portsから、
wine-devel（注３）をmakeしました。
wimeの「imm-magic-1.7.3」を「emulators/wine-devel/files」の下に
置いてmakeします。普通にmakeが通りますが、
「emulators/wine-devel/work/wine-7.2/dlls/imm32」の下には、
「imm32.dll.so」でなく、「imm32.dll」しかありません（注４）。
執筆者は、低スキルですので、「そう変わったのかな」と
「imm32.dll」を、ホスト側のFreeBSD13.0R/amd64へ
ファイルコピー（注５）しました。 >>67
（注１）「chroot」や「jail」が、よくワカラナイため。
勉強しろ、なんですけどね。
（注２）makeするだけだし、コンソールだけでいいや、
だから、ディスクは8GBでじゅうぶん、と思いましたが、
Wine7.2が依存する、なぜだか古い「llvm12」のmakeが
からんだこともあり、ディスクがあふれました。
10GB以上は必要かと思います。
（注３）現行のWineはWine7.4で、この試行ではWine7.2となりました。
現在、FreshPortsを見ると、昨日の03/23にWine7.4へと
バージョンが上がっていました。タイミングが悪いです。
（注４）imm.cを見るとパッチの指定どおりにソースが変更されていました。
（注５）ホスト、ゲスト間で、FTPで転送しました。 続き。
ホスト側というか、生活環境のFreeBSD13.0R/amd64では、
pkg(8)で、wine-develをインストールする事とします。
# pkg remove i386-wine-devel ※Wine6.12
# pkg install wine-devel ※Wine7.0.r2 WOW対応版
% wineboot
/home/HOGE/.i386-wine-pkg//usr/local/bin/wine doesn't exist!
Try installing 32-bit Wine with
/usr/local/share/wine/pkg32.sh install wine-devel mesa-dri
% /usr/local/share/wine/pkg32.sh install wine-devel mesa-dri
※repository catalogueを取得して、ユーザのホームディレクトリの
「.i386-wine-pkg」以下に、i386対応な、Wineのパッケージが
インストールされます。サイズは2.5GBです。 続き。
・Wine6.x系で必要だった「setenv WINEDLLPATH /usr/local/lib32/wine」は
必要なくなっていました。
※当時、スレで助言していただいた方、本当にありがとうございました。
・WOW対応版のWineで「.wine」を新規生成すると「Program Files (x86)」が
できていますが、新規生成をしなくても、32bitなWineで作った、
古い.wineのままで、「wine hoge.exe」とすれば、WineでEXEが起動します。
つまり、32bitなWindowsソフトウェアを再インストールする手間はいらず、
EXE起動時に、Wineは、32bitなEXEを判別してくれます。
ただし、32bitな環境で作った古い.wineのままだと、
「Program Files (x86)」がないまま、となりますので、
64bitなWindowsソフトウェアと混用する場合は、不便かもしれません。
・使用感としては、昔のLinux板のWineスレでは、
「（Linuxでは）WOW64だと、32bitソフトウェアの起動が遅い」
などと言われていましたが、普通に速く、違和感はないです。 続き。
さて、かんじんのwimeです。
FreeBSD13.0R/i386で作った32bitな「imm32.dll」をどこに置くか？
あちこちに「imm32.dll」や「imm32.dll.so」がありますが、
/usr/ports/emulators/wine-devel/work/wine-7.2/dlls/imm32/imm32.dll
のように、できあがった「imm32.dll」を、
/home/HOGE/.i386-wine-pkg/usr/local/lib/wine/i386-windows/imm32.dll
として、オリジナルのimm32.dllを、wimeのパッチがあたった
「imm32.dll」と置き換えると、32bit環境でgmakeしたwimeにより、
32bitなATOKが稼働してくれました。
※ >>14 は、このレスの内容で修正して読んでください。
pkg(8)で入れたwine-develは、7.0.r2であり、7.2でmakeしたimm32.dllへと
差し替えたことになりますが、「IMEまわりは、さほど変更がない」と、
昔のLinux板のWineスレで読みましたので、気にしません。
あいかわらず「余所でやってください」が出るので
UserAgentをWindows10(Chrome98)で書き込みました。うえーん。
じゃ、夜ゴハン食べてきます。 荒らしがウロウロしてなければサラッと教えられるんだがなあ UA え゛！そうなの！
運用情報板でも確定した回避方法が出てないんだけど、
なんらかの方法があるのね。
他の荒らしが多そうな板で書けて（テストで書いてみた）、
すっかり静かなUNIX板で書けないのはおかしいよね。
UNIX板でも無意味にスレを保守しているのが目ざわりなので
個別に規制して欲しいくらいだわ。 代わりと言ってはなんだがGoogleタイムラインに流れてきた記事を
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1397428.html
Windowsのメイリオっぽささえ許せれば抜群に綺麗で読みやすい
UIフォントとしてもなかなか優秀 ニュー速(嫌儲)の
「Windowsのクソフォントｗｗｗ」のスレで知ったｗ
ports化されればいいなあ、と思った。
と言っても、執筆者君は、
「font-jis-misc」と「ja-font-mona-ipa」ぐらいしか
使ってないけどさ。
フォントが少なかった時代から思うと、フォントの選択肢が
多いと得した気持ちになるよね。
「不正なPROXYを検出しました。」が出たので
嫌儲のURLを書かないでレスしてみた。
じゃ、夜のデザート食べてきます。 >>73
> 無意味にスレを保守している
放置しておいても落ちやしない板で行うそれの推測
・「書き込みで広告代稼がせてんだから他の荒らし行為は大目に見ろや」と言うつもり
・縄張りアピールのつもり
・落書きによるただの発散 ○FreeBSDのWineがWOW64になった状況のまとめ
・FreeBSDのWineがWOW64対応になったのはよいけれど、
64bit版と32bit版が重複して入った形になっている。
・amd64においては、ユーザのディスクを重複で消費して
ムダなような気もするが、Ports的には、64bit版と32bit版の
２種類をメンテするよりは、人的リソースの面で効率がよい。
・なにより、i386-wineのAlexander88207氏が、関わっている
という状況は、Alexander88207氏の、今までの貢献からも、
確実に動くものがコミットされている、という安心感につながる。
・最近のことなのに、すでに憶えていないが、今までは、
wineと、i386-wineは、排他利用だったような気がする。
Windowsソフトウェアの64bit版と32bit版の混用ができるのは、
より、Windowsに近い。
まあ、SETUP.EXEは、32bitで、本体は、64bitをインストールする
というソフトウェアもあるようだし。
・しかし、Wineの32bit版は、wineboot時に、シェルスクリプトを
走らせないといけないという状況から、32bit版Wineは、
pkg(8)から入れないといけない、というキメウチのようで、
今回のように、imm32.dllにパッチを当てたい場合は、
i386でmakeしないといけない。
32bit版Wineも、amd64のPortsで自前でmakeしたものが入れられる
なら、FreeBSD/amd64だけを用意すればよいのだが……。 ○Windows版ATOKまわりのまとめ
・「ATOK Passport」は、月額／年額の契約で、ネット経由でライセンスを
問い合わせるようになっている。
そして、一太郎2022同梱版ATOKも、年契約となり、
いわゆる「買い切り版」のATOKは、一太郎2021同梱版が最後となった。
一太郎スレでも、駆け込み購入で大騒ぎになったのは、当然かもしれない。
・おそらく、wimeで、年契約版のATOKが動くとは思うが、報告がないので
なんとも言えない。
>>15 の2014年版のようにヒョッコリと動かないかもしれない。
試用版（体験版）で試すという方法もあるが、過去のWineスレや
wime公式や、各種ブログで、報告があったように、試用版と製品版では
挙動が違うという場合があったので、製品で試さない限り、
確実なことは言えない。
・wimeのconf.mkには「CC32_ENV?=schroot -c dev32 --」の記述が
あるので、自分でなんとかするならば、FreeBSD/amd64のchrootでも、
32bitなwimeがgmakeできるかもしれない。
・現状、64bit版ATOKは、FreeBSDの64bit版Wineにインストールできない、
と、wimeの公式で報告されている。
また、一太郎は今でも、32bitなソフトウェアとして提供されている。
じゃ、夜ゴハン食べてきます。 このスレをふくめ、複数スレの『依頼』、ありがとうございました。
廃墟のスレで、栞となっているぶんには、板の「華」と言えない事も
ないですが、目ざわりには違いないので。
微妙にURLを変えてあるので「手が込んでいるなあ」と
思ってました《くだけた表現》。
まあ、レスごとにファイルをアップしていただけ、かもしれませんが、
その労力と執念が、怖がられる結果になる、と、感じないところが、
なんとも言えませんね。
情報的な面で古びてしまったスレは、ある程度で落ちればいいのにね。
そのわりに、WXGのスレは、情報的には古びてしまい、現状を報告する
散発的なレスが続いているが、次が必要ってほどでもないし、という
感じで、いい感じだったんですが《くだけた表現》、
突然の大量書き込みで過去ログ行きになりましたし。
「そういう」人間関係や社会に生きている、と感じさせられます。 >>81
ところでwimeさん、今宵は本スレが随分賑やかな様ですが
あれ何人でやり取りしてる様に見えますか？
日頃閑散としてる板なのに急に多数の人が集結するとは思いづらいんですけど まあ3人くらいで回しているんだろうねえw
歴史を知らない人大杉 >>82
ああ。なるほど。
>>83
「語れ」スレの事かな。１人 VS ３から４人かなあ。
うーん、UNIX板は、ほとんど人がいないように見えるけど、
NetHackスレ、Emacsスレ、あたりは常時活発だしなあ。
※現在のUNIX板では、１日２レスで活発という感じ。
※大昔、「質問」スレだかで、見たんだけど《くだけた表現》、
「2chの書き込みは水曜日から多くなる」そうだ。
考察内容（週の中だるみか？、とか）は、忘れたけど、
それは今でも、他の板でも、感じるなあ。
ただ、昔のUNIX板では、「BSD入門の心得」な、人も
多かったから、利用者の継続（年齢の持ち上がり）を
考えても、突然のレスバトルは不思議ではない、と思う。
「ああー」って感じ。
ただ、熱意というか、執着というか、が、激減したｗ
３スレほど、24時間ピッタリ張りついて、レスバトルで
体力を消耗して、半年ほど寝込むぐらいの勢いで
やらないとだめじゃん、と思うｗ そもそも、UNIX板の人って、
知識不足で、いい加減な回答をするぐらいならスルー、
それなりに興味がないとスルー、
まれに「BSD入門の心得」な感じで、熱くなる時もある、
って感じです。
たまに見かける「光る」レス、回答の「man hoge」レス、でも、
冷静感があふれているので、成熟した人
（ちゃんとした社会人と言うか）の利用が多く、
UNIX板には、それなりに人は居るが、レスのやり取りという形で
見えていないだけ、なのではないか、と思う。
それゆえに、執筆者君は、「かなりの人数の無言の閲覧者がいる」
という前提で、しかも、「そういう」人から理不尽なツッコミが
入らないように、気をつけてレスを書いています。 盛り上げるための工作員（職業レス屋）って事は、ないと思う。
「語れ」スレでは、双方、ちゃんとUnixの知識があるし。
工作員は、「そもそも、語るべきものを持たない」から、
その職業ができるのかもしれない。
だから、「許可を受けた」レスしかできなかったり、
仕事だから、感情抜きで、レスを「貼り付ける」わけで。
よって、工作員は、専門板には来ないと思う。
マルチポストは来るけどね。
自作板では、受診を勧めたい荒らし、も、いる感じだし。
Linux板では、私怨の荒らし、っていうのもあるみたいだし。
Linux板の急激な廃墟化というか、レベルの低下には、
気づいてましたが《くだけた表現》、「おかしさ」までは
気づかず、「タコ（Linux用語）が増えたのかな」って
程度でした。
外部のまとめサイトを見ると、「そういう人」がいて、
Linux板は廃墟状態になったみたいです。
本当に１人で、Linux板を廃墟化させたとしたら、ある意味、
すごいですけど、まとめサイト側が、「そういう人」かも
しれませんから、部外者は判断できかねますが。 最近、こういうレスも書きました。
※UNIX板ではハンドルを固定する事にしています。
なぜかって？ wimeをもりあげるためです、キリッ。
まあ、他の板は、閲覧はしても、そもそも書きませんが。
書く労力がもったいないからですｗ
いいかげんPC-98は捨てろ＠UNIX
https://mevius.5ch.net/test/read.cgi/unix/1036951410/642-n
あ、それと、このスレの主催者ではないです。
主催者なんて、とんでもない、おこがましいです。
スレを立てて、頻繁に利用しているだけですｗ
他の方々、いらはい、いらはい（寄席の呼び込み感）。
あー、wimeのおかげで、WineでWindows版のATOKを使って
長文レスが快適だったなあー（棒）。
あー、wimeのおかげだわー（棒）。
執筆者君より高スキルのユーザが降臨して、助言して
くれないかなあ（真剣）。 > ３スレほど、24時間ピッタリ張りついて、レスバ
特徴的な方が何人か浮かびますね
ほじくって貼ったりすると荒れそうなんでやりませんが >>88
> Linux板の急激な廃墟化
ここ1~2年の事なら自作自演が減って化けの皮が剥がれただけでしょ □ホームディレクトリ以下に置かれるWine関連のファイル
Wineの動作や、WineでのWindowsソフトウェアのインストールにより、
Wine関連のファイルがホームディレクトリ以下のあちこちに
散らばります。
もちろん、置きっぱなしでも、動作に問題はありません（注）が、
.wineを新規生成する時に、確認して消すと、気持ちよいでしょう。
一括削除するコマンド例の記事などがありますが、Wineによる命名規則が、
変わる場合がありえます（実際に微妙に命名が変わっていた）ので、
GUIなファイラーなどで、目で見て消すとよいでしょう。
執筆者による発見もありますが、おもに以下の参考文献に依っています。
参考文献
http://variedtastefinder.jp/blog/?p=1561 ※現在404。2017年に閲覧
https://wiki.archlinux.jp/index.php/Wine
（注）Wineのバージョンアップのたびにインストールした
フリーソフトのアイコンがインストールした回数だけ
たまっていたことがある。
レスの行制限があるので、ファイル群の詳細は次レスで。 続き。
$HOME/.wine ※本体
$HOME/Desktop/の下
※WineでDesktopをDesktopにしている場合
$HOME/.config/menus/applications-merged/wine*
$HOME/.local/share/applications/ の下
※Wine以外も使っています
$HOME/.local/share/applications/wine/ の下
$HOME/.local/share/applications/mimeinfo.cache
※キャッシュなので消せます
$HOME/.local/share/desktop-directories/ の下
$HOME/.local/share/icons/hicolor/ の下
※Wineしか使っていないような
$HOME/.local/share/mime/packages/x-wine-extension*
$HOME/.local/share/mime/application/x-wine-extension*
$HOME/.cache/wine/wine-mono-*.msi
※Wineバージョンごとのmonoインストーラ wine-devel(WOW64なWine7.0)で、.wineの新規生成と
Windowsソフトウェアの再インストールをしました。
Wine6系からは日本語命名のファイルはUTF8扱い（注）のようですので、
「setenv LANG ja_JP.eucJP」な、運用の方は、インストール時のみ、
「ja_JP.UTF-8」にされるとよいでしょう。
一太郎は、「C:\JUST」に配置される、テンプレートデータ
（入れない選択はできない）のファイル名が、半角カタカナや
全角日本語だったりして、インストーラ内でのコピー中に、
読み取れない、などのエラーが出ますが、「次へ」の連打で
乗り切ることができます。
これらのファイルは、インストール後、正常にUTF8なファイル名に
なっており、コピーできずに欠落したファイルはありませんでした。
また、他のソフトウェアでも、書式ファイルや、設定ファイルなどは、
日本語ファイル名だったりしますし、インストーラでインストールした
ディレクトリに「説明書.TXT」のようなファイルがあったりもしますね。
（注）Wine5系の時は、EUC-JPな日本語ファイル名が扱えました。 FreeBSD13.0Rのwine-devel(WOW64なWine7.0)でのwimeの動作
※これは、あくまで執筆者の環境でのみ、の話です。
環境
・FreeBSD13.0R/amd64
・wine-devel-7.0.r2 ※WOW64対応
・wime4.1.4 ※32bitバイナリ
・ATOK17（2004年） ※もちろん32bit
・emacs-27.2
・ja-yc.el-5.2.1_19,1 ※FreeBSDのPortsでパッチがあたったものを野良化
（１）wimeのwimectrlが以下のエラーを出して動かない。
ld-elf32.so.1: Shared object "libX11.so.6" not found, required by "wimectrl"
ATOKのプロパティが開けないので、ほんの少し不便です。
「libX11.so.6」っぽいものが、どのディレクトリに置かれているのか、
だけでも、どなたか、分かりませんでしょうか。
（２）wimeでの初回変換時、yc.elにより、入力された文節の区切りを
変更しようと、Cintrol+fすると、 Wineがエラーを出して停止、
Emacsの上の、Xクルーザは腕時計となり、killするしかなくなる。
Wineのエラーは、backtrace.txtを取ることができる。
※backtrace.txtを見てもどこが悪いのか分かりませんが。
一度でも変換確定してしまえば、２度目の変換で、文節の区切りを
変更しても大丈夫、という不思議状態です。
じゃ、夜ゴハン食べてきます。 >>95
wimeでの初回変換時、の件に関して追記。
wimeでの初回変換時、
Cannaのフェンス（1byteのパイプ文字に囲まれた状態）内の
１度目の変換候補をさわろうとして、
・文節区切りの変更で、Control+f
・変換自体を取りやめようとして、Control+g
・変換一覧を出そうとして、２度スペース（注）を打鍵
であっても、Wineがエラーを出して停止、それにともない、
wimeも「Canna」に接続できなくなる、ということが判明。
（注）執筆者は「.canna」で「(setq n-henkan-for-ichiran 1)」と
スペースでの変換打鍵の２度目で変換一覧を出すようにしている。
今のところ、とりあえずの回避策としては、
「１度目の変換では、フェンスに囲まれた状態で確定しておく」
としている。
次のバージョンのFreeBSD、次のバージョンのWineまで我慢します。
あいかわらず、Windows10のChrome98.0のUser-Agentで書き込み。 参考
【西川和久の不定期コラム】Chrome OS Flexと最新版Wine 7.0の組み合わせでWindowsアプリを動かしてみる - PC Watch
https://pc.watch.impress.co.jp/docs/column/nishikawa/1401328.html 今現在の、FreeBSDのpkg(8)のバイナリパッケージ(quarterly)の
Wineのバージョンは、Wine7.4(wine-devel)、Wine6.0.3(wine)、
となっています。
FreeBSD13.0R/amd64での、Wine7.4では、.wineの生成のために、
「wineboot」して、
「/usr/local/share/wine/pkg32.sh install wine-devel mesa-dri」
として、32bit環境（~/.i386-wine-pkg以下に入る）を入れても、
32bit環境は、wine6.0.3を展開されます。
当然ながら、
「wine [wine-6.0.3] and wine64 [wine-7.4] versions do not match!」
と言われます。
指示通りに「/usr/local/share/wine/pkg32.sh upgrade」をして、
リポジトリが、Upgradeされても、なぜだか、やはり、wine-6.0.3が
展開される状況ですので、32bit環境が必要な方は、Wine7.4を
避けた方がよいでしょう。 Wine6.0.3(WOW64)では、普通に32bit環境が生成でき、
執筆者として懸案だった、wime+emacs+yc.el環境下での、
「変換フェンス内で何かをするとemacsが腕時計になる」状態（注）は
回避できましたが、
やはり、wimeのwimectrlで「"libX11.so.6" not found」となる状況は
変わりませんでした。
（注）>>95 >>96
「１度目はフェンスで確定をする」という運用をしていても、
時間がたっても同様のエラーが出たため、他のバージョンを
試す気になった。
>>70
あまり関係ありませんが、Wine6.x系で、
「setenv WINEDLLPATH /usr/local/lib32/wine」と、
環境変数を設定しないといけなかった過去があるのは、
「i386-wine」であるから、ということが、これらの試行で
よく理解できました。
今のWOW64なWineの仕組みだと、FreeBSD/amd64インストール時に
「lib32」を入れておかなくてもよいということです。 「ちょこっと印刷できると便利だもんね！」ということで、
田中みな実さんの美容なみに、執筆者君は、Wineでの印刷も
期待しています。
Wine7.0r2(WOW64)では、Wineで稼働するソフトウェア内から
プリンタ（注１）が見えない状態（注２）でしたが、
Wine6.0.3(WOW64)では、プリンタは見えました（注３）。
（注１）CUPSでなく、昔ながらのBSDlpr(/usr/bin/lp)。
（注２）エラーメッセージは忘れましたが
「プリンタがセットアップされていない」というような内容。
（注３）実際の印刷はしていない。
やはり、執筆者君としては、ATOKのプロパティが出せない、
というのは、多少なりとも不便なので、i386-wine-devel(6.12)に
戻りました。
じゃ、田中みな実さんオススメのボディクリームを塗ってきます。 釣れますか？ ,
＼ ,／ヽ
￣∨￣￣￣￣￣￣￣ ,／ ヽ
∧＿∧ ∧∧ ,／ ヽ
（ ´∀｀） (ﾟДﾟ,,),／ ヽ
（ ） (| つ@ ヽ
｜ ｜ | ＿＿_ 〜| | ヽ
（_＿）＿） |――|. ∪∪ ヽ
￣￣￣￣￣￣￣￣￣￣￣￣| ヽ
／⌒＼／⌒＼／⌒＼／⌒＼|彡~ﾟ ゜~ ~。゜ ~ ~ ~ ~~ ~ ~~ ~ ~~ ~~ ~~
⌒＼／⌒＼／⌒＼／⌒＼／⌒＼彡 〜 〜〜 〜〜 〜〜 〜 〜 >>100
肝心なことを書き忘れていました。
FreeBSDのX上のGUIなソフトウェアから、プリンタで正常に日本語が
印刷できる状態であれば、Wineで稼働するWindowsソフトウェアから
日本語の横書印刷は、できます。
Wine1.7.11＋OpenOfficePortable3.2.0 で、縦書表示、縦書印刷を
していましたが、一瞬の輝きだったようで、今では、横書印刷しか
できません。
めったに縦書印刷をしないから……、
別にいいですけど！（田中みな実さんぽくむくれた表情）。
Wineで縦書がなかった時代から、縦書表示、縦書印刷ができていた
CassavaEditorなら、今でも縦書印刷ができるかもしれません。
FreeBSD での Office 環境を語れ! その2＠UNIX
https://mevius.5ch.net/test/read.cgi/unix/1107211157/863
https://mevius.5ch.net/test/read.cgi/unix/1107211157/858-n
【指令】お前らの年賀状作成ソフトを報告せよ！＠UNIX
https://mevius.5ch.net/test/read.cgi/unix/1008926166/228-n
※↑スレのレス245の https://github.com/Torisugari/printha
には、期待していたのですが、使ったよ、って記事がないですね。
※レス228は、執筆者君です。以下のサイトを参照していました。
Linux＋Wine＋CassavaEditorではがきに宛名印刷する印刷設定の一例 - ぜんざいの耐えがたき甘さ
https://sound.jp/zenzai/other/wine-cassava-setting.html GNOME42悪くない
少なくとも近年のFreeBSDのGNOMEらしからぬ仕上がり
どうせ誰も使わんのだろうが >>103
追っかけている方はおられるんじゃないですか。
「かけまわる子犬。」氏はKDEを追っかけているし。 FreeBSDのKDEはdiscoverでpkgが扱える様になれば言う事無し 割り込んですいません。自己レスですが。
>>67-71
imm32.dll.soとimm32.dllの件
>>99
＞今のWOW64なWineの仕組みだと、FreeBSD/amd64インストール時に
＞「lib32」を入れておかなくてもよいということです。
以上のレスは、以下のLinux板のWineスレで、理解が深まります。
i386-wineの統合のタイミングは、まさに今だった、
ということかもしれません。
今夜も Wine で乾杯! - 23本目＠Linux
https://mao.5ch.net/test/read.cgi/linux/1585198566/671-n FreeBSDを語れスレのテンプレで興味を持って来ました
このスレは主にFreeBSDでwimeを使っている君と言う方が盛り上げている感じなんですね
FreeBSDではどのデスクトップ環境がおすすめですか？推している方がいるようにKDEですか？ ん？ 語れスレのテンプレ？（ケンモメンぽく）
えっ！やだっ！（田中みな実さんっぽく）
けっこう活発なラズパイスレと一緒に関連スレになってる！
盛り上げると言うか、
「高スキルユーザさーん！ 興味を持ってくださーい！」とか
「FreeBSDのWineで何かあれば、さがわ@sagawa_aki氏にも届け！」という
感じで報告しているだけで。
Linux板にはWineスレがあるんだけれど、FreeBSD特有のWineの話は、
Linuxには関係ないし、「FreeBSD限定のWineスレ」ってほどの
話題もないしね。 「おすすめのデスクトップ環境」って、Linux板文化っぽいね。
Linuxでも有名で、FreeBSDでも、FreshPortsでコミット回数が
多くて、よく使われている感じの、しかも、FreeBSD特有の問題が
あれば、回避策が見つかりやすいやつ、で、いいんじゃないかな。
PCでのUnixは、Linuxが当然の前提、って感じなので、
FreeBSDだと……、という事が起こりやすいしね。 例のところを見ると、
「みなさん、普通にリッチなデスクトップ環境を使っているのね」
と思います。
触れないほうがいいかもしれないけれど（注）、リンクを書いておこう。
FreeBSD研究部
https://ja-jp.facebook.com/groups/freebsd.labo.japan/
（注）
いいかげんPC-98は捨てろ＠UNIX
https://mevius.5ch.net/test/read.cgi/unix/1036951410/642-n >>109
> FreeBSD特有のWine
5chブラウザの動作報告などして下さると面白いかも知れないですね 5chなので
Windowsの専ブラの動作報告などダサイでしょうから気が向いたらと言う事で 「wimeまとめ」の >>13 の「canna.el」への補足です。
執筆者は、「yc.el」を、現在まで使い続けてきました。
そのため、 >>13 での「canna.el」への言及が、中途半端で甘かった
のですが、最近、「Yuuji」氏（注）による、EmacsへのCannaパッチを
知りました。
これが、FreeBSDの、pkg(8)の、flavor（Portsならmake option）の
「emacs-canna」の「もと」なのですね。
emacs23から数えて、13年ほど、まったく気づいていなかった、という
自身の検索の甘さをお詫びします。まことに申し訳ありませんでした。
（注）Twitterを見ると「ものずんごい有名人ではなかろうか」と
思いますが、まったく存じ上げませんでした。
FreeBSD13.0R/amd64で、
Wine(i386-wine-devel-6.12)＋wime4.1.4＋ATOK17(2004)＋emacs-canna-27.2
を、使ってみましたが、
「やだっ！ Mule時代みたい！ 勘違いしないでね、ほめてるのよ！」
「yc.elでは、変換候補が一斉に出て、Emacsのエコーエリアが
数行ほどになるのに違和感があったのよね！」
と、誰だか分からない物まねをしながらウハウハです。
yc.elより、emacs-cannaのほうが軽いような気もします。
FreeBSDを使っていて良かったなあ、と、思いました。
https://twitter.com/hiroseyuuji/status/1511329334107140101
https://twitter.com/5chan_nel (5ch newer account) >>112
13-stableでpkgのwine6を使ってjanestyle4は動いた。この書き込みはそこから。 >>116
確かに動いた あっさりと
https://i.imgur.com/uWiXdbE.jpg
それも i386-wine-devel で使ってたやつがそのまんま
wime氏、116氏、ありがとう そのうち私も何らかの成果があればご報告差し上げます >>117
自分のレス番間違えてしまった
とにかく感謝してます wineは使わないけどV2Cだって13-stableで動くよ。
自分はV2C-Rを使ってて最近V2C/2に移行した。 そうそれ。
JAILで古いportsをビルドしてパッケージだけメイン環境に突っ込んだ。
スクリプトエンジンが変わってて動かんから古いエンジンを突っ込む必要があったり
ちょっと手間だったけどV2C/2が快適に動いててこの書き込みしてる。 >>74
これをベースにした合成フォントがportsに来たみたいですよ
FreshPorts -- japanese/font-udev-gothic: UDEV Gothic
https://www.freshports.org/japanese/font-udev-gothic/ >>122
おおっ！ Portsに来たぁぁ！
２つあるのか。明朝はないのね。
ん？ 「Nerd Fonts」。「オタク文字」？ って何だ？
FreshPorts -- japanese/font-udev-gothic: UDEV Gothic
https://www.freshports.org/japanese/font-udev-gothic/
FreshPorts -- japanese/font-udev-gothic-nf: UDEV Gothic (Nerd Fonts)
https://www.freshports.org/japanese/font-udev-gothic-nf/ >>123
上流リポジトリ
https://github.com/yuru7/udev-gothic
HackGenの作者さんの様でテキストエディタや端末エミュレータ用の等幅フォントですね
ナードフォントというやつは絵文字グリフが充実したフォントらしいです >>124
わざわざレスすいません。
モリサワの「BIZ UD」フォントからのPorts化なのでなく、
「yuru7」氏の二次的成果物（BIZ UD+JetBrains Mono）からの
Ports化なんですね。 >>125
と、言われても……、なあ。
連日の長レスの後の短レスの投稿数の多さが恐いと思います。
Windowsは、「データを持って行って」ぐらいでしか
使ったことがないので、理解できませんでした。
今でこそ、Windowsが対応しておかないといけないキーボードは、
日本語か、英語か、ぐらいの選択ですが、昔は、Windowsが対応して
おくべきキーボードがたくさんありました。
101/104英語、106/109日本語、PC9801系、AX、J3100（ATコネクタ）、
FM-TOWNS、親指シフト（最近まで現役だったみたい）、かなあ。
Controlキーが、左にしかない場合もあるし、Windowsさんには歴史が
あるんだから、ぐちゃぐちゃとは言えないよね。
大昔（MS-DOS時代の話かもしれない）に読んだ、ATOKのバグ出し
チーム（だったかな？）の記事。
バグ出しチームは、標準のキー割り当てで変換し（当たり前ですが）、
しかも、変換結果の漢字が何番目に出るかも記憶しているため、
即、変換結果を選ぶことができ、漢字変換が正確で速いのは良いが、
学習機能を使わない状態（無意識に学習機能を使わないようにしていた）
だったため、学習機能の向上の役に立たない、ということに気づいた、
という話。 >>113 の件について追加。
FreeBSD13.0R/amd64＋Wine(i386-wine-devel-6.12)＋
wime4.1.4＋ATOK17(2004)＋emacs-canna-27.2 の
環境下において。
emacs-canna標準の、canna.el使用時の、漢字変換時に、
ごくまれに、WindowsなATOKの変換候補のGUI表示がされる。
もちろん、そのGUI表示で変換候補を選ぶことはできず、
単に描画されるだけです。
この描画は勝手に消えてくれないので、ATOKのプロパティを
表示（wimectrl -s）させて、プロパティをキャンセルすると、
ATOKのプロパティの描画と一緒に消えてくれます。
ただ、「たまになる」だけで確実に再現させることができません。
「標準のEmacs＋yc.el」の時も、ごくごくまれになっていたと
記憶するのですが、条件を思い出せません。
実害はないのですが、一応、そういう現象がある、という事で。
それと、繰り返しになりますが、「標準のEmacs＋yc.el」より
「emacs-canna」の方が、軽いように感じます。
「Emacs LispでCanna」と、バイナリで対応の「emacs-canna」なら、
当然かもしれません。
もう「標準のEmacs＋yc.el」には戻れません。 >>127
もしご本人が読んだらどんな反応があるか目に浮かぶ様なご回答ですな >>130
恐いのは恐いんですが、悪口ではないんですよ。
ただ、キー割り当てやソフトウェアの挙動には、人間側として
不満があったとしても、よかれと思って考えられた設計思想や、
俗に語られる、タイプライターの配列の話などの、
いまさら変えられない歴史があるし、あえて、人間側が標準状態に
合わせるのも考え方として「ある」という話です。
ATOKのバグ出しチームの話も、「へえ、変換学習をさせなければ
変換先の順番が変わらないのだから、変換作業が速くなるね」と
感心したので、憶えていたのだと思います。
ATOKのスレで、ATOKの新規インストールをしたので、
「これから（自分流の入力をして）辞書を鍛える」というレスが
並んでいた中に、「短文でなく、長文で変換をしたら、文脈に
応じた変換結果になりやすいのに」というレスを見てからは、
執筆者も、文脈を読み取りやすい長さのタイミングで
変換するようになりました。そのレスには感謝しています。 そのスレで言及があった「窓使いの憂鬱」は知っていましたが、
共同使用のPCには入れられないし（共同使用相手がUnix系とは
限らない）、「窓使いの憂鬱」を入れられる環境なら、
Emacsな人なら、xyzzyを入れて「メモ帳」代わりに使っても
よいだろうし、Windowsのダイアログ入力のコピペなどの
すべてまでも、を、Unixっぽくするのも、どうなのか、
Windowsにおいて、「絶対にマウスを使たくないでござる」は、
難しいだろうな、人間には慣れる能力もあるのに、と、
思ったことがあります。
『UNIXという考え方−その設計思想と哲学』を読んで、
マウス操作もアリ（操作は、なるべく楽をしろ）なのだな、と、
考えを改めた執筆者君でしたー（きょうのわんこ風）。 ありきたりな環境で人並みに過ごすのか、楽をする為に人並み外れた途方も無い時間と労力を費やすのか
まさに人それぞれと言う話でござるな まあどっちかというとWindowsならマウス無しのオペレーションも無くはないんだけどね。 > BSD/LinuxでのOffice/Desktop環境を語れ！ Part03 GhostBSDのデザイン割と好きなんですが
OpenRCに馴染めないのでパーツだけ拝借してそれっぽくしてみました
https://i.imgur.com/HmjeR0v.jpg みなさん、フツーにリッチなデスクトップ環境を使っているのね。
計算機資源は、makeやコンパイルに振り向けるべきだよ、
それなら自作PCも安価で済むしね、という貧乏性な執筆者です。
大昔、初めてWindow Managerの仮想デスクトップを使った時は、
「わー、すげー」とか言って、いくつかの窓を仮想デスクトップへ
移動させたが、存在を忘れてシャットダウン。
仮想デスクトップマネージャみたいなものがあっても、
「見えていない物は忘れてしまう」という事に気づいて、
そもそも、仮想デスクトップは使わなくなった。
XのWindow Managerは、ソフトウェアを位置指定（-geometry）して
起動ができるので、「わー、すげー」とか言って、
「Emacsはこの位置で」などと、設定に夢中になったが、
同じソフトウェアを複数起動すると、ピッタリと同じ位置に
起動するので、先に起動していたのを忘れてしまう、という事で、
位置指定もやめた。ダメダメじゃん。
といっても、タイル型のWindow Managerへ行くほどでもないです。 > ※執筆者はC言語もMakefileも理解していない >>140
あははー。
執筆者のスキルを明示するためにサラッと書いたんですが。
前スレにwimeネタを初めて書いた時点で書きましたが、
執筆者は、C言語も、Makefileも、理解していません。
いちおう、見るには見ますが、修正する能力はありません。
ケアレスミス程度なら修正しますが。
さらに言えば、シェルスクリプトも、こみいったものだと、
追いきれず、途中で迷子になります。
wimeや、Wineに対して、*BSD業界の高スキルユーザさんに
興味を持ってほしい、というのは、それが理由なんです。
「FreeBSDでは、動かないんですが」
「さあ？ Linuxでは普通に動いてるし」
「え゛え゛！」
って、ありそうでしょ。 執筆者しか、FreeBSDで、Wineが、ないと困るほどの状態で
常用しているユーザはいないのではないか、と思っていましたが、
FreeBSDでWineな方がおられました。
みなさん、WineのFreeBSDでの特有の知見を共有するためにも、
Wineをドンドン使いましょう【ＰＲ】。ｗ （URLの後は引用です）
https://twitter.com/stackfield_jpn/status/1528331070152019969
stackfield@stackfield_jpn
FreeBSDでCarrara 8.5 64bitが動いたな。 wine 6.0な。wine-devel(7.4.1)だと動かんのだがおもしろい話。
8:04 PM · May 22, 2022·Twitter Web App
https://twitter.com/5chan_nel (5ch newer account) FreeBSDの使い手でケンモメンねえ
まさかとは思うが可能性はゼロじゃねえ vncやxrdpで入ろうとするとconsolekit-daemonがエラー吐きながら1分から2分くらい待たせやがるんだが何事かわかる？ 例えばこんなの
console-kit-daemon[7641]: WARNING: Error waiting for native console 9 activation: Inappropriate ioctl for device
> なぜその吐いたエラーを貼らんのか？
寝起きで思い出した様に書いたから あとconsole-kit-daemonじゃないけど気になったのはこれ
xrdp-sesman[1599]: [ERROR] sesman_data_in: scp_process_msg failed
xrdp-sesman[1599]: [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
dbus-daemon[1440]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out (service_start_timeout=25000ms)
dbusが吐いたタイムアウトエラーの後に一応繋がりはするんだけどさ 結局手直しは諦め新規インストール用データセットへinstallworld、設定複製、
chrootして各種パッケージ入れて再起動し一応解決
リフレッシュ出来たと思う事にしました デスクトップ環境にリモートアクセスし操作する為のプログラム
そんなこと言い出したらwineの話もアウツでは amd64、i386共に wine-devel-7.8
6.0では起動しなかったbecky2が起動
https://i.imgur.com/4lfNo2n.jpg
互換性が良くなってきている模様 winnyとかFLMASKはwineで動くのかな？
当時？はFLMASKのためだけに、vmwareを入れたりしてたけど FreeBSDのMATEに、
・mate-desktop/mate-netbook
https://github.com/mate-desktop/mate-netbook
・ubuntu-mate/mate-window-applets: Window applets for MATE Desktop
https://github.com/ubuntu-mate/mate-window-applets
・ghostbsd/station-tweak: This is Station Tweak, a fork of MATE Tweak.
https://github.com/ghostbsd/station-tweak
この辺を野良ビルドで入れるのオススメ これのことか
GitHubの利用をやめるようオープンソースソフトウェア非営利団体が強く呼びかけ - GIGAZINE
https://gigazine.net/news/20220704-software-freedom-conservancy-give-up-github/
ギガジンを鵜呑みにしてしまう人っているのか Software Freedom Conservancyがどんな団体なのか
の方がgigazine云々より重要じゃないか？ >>143
今、気づきましたが、ハンドル名をコピペミスしている……。
「ERROR: 余所でやってください。[unix]」エラーのため、
書き込みをリトライしていたからだと思います。
>>156
https://www.winehq.org/search?q=atok
上記URLのWineHQ公式のデータベースでは、
2017/07/21にReleasedされたWine2.13で、ATOK2017が、Garbage評価、
という報告が出てきます。
この年度時点で、すでにwimeは熟成した存在で、執筆者君が、FreeBSDで
wimeを試した初めてのレスが、前スレに書かれています。
この時点で、wimeに対するLinux業界での喜びの声は、沈静化しており、
執筆者の、Linux板のWineスレへのレスに対しても、「懐かしい」感の
あるレスがありました。
たしかに「素」のWineでは、ATOKは動きませんが、
Wine＋wime＋ATOKで、CannaServerに見える形で動くので
周回遅れでのデータベース登録となっているのも事実です。
※ATOK2017がwimeで動作するという報告は見あたりませんが。
日本語利用者がこのデータベースを参考にする可能性は、
比較的に低いと思われますが、誤解を生む登録だなあ、
と思います。
日本語を常用利用していない方が登録したのかなあ。 すでに、ずいぶん前から使っている方からすれば、いまさらでしょうが、
Emacs28.1で、文書中の全角空白（2byte空白）が赤のアンダーバーで
表示されるようになりました。
まあ、昔から設定によって全角空白などを表示させることはできましたが、
四角い形状で表示されたりして、執筆者的にはイマイチ感があり、
アンダーバー表示の控えめ感は、ありがたいと感じています。
ただ、Emacsのエコー領域に表示されるCannaの変換候補でも表示されます。
※emacs-cannaで、canna.elを使用。
不思議なことに、全角漢字の候補のうしろにも表示されています。
漢字は全角なので、まあ、おかしくはないけれど、意味がない、と
思うのですが……、ああーっ！分かったー！
変換候補の一単語ごとの区切りの空白に全角空白を使用しているので、
それに反応して赤のアンダーバーが表示されているんだ！ (ヽ´ん`) それぼく
ごぶさたしております。
ニュー速(嫌儲)のキャラクターがカワイイので、つい見に行って
しまう執筆者君です。
FreeBSD13.1R/amd64を新規インストールしました。
さて、執筆者がアテにしているソフトウェアはWineとwimeです。
WOW64となった現在のFreeBSDのWineでは、
32bit環境の展開で「versions do not match!」>>98 となったり、
wimeのwimectrlで「"libX11.so.6" not found」>>95 >>99となったりの
過去がありますので、今のところ、FreeBSD13.0R/amd64の
「/var/cache/pkg/」からコピーして保存しておいた
「i386-wine-devel-6.12,1.pkg」を、FreeBSD13.1R/amd64に
「pkg add」で入れて使っていますが、普通に入って、普通に、
i386-wine-devel-6.12が使えています。
wimeのために、FreeBSD13.0R/i386でmakeした「imm32.dll.so」を
「/usr/local/lib32/wine/i386-unix/imm32.dll.so」に置いて
wime（FreeBSD13.0R/i386でコンパイルしたもの）が稼働しています。
もちろん、Wineが6系なので、（他のdotファイルでもよいが）.cshrcに
「setenv WINEDLLPATH /usr/local/lib32/wine」を設定しています。
こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の
「Distribution Select」で「lib32」を入れておきました。
FreeBSDのPortsのWineは、公式やLinuxと同じタイミングで、VersionUp
する時もあれば、少し対応が遅く、ほぼ固定状態みたいな時があります。
i386-wineの時みたいな感じですが、まあ、ボランティアなので文句は
言えませんね。
余裕ができたらWOW64なWineを試してみます。 FreeBSD13.1R/amd64でのVirtualBOXの話です。
現在のPortsでもpkg(8)の「quarterly」でも、VirtualBOXのVersionは
6.1.36です。
pkg(8)でVirtualBOX6.1.36を入れ、FreeBSD13.1R/amd64をブートすると
カーネルメッセージで、
KLD vboxdrv.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type
と言われます。
Solved - Virtualbox kernel module fails to load on FreeBSD 13.1-RELEASE | The FreeBSD Forums
https://forums.freebsd.org/threads/virtualbox-kernel-module-fails-to-load-on-freebsd-13-1-release.85191/
上記URLによると、2022/05/17時点の質問ですが、同じ状況が報告されて
いました。FreeBSD13.0でpkgがビルドされたことが原因のようです。
Forumで話題になっているのは6.1.34の頃の話のようですが、
6.1.36の今現在も同様のエラーが執筆者の環境では出ました。
ところが、上記Forumのfyamamoto氏の書き込み通りの手順で問題は
解決されました。
こんなこともあろうかと、FreeBSD13.1R/amd64のインストール時の
「Distribution Select」で「src」を入れておきました。
〔次に続く〕 〔前からの続き〕
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
とのメッセージが出ます。 執筆者は、FreeBSD13.0R/amd64で、Athlon5350のRadeonR3を
amdgpuで使っていましたが、FreeBSD13.1R/amd64では使えませんでした。
詳細としては、
カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。
モニターの電源ランプは、画面出力が「ある」状態だが、
実際の画面出力は「ない」。
たんに、「画面出力がないだけなのか」と、かなり時間を置いて
画面出力に頼らずにログイン作業をしてみたが、ログインできないので、
リセットボタンでリブートするしかない。
やってみたこと。
・「gpu-firmware-amd-kmod-banks」を入れてみた。
結果：状況変わらず。
・「loader.conf」に「hw.amdgpu.exp_hw_support=1」を追記。
出典：https://running-dog.net/2021/04/post_2429.html
結果：状況変わらず。
〔次に続く〕 〔前からの続き〕
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」にしていなかったからかなあ？ 、ぐらいです。
こんな風に変わっているよ、という助言などがあれば、
よろしくお願いします。
じゃ、お夜食、食べてきます。 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 はインストールしていたのか あと 13.0 から 13.1 にアップグレードしたのなら -kmod は ports で make し直す必要があるかと あわわ。即レス驚きました。ありがとうございます。
>>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」も
試しましたが状況は変わりませんでした。 そもそもこれだけ熱心にレポート書いてる人が
あんなしょうもない釣りやるとも思えんよね
ここの嫌儲民はどちらかと言えばあの >>171
> ・xorg.confに「Driver "modesetting"」
modesetting じゃなくて "amdgpu" ではどうなるの？ >>171
まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる
>>165のリンク先にも書いてある
> カーネルメッセージの、rc.confの評価あたりで、画面出力がなくなる。
-kmod は pkg じゃなく ports からインストールするように ん？ 何か嫌疑が、かかってます？
古くさい釣りAAが貼られていたのも、それがらみですか？
世の中、ヒマ人が多いんですね。
嫌儲板には書いたことはありません。閲覧のみです。
そんなことよりも、wimeを、以下略。
執筆者は、UNIX板では「FreeBSDでwimeを使っている君」で
書き込みをしています。※他の板では書いていません。
仮に、初歩的な質問をする場合で、通りすがりのフリを
したくても、即バレてしまう文体なので、恥を忍んで固定名に
するつもりです。
Linux板に書く場合も、これからは同様にするつもりです。
それもこれも、すべてwimeの宣伝のためです。
なぜ宣伝するかというと、wimeを、以下略。 さらに書き忘れていた。
執筆者が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
［終了］
ファイルの差し替え処理のようです。 日本語入力メソッド総合スレッド＠Linux＠5ch掲示板
https://mao.5ch.net/test/read.cgi/linux/1472658083/139-140
上記のレスのおかげでwime 4.1.5がリリースされているのを知りました。
新規リリースに気づいていませんでした。ありがとうございました。
上記URLでは「ATOK17」とありますが、ATOK17は、2004年度版となります。
＞ATOK17にあわせてATOK28W.IMEからATOK30W.IMEに変更したところ
とのレスが正しいとすると、2015年度版（ATOK28）に対する処理を
読み替えて変更した、ということですから、もともとの「ATOK17」表記は、
おそらく「ATOK30」が正しいと推測されるので、ATOK2017での動作報告
かと思われます。
いずれまとめて手順の書き換えをする時用にメモしておこう。
>>15に上記Linux板のURLを追加のこと、と。 >>174
＞まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる
そういうものとは、まったく知りませんでした。
今までカーネルモジュールを使うソフトウェアは、あまり使っておらず、
意識していませんでした。
＞>>165のリンク先にも書いてある
まことにすいませんでした。
英語なもので、さらっと読み飛ばして、ポイントっぽいところだけを
読んでいました。
>>173
CUIのコンソールの出力がなくなり、CUIのloginまでいけない状態なので、
xorg.confの評価までは、いけていないのです。 drm-fbsd13-kmodをpkg(8)から入れず、Portsから入れてみる。
○FreeBSD13.1R/amd64はクリーンインストール。
○amdgpuを使うために入れたもの
・pkg(8)：xf86-video-amdgpu-22.0.0
・ports ：drm-fbsd13-kmod-5.4.191.g20220604_1
※pkg(8)と同じバージョン
・pkg(8)：gpu-firmware-amd-kmod-banks-20220511
・pkg(8)：mesa-dri-21.3.8 ※注
・pkg(8)：mesa-libs-21.3.8 ※注
注 https://running-dog.net/2021/04/post_2429.htmlに
書いてあったのだが、すでに入っていた。
○以下の設定をした。
・rc.confに「kld_list="amdgpu.ko"」
・xorg.confに「Driver "modesetting"」
・「#pw groupmod video -m <ユーザ名>」
pkg(8)の「drm-fbsd13-kmod-5.4.191.g20220604_1」を、removeし、
portsから「drm-fbsd13-kmod-5.4.191.g20220604_1」を
入れましたが、以下のように状況は変わらずでした。
カーネルメッセージの、rc.confの評価あたりで、画面出力が
なくなる。
モニターの電源ランプは、画面出力が「ある」状態だが、
実際の画面出力は「ない」。 で、リセットボタン。
まさか、「１分くらい待つと画面出力が始まる」とかじゃないで
しょうね。
いえね、i386を使っていた頃は、VGA表示から精細な表示に
切り替わるのに10秒くらいかかっていたので。 うろ覚えだがgpu firmwareみたいな名前のpkgもportsで作り直しが必要だったような。 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とは違うはずだから Athlon Athlon5350なのにgpu-firmware-amd-kmod をインストールしているのが間違い
必要なのはgpu-firmware-radeon-kmodの方
分からないのならMeta ports の gpu-firmware-kmod
あと -kmod なのだから pkg ではなく ports から試すように（特にトラブってる時には） amdなんて使ってないけどwikipedia見て調べてみた
180 書いたの俺だけどこれは関係無かったか wine 等とまるで関係ないんだがCinnamonが割とまともにつかえる
足りないと思ったものは適宜追加しながらお好きな人はどうぞ
ただし画面ロックとシステム情報おまえらはまだダメか ヤらねばヤられる >>175
すいません。
Linux板のWineスレで、すでに「FreeBSDでwimeを使っている君」で
書いていました。
https://mao.5ch.net/test/read.cgi/linux/1585198566/449
>>186
Wineのスレではないので、良さげっぽかったり、便利っぽかったり、な
情報は書いてください。
スレタイは「Office/Desktop環境」となっていますが、
Unix系OSでOfficeソフトを使うような日常生活環境を構築するための
情報交換をしたい、人柱報告（>>4など）も読みたい、というのが
スレの趣旨です。
Desktop環境にしても、LinuxのDistributionにしても、構築する個人や、
コミュニティの好みで構築されているので、長短がありますから。 >>180 >>185
それ、サーバなマザーボードでの構成でしょ。
おそらく、後載せのRadeonR7は、「ダミーが刺さって」とのことから、
ビデオ出力に使わずに、演算に使っているのではないか、と感じました。
執筆者君の環境の場合、VGAを複数認識するような高価な環境ではなく、
ビデオカードをさすと、APU側のビデオ機能は無効になるマザーボードが
ある、という、ローエンド環境に、ありがちな環境です。
もちろん、この試行中でも、いちいちビデオカードを外しながら
試していました。
おかげで、アルミ筐体の拡張スロットのネジがゆるくなってきました。 >>183
＞64bitと32bitを同時に使えるようにしただけなんじゃ
たぶん、そうだと思います。 >>38 >>67 あたりに書きました。
FreeBSDのWOW64なWineとはいっても、FreeBSD/amd64の場合、
そのままでは、64bitなWindowsソフトウェアしか使えません。
32bitなWindowsソフトウェアを使いたい場合は >>69 に
書いたように、シェルスクリプトを走らせて、
ユーザのホームディレクトリの下に
32bitなWine（バイナリ提供の様子）を展開しないと
いけませんから。
以下のURLは参考まで。
http://hayabusa6.2ch.net/test/read.cgi/linux/1455088008/51-n
https://mao.5ch.net/test/read.cgi/linux/1585198566/442-n
https://mao.5ch.net/test/read.cgi/linux/1585198566/679-n なんだか、入門者の犬小屋スレみたいになっていますが、
みなさん、ありがとうございます。
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」もね！ （田中みな実さんぽくキリッとキメ顔） >>189
Linuxの場合と同様64/32bit使用可な環境作って32bitアプリインスコすると
~/.wine/drive_c/Program Files (x86) ディレクトリが出来るのでどうなんでしょうねえ
(emulators/i386-wine(含-devel)の頃には起こらなかった挙動) >>182 >>192
執筆者が「その程度のレベル」なのは、
前スレ当時から自己紹介しております。キリッ。
自分でKernelをReConfigureした場合、Ports由来のKernelModuleを
再makeしないといけない、というのは知っていましたが、
「まだ 13.0 のサポート期間なので pkg は 13.0 で make されてる」、
というのは知りませんでしたし、さらに、標準のKernelで「.1」の差が
問題になる、というのも認識していませんでした。
この後に「その程度のレベル」な、謝罪のレスがあります。 >>191
執筆者の試行では、32bit環境の.wineのまま（新規生成していない）で、
WOW64なWineで32bitなソフトウェアが動きました。
WOW64のWineでwinebootで.wineを新規生成すると、「Program Files (x86)」が
できていました。 まずは、おわびです（ガバッ、土下座）。
お散歩がてら「さがわ@sagawa_aki」氏のTwitterを見ていると
以下のようなTweetがReTweetされていました。
https://twitter.com/scp1979/status/1547002783227817985
＞晋太郎@scp1979
＞FreeBSD13.1でWineを起動したら「wine: could not load http://ntdll.so: (null)」と出て起動しなかった。
＞ググても解決方法が見つからなかった...
＞pkg info -D wine を確認したところ、procファイルシステムが必要と書いてあったのでmountしたら起動した。
＞#FreeBSD #Wine #備忘録
＞8:39 AM ・ Jul 13, 2022・Twitter Web App
執筆者は青ざめました。
「wine: could not load http://ntdll.so: (null)」で
このTweetより先に、大騒ぎした張本人だからです。
※大騒ぎの初出は、以下のURL、2020/12/11(金)。
https://mevius.5ch.net/test/read.cgi/unix/1107211157/919-921
https://mevius.5ch.net/test/read.cgi/unix/1107211157/951
https://mevius.5ch.net/test/read.cgi/unix/1107211157/952-953
https://mao.5ch.net/test/read.cgi/linux/1585198566/449
https://twitter.com/5chan_nel (5ch newer account) で、前スレ951氏助言の
「setenv WINEDLLPATH /usr/local/lib32/wine」との設定をコメントし、
/etc/fstabに「proc /proc procfs rw 0 0」と、設定をして、
winecfgを起動すると、普通にwinecfgが起動しました。
執筆者が、procをマウントしていれば、騒ぐ必要がなかったミスとなります。
前スレの951氏にはWineのソースを調べ、助言レスをさせる、という手間を
かけさせて、まことに申し訳ありませんでした。
Linux板のWineスレでも質問をして、申し訳ありませんでした
執筆者の不注意なミスにより、心配した方々に迷惑をかけて、
本当に申し訳ありませんでした。 あれれ？
>>195 のWineのエラーメッセージ引用のかぎカッコ中に
「 h t t p : / / 」とありますが、執筆者は書いておりません。
投稿時に自動的についたものと思われます。 >>196
インストールのメッセージくらい読めというところだが
貴方が前スレの992に貼ったFreeBSD Forumsでも
そのエラーの回避法としてprocのことが書いてある >>195
当時のリンク先のサイトのレスが書き込まれた日付をよーく見ると良いよ。
ついでにそれがportsに反映された時期も。
四ヶ月後に再度見に行くか？ったらまあしないだろうし
そもそも当時の作業者が初耳！してるくらいだから。
あとprocマウントしてても多分そのエラーは当時は出てたと思う。
なんでかっつーと自分のマシンは最初からfdescfsとprocfsはmount済みなんで。 >>198-200
○「wine: could not load ntdll . so : (null)」と出る件
※5chに書き込んだ時点でゴミがつくので1byte空白をはさみました
前スレ919(2020/12/11)の執筆者のレス時点では、
https://forums.freebsd.org/threads/i-cant-run-windows-applications-with-wine-64bit.77253/
の、forumsが Oct 8, 2020 (2020/10/08)で、一時的に止まった時点を
執筆者は閲覧し、レスしていました。
Alexander88207氏（i386-wineのコミッタ）の Oct 8, 2020 (2020/10/08)の
書き込み(post-480654)では、
試してみて、同様の結果になる、と、報告しています。
※執筆者はこの書き込みは見ていました。
それから、ずいぶんたってforumsが動き出しました。
tbyte氏の May 2, 2021 (2021/05/02)の書き込み(post-509356)では、
FreeBSD13のwine-devel-6.4でも同様です（執筆者意訳）、
と報告されています。
grahamperrin氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522107)で、
Alexander88207氏に対して、「Do you still get a null there?」
と返しています。
Alexander88207氏の Jul 11, 2021 (2021/07/11)の書き込み(post-522113)で、
「But the workaround for this error is to mount procfs on /proc.」
と書かれました。（注）
〔次に続く〕 〔前からの続き〕
前スレ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を閲覧して
検証することができないのですが。
〔次に続く〕 〔前からの続き〕
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257105
で、「wine: could not load」の件が報告され、
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257020
と、関係があると思われていたが、違うようだ、と、なったようだ。
「id=257105」は閉じられて、その後、どうなったかは分からない。
https://www.freshports.org/emulators/wine-devel/
では、31 Aug 2021 07:11:18(2021/08/31) の wine-devel 6.16,1で
「ntdll: Always return a value in get_builtin_init_funcs.」
として問題に対応がなされた。
……というのが時系列ではないでしょうか。
執筆者は、FreeBSD13.1R/amd64において、FreeBSD13.0R/amd64で
取得しておいた、i386-wine-devel-6.12,1のpkg(8)を「pkg add」で
入れて使っていますが、WINEDLLPATHの環境変数を設定しなくても、
「/proc」のマウントだけで使えています。
「wine: could not load」問題を、まとめれば、ですが、
現在、FreeBSDで、Wineを使うなら「proc」をマウントしておくこと、
ということですね。
執筆者が青ざめて謝罪をした意味はあります。
なぜなら、こんなことでもなければ、執筆者は「proc」をマウント
することはなかっただろう、と、思うからです。
試した報告をする方々、助言をくださる方々に感謝します。
〔終了〕 >>202
> もう今は、i386-wineのPortsTreeがないので、FreshPortsを閲覧して
> 検証することができないのですが。
パッケージを保存しておいた実機で各種検証する人の書く事とも思えんが >>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のパッチがあたるかは、執筆者は未検証。
と、書きましたが、この迂遠な手抜き手法は、そうするしかなかった、と、
いうことになります。 「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 >>206
それが Forum とかでの freebsd の ports は multilib をサポートしてないから
という発言につながるわけですな この件について、執筆者自身も、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の現状を
試さないといけないな。時間ができたら試します。 >>208
あ、連続レス中にはさんでしまった。
＞multilib をサポートしてないからという発言に
ああ。そういう意味、そういうこと、だったのか。
なんの話だろう、特殊なライブラリ？ とか思っていました。
すいません、forumsの内容も、英語のため、精読していませんでした。 そう言えばprocfsはふつうにマウントしてましたねえ
と言うか sysutils/desktop-installer でDE入れると勝手に設定されるので >>211
ああ、やっぱり。
「wine: could not load」の件は、まさに「おま環」（お前の環境特有）
だった、ということでした。大騒ぎしてすいませんでした。
fstabの見直しで、procfsの設定に追加して、tmpfsに128MBを設定したという、
あつものに懲りてなますを吹くかのような執筆者君です。
あと、i386-wineが出てきた直後ぐらいに、2chで、i386-wineが待てない人用、
として手作業の方法をレスしていた方が、Portsはユーザが、makeしてinstall
することができないので、i386-wine的なものに対応しづらい、と
読んだことがあったような気がする。
※技評のWebの後藤大地氏のFreeBSDの記事で読んだのかもしれない。
Linuxもバイナリ配布が主で、ports的な仕組みからバイナリを作って
いるんだろうけど、どうしているのかなあ。 手順の再まとめをする時用にアンカーを打っておこう。 >>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を選択する。
という結果になりました。 >>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 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 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されたものが提供されることになるでしょう。 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は違いました。 再まとめ用：
「wimeのパッチはリネームも編集もせずにそのまま置けばよい」>>11
「Wine7系からはパッチを当てても、imm.c.origとリネームされた
オリジナルのソースファイルは残らなくなった」 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氏は、どう思っているのだろう。 >>219
そこは
/usr/local/share/wine/pkg32.sh install wine-devel mesa-dri
だろ >>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
の環境下では、今のところ出ていません。 >>219 >>220
あ゛！ あ゛！ あ゛！
間違っていた！
そりゃあ、そうですよね！
pkgのメッセージをそのままコピペしただけなんですけどね！
いや、言い訳にはならないな！
間違ってました！ すいませんでした！ 執筆者としては、
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公式と同じ結果。 知らないかもしれないので書いとくが
amd64でi386-wineはビルドできる
https://wiki.freebsd.org/i386-Wine >>224
その記事は、昔から知っていたんですが、
ほぼ、理解できていませんでした。
今は、うっすら理解できます。 今のところ、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!」と言われているな。なぜだろう。
じゃ、夜食を食べてきます。 >>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 >>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を持ってきて、
展開してもいいのではないかと思う。 やだぁ。こういうこと？ しようがないわね（意味深）。
環境：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で。
http://imepic.jp/20220818/059700
http://imepic.jp/20220818/061470 そう言うズレた事やるなら今後俺が何かを手助けする事は無い 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 「パッケージのファイル名」
でインストールしてみたらどうなるの だけど libX11 は mesa-dri の依存関係でインストールされる筈だよな > versions do not match!
もし、パッケージマネージャに複数のリポジトリを登録してるなら
pkg32.shを呼ぶときにリポジトリを指定しないと混ざって不整合起こす可能性があるよ。
こっちの環境でそれ喰らって少し悩んだけど結局pkgを呼んでるわけだからオプション付けるだけ。
wine-devel 7.8.1でjanestyleの通信回りが動かなかった悲しみ。 >>227
これでいいんか？
https://i.imgur.com/gobPqEo.jpg
>>231
ここまでの流れをざっと見てみると何がしたいのかサッパリわからんな
おまかん自慢？ ちゃんと読まないからwineじゃなくてwine-develの事だと分からないんだろ ちゃんと読めば「既存パッケージで32bitアプリも64bitアプリも同時に動かせるのに何故過去の遺産に拘っているのか」
と首を傾げているって事では それは消えた i386-wine-devel のほうが今の wine よりバージョンが上だからでは
そして wine-devel(7系？)では imm32.dll.so が無くなったせいなのか wime が動かないと バージョンが上とかじゃないな
wimeの作成環境に書いてあるのがwineのstableじゃなくて開発版だから
wine-develなのか 検証不可能だが要はこれが望む環境で使えんライブラリであると
https://i.imgur.com/JtkfBpN.png
何をゴチャゴチャビルドだのdevelだの書いていると思ったわ
/procがどうのこうのだの切り分けが半端だったんだから先ずは不満な人が
既存パッケージで作れる環境でいちから試せば少しでも前進するんじゃね imm32.dll.so と書いてるのはwime君であってwimeの作者じゃないけどな
作者は imm.c にパッチをあてろと書いてるだけ
>>242
wine-devel でも imm.c はある
というか>>217-218見るとパッチがあたって無い
wine-devel/files に置くんじゃなくて
make patch の後手作業でファイルを変更してみたら ソースが無いって話はしてないぞ
imm32.dll.so が無くなった
でも imm32.dll.so なんて言ってるのはwime君で作者じゃない
linux でも7系では imm32.dll.so は無いようだ つまり氏のコレは早とちりか何かと
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のパッチをあてるのは、そもそも無理だった、
ということになります >imm32.dll.so
あるよ latestの wine-devel-7.14,1 i386のパッケージを展開し確認
quarterly の7.8に同梱されているかはしらん >>248
あ、微妙に違ってた
imm32.dll はあるが imm32.dll.so というファイルは無い >>249
>imm32.dll
マジックナンバー文字列は「MZ」 作者が書いてるのは 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 にも無い > 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でもつかってんのかな > 現在pkgに存在しないバージョンの様だが更新していないportsでもつかってんのかな
コピペミス
wine-devel-7.14,1.pkg >>231
twm愛好家なんだ よかったらあっちのスレも盛り上げてよ 13.1-RELEASE-p1 quarterly
いつの間にか sysutils/fusefs-smbnetfs がふつうに使える様になっとる
クライアントマシンとしてSMB2以降を使いたい人にはオススメ >>232
ん？ よく意味が分からないです……。
悪いところがあれば直します。
助言者が欲しくて書いているようなものですから。
>>255
「あっち」？ あらやだ、すごいことになってるわ、困ったわね（意味深）。
画像のチカラってすごいのかな（意味深）。
※こんなボケを書く雰囲気ではないんですけれど一応。 個別にレスできませんが、誤解を解きたいです。
>>239 の通りで、執筆者が今のところ、i386-wine-devel(6.12)を
使うのは、pkg(8)も、Portsも、現在のWineは6.0.4だからです。
なぜ、Wineのdevel版なのか、は、さがわ@sagawa_aki氏の修正が、
即、入っていたりして、新しいからです。
今までWineの「devel」で困ったことは、Wine1系の時に、
まったく動かなかったことが、２度あっただけで、
数日後に即、修正版が出ましたから、
Wineの「開発版」とはいえ、信頼しているから、です。
日本語入力メソッド総合スレッド＠Linux＠5ch掲示板
https://mao.5ch.net/test/read.cgi/linux/1472658083/30
でも勧めましたし。 >>217 の試行では、wine-devel(7.14)がPortsのVersion
でしたので、pkg(8)も、一時的に、latestにしました。
>>244
＞imm32.dll.so と書いてるのはwime君であって
その通りで、imm32.dll.soとか、imm32.dllとか、
のことを書いているのは執筆者本人のみです。
「wime」ではパッチをあてろとしか言っていません。 >>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
※アンカーをつけすぎると書き込めないので細切れになります。
〔次に続く〕 〔前からの続き〕
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系以降、
「分離作業が行われているから」か、と思います。 >>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対応版)に持ってきました
（少しぐらいのバージョン違いは気にしません）。
〔次に続く〕 〔前からの続き〕
その結果が、>>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 >>233 >>235
＞/usr/local/share/wine/pkg32.sh add 「パッケージのファイル名」
i386で作ったパッケージを「/home/ユーザ名/.i386-wine-pkg」
として持って来られるとは思っていませんでした。 >>263
pkg がビルドされているのは13.0R、13.1Rとはコンパイラのバージョンが違うので
md5が違うのは当然 >>262 では、肝心なことを書き忘れていました。
ホームディレクトリ以下に展開される32bit環境では、
Wine7.14では、「lib/wine/fakedlls」しかなく、
「lib/wine/i386-windows」はなくなっています。
しかし、Wine7.14をi386でmakeすると、
「i386-windows」は存在します。
>>267
ああ、そうなのか。知りませんでした。
パッチをあてて、オリジナルファイルを残さないのは
おかしいですから、なんとなくですが、
そもそも、パッチがあたっていない可能性があります。 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が
ホームディレクトリ以下に入りました。 （注）基本に戻るのは大事だと痛感しました。
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 再まとめの際は注意。 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」でした。 >>273
wime-4.1.5/io/Makefile の
ifneq "$(OS)" "Linux"
override LDFLAGS:=$(subst local/lib,local/lib32,$(LDFLAGS))
endif
を消してみたらどうなる？ 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 ※桁折り済み では、と、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に戻ってきました。 >>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 と同じ結果となりました。 32bit の libX11.so.6 があるディレクトリを
ldconfig -32 で追加したら https://github.com/chriswells0/freebsd-scripts
ここの portsfetch で quarterly の ports tree が取得できる
wine-devel も 7.8,1 ○漢字変換はできるが、「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
〔次に続く〕 〔前からの続き〕
>>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系をやってみます。 書き忘れていました。
>>269 で、
＞ホームディレクトリ以下に展開される32bit環境では、
＞Wine7.14では、「lib/wine/fakedlls」しかなく、
＞「lib/wine/i386-windows」はなくなっています。
と書きましたが、
Wine6.0.4でも「lib/wine/fakedlls」しかありませんでした。
執筆者は、安直に「imm32.dll.so」や「imm32.dll」の
ファイルだけを持って来ていましたが、
「パッケージで持ってくればよい」という知見が、
このスレで与えられました。
みなさんありがとうございました。 辛抱した代わりと言ってはなんだがよかったらtwmスレもちょいちょい書いてくれると嬉しい twmというか、ctwmだから、おじゃま虫だなあ。
執筆者君は、ctwm特有のカスタマイズはしないようにして、
すぐにtwmに切り替えられるような.ctwmを書いています。
twmのスレ、見てはいますが、特に書くネタはないなあ。
Windows3.1や、FreeBSDのAfterStep1.4からの慣れで、
「ウインドウを消すバツ（Ｘのロゴ）が最右端でないと、
使いにくいな」と、思ったことがあり、バツを最右端に
する設定を、ググり中に見つけたが、バツを最右端にすると
リサイズボタンが使いにくくなるのに気づいて、最右端は
リサイズボタンなのだなあ、と、思ったことがあります。
よくあるウインドウのように隅っこでリサイズできると
いいんだけど、窓枠が太くなるしなあ。
まあ、気をつけておきます。 それで思い出したけど、最近のGNOME系かな、
ユーザーサイド側の窓の装飾ってどうなの、と思う。
Window Manager を考えなくてもよいので、
管理の負担が減るとか、アプリケーション内の入れ子で
表示しやすい、というのが、あるのかもしれないけれど、
X Window Systemの考え方からは、逆行しているように思う。
もし、ユーザーサイド側の窓の装飾を、流行などで、
コロコロと変えられたら、ユーザ側からは地獄でしょ。
それに、そういう事をすると、逆に古びると思う。
「スマホ風のUIだって、プギャー」って時代も来るだろうし。 >>281
使ってないから知らなかったが net/gitup 見たら
gitup.conf.sample に quarterly の設定もあるな
ports の更新もこれ使えばいいんじゃね portsfetch でも更新できるから
どちらでもいいが 「portsfetch」の、ご紹介ありがとうございました。
ありがたいShellScriptですね。
VirtualBox6.1.36内のFreeBSD13.1R/i386で、portsfetchを
動かしたところ、動作中にリブートがかかりました。
portsfetch内から追加パッケージをインストールしたまま
動かしていたからなのか、負荷がかかりすぎたのか、は
不明です。
ですが、リブート後、再度、portsfetch したら
（何かを取得し直しになりましたが）、PortsTreeが
quarterlyになりました。 さて、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
〔次に続く〕 〔前からの続き〕
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の設定通りに見えて、
印刷できました。 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での設定も、ちゃんと載っていますし。 素直に pkg32.sh で cups インストールして設定すればいいと思うが □いまさらながら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の存在に困って、この入れ替え設定をしている人は、
それなりにおられると思います。 □いまさらながら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ファイルを指定します。 □いまさらながら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
５．５ プリンタの設定 | あらかると
https://www.starlink.jp/freebsd/freebsd-cups/ □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」をインストールしました。 □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でも、印刷できて
偉いなあ、と思います。
じゃ、お夜食を食べてきます。 備忘録。
タイミングで該当バージョンに当たった人がいるかもしれませんが
firefox-105は避けた方がよいようです。
Firefox-ESRが105固定になりませんように。
https://mevius.5ch.net/test/read.cgi/unix/1632283136/154-171 Firefoxは常に最新使ってるが105の時も落ちた事はないな
なおESRになるバージョンは決まってる
https://wiki.mozilla.org/Release_Management/Calendar あ、やっぱり、１つだけの報告の場合、
判断は保留したほうがいいのか。
つい、飛びついちゃうな。
ReleaseCalendarは知りませんでした。
ありがとうございました。 少し前に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の先頭部分をカットしています。 >>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が実装された さがわ@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です。 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なんですが。 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に更新されている。 前スレッドを事実上の占有状態で消費した事による贖罪の意味で、
執筆者は、次スレッドとして、このスレッドを作成しました。
別にスレッドのヌシというわけではありません。
5ch(2ch)専用ブラウザ分裂がらみの「talk」掲示板のUNIX板には、
このスレッドと同名のスレッド（>>1のみがある状態）が存在しますが、
執筆者が関与したものではありません。
>>1 のみが、コピーされた形でのスレッドのようです。
「出典」という形で、このスレッドのURLが表記されてはいますが、
著作権的にはどうなんでしょうね。
「出典」には、あたらないように思います。以上です。 