ここには、FreeBSD の「その他のメモ」を置きます。
必要なら 「インストールに関するメモ」 「X に関するメモ」 も参照してください。
FreeBSD に関するページへ戻る先日、 HP Compaq dc7700 の FreeBSD/i386 13.2 を FreeBSD/amd64 14.0 に更新しました。 色々問題もあったのですが、ports に関する情報をこちらに置いておきます。
私は LANG=ja_JP.eucJP (今だに) で普段は作業していますが、 perl を使うと、
Locale 'ja_JP.eucJP' is unsupported, and may crash the interpreter.なんてのが出るようになっています。 とりあえず今のところ実害はないようですが、ちょっと嫌です。
私はメールサーバからのメールを japanese/mh の inc (今だに) を使って APOP (今だに) で取得していますが、 OS を更新してから、inc の APOP がつながらなくなりました。 よくよく調べると、APOP の認証用の暗号が、不正なものが送られていて、 それは 64bit 対応がちゃんと行われていないことが原因でした。 さすがに、amd64 上でそんな古いものを使っている人はいないのでしょう。 以下のパッチを使って問題は解消されました。
とりあえず amd64 対応にしてありますが、 あまり正しいものではないと思います。bugzilla にも報告済みです。
わたしは印刷は、PostScript ファイルベースで行っているのですが、 プリンタから紙のサイズが違う、と文句をいわれました。 a4 でなく letter で出ているようです。 これは、/usr/local/etc の papersize が papersize.letter へのリンクになっているのを papersize.a4 に直せば解消します。 なお、これは libpaper を使うコマンドに影響するようです。
「FreeBSD: その他のメモ (01/25 2024)」 で紹介した、portupgrade の egrep の不具合ですが、 それを動かしていたのは i386 版の FreeBSD (13.2-RELEASE-p9) でした。
先日、amd64 版の 2 台の FreeBSD マシン (14.0-RELEASE-p4, 13.2-RELEASE-p9) で portupgrade を実行したのですが、 その egrep の不具合は最後まで発生しませんでした (-ac の方は起きるよう)。 ということは、egrep の問題は、i386 版特有の問題なのかもしれませんが、 それはそれで余計に謎が深まったような気もします。
portupgrade について 2 点ほど気がついたことを書きます。
「FreeBSD: その他のメモ (12/20 2023)」 で紹介した、portupgrade の -ac の make config の作業を最初にやってくれなくなった件ですが、 原因はまだわかっていません。 -aC がよいかもと書きましたが、そちらもだめでした。
ただ、それについては回避策を見つけました。 とりあえず make config は、ほとんどの場合は使用せず、 単に enter を打ってるだけだったので、 それに代わるものとして標準入力から改行を食わせる、 という方法です。
FreeBSD には y を標準入力に打ち込んでくれる /usr/bin/yes なるコマンドがありますが、 それと同様に改行を入力させればよいと思って、最初は awk を使って、
# awk 'BEGIN { while(1) print "" }' | portupgrade -ac
** Command failed [exit code 0]: /usr/bin/script -qa /tmp/portupgrade20240124-59682-2i6x28 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=gtk4-4.12.4 UPGRADE_PORT_VER=4.12.4 make FETCH_BEFORE_ARGS=-q「/tmp/port...」が script コマンドが作成するログファイルです。 「exit code 0」で止まっている変だと思っていたのですが、 core の中身を見たら大量の改行コードが含まれていたし、 コアファイルのサイズがいずれも同じだったので、 上に書いたような理由ではないかと想像しています。
** Fix the problem and try again.
そこで、awk に吐かせる改行コードをだいぶ減らして、 1 秒に 1 回だけ打つようにして試してみたら、 ちゃんと問題なく portupgrade が通るようになりました。 1 秒に 1 回にするには、例えば上の awk の部分を
awk 'BEGIN { t=systime(); while(1) { while((s = systime())< t+1) ;
print ""; fflush(); t=s}}'
これは、やはり portupgrade の途中で、
egrep: empty (sub)expressionのように出て止まってしまう問題です。 これは調べてみると、FreeBSD の /usr/bin/egrep (BSD grep) の問題のようで、 「(A|)」のようなパターンで egrep を実行するときに出るメッセージのようです。 実際、/usr/local/sbin/portupgrade (ruby スクリプト) 内に、 「... use (in |)this function...」のようなパターンが使われています。
** Command failed [exit code 0]: /usr/bin/script -qa /tmp/portupgrade20240117-59912-lsb8wz env UPGRADE_TOOL=portupgrade UPGRADE_PORT=glib-2.78.3,2 UPGRADE_PORT_VER=2.78.3,2 make FETCH_BEFORE_ARGS=-q
** Fix the problem and try again.
従来は起きなかったので、/usr/bin/egrep が更新されて起きた問題のようですが、 以前が GNU grep だったのか、 それとも BSD grep でそういう問題の起きないバージョンだったのかは ちょっとわかりません。
解消法としては 2 つ考えられます。
[a] の方は、「(in |)」と書かれている部分を 「(in)?」に変えればいいと思います。
[b] の方は、その設定は、portupgrade と一緒にインストールされる ruby パッケージ pkgtools が /usr/local/lib/ruby/site_ruby/3.1/pkgtools/ (バージョン番号は環境依存) にありますが、 その中の pkgtools.rb という ruby スクリプトの
system '/usr/bin/egrep', '-q', pat, file
system '/usr/local/bin/ggrep', '-E', '-q', pat, file
ggrep: warning: stray \ before #
色々問題が起きていて、かつ情報もあまりないようなので、 そろそろ portupgrade も捨てどきなのかなとも考えています。 なお、いずれの場合も、portupgrade を使わず、 それぞれのディレクトリで make install を手動で行う分には 特に問題は起きていません。
一台 FreeBSD を 13.2 (i386) から 14.0 (amd64) に上げたのですが、 ports などでも色々ありましたので、ここにまとめて書いておきます。
→ 私はこのマシンで www/py-selenium, www/geckodriver, www/firefox-esr を利用しているのですが、それが今回の更新で動かなくなりました。 まずは selenium が selenium3 から selenium4 に変わったことで、 いくつかプログラムの書き直しが必要そうなことがわかりました。
しかしそれだけでなく、ごく簡単なソースでも py-selenium から firefox が起動してくれません。 これは、以下に情報があってそれでようやくわかりました。
どうやら、現在の FreeBSD の ports の selenium4 + geckodriver (0.26) の組み合わせが問題のようで、selenium4 が geckodriver を呼び出す際の -websocket-port のオプションを、 古い geckodriver (0.26) が認識しないことが原因のようです。 geckodriver を 0.30 以降に上げることが selenium4 を使うための必要条件のようですが、 FreeBSD の現在の ports (package) ではそうなっていません。
ということで、解決策はむしろ selenium4 を selenium3 に下げることで、 これは pip を使って手動でインストールすることでいけるようです。 まずは、devel/py-pip をインストールし、
# pip-3.9 uninstall selenium
# pip-3.9 install 'selenium<4.0.0'
少し前の話もありますが、いくつかまとめて書きます。
portupgrade したら、
- devel/libpthread-stubs (port deleted)
そこにあるように、pkg info -r libpthread-stubs とすると libxcb-1.15 がでてきて、x11/libxcb を更新したら libpthread-stubs を pkg delete しても問題ありませんでした。
別な portupgrade で、multimedia/mplayer の更新に失敗していました。 ログを見ると、
codec-cfg.c:60:10: fatal error: 'libavutil/avutil.h' file not
found #include "libavutil/avutil.h"
portupgrade で、
- x11/libdmx (port directory error)
同様に japanese/kappa20 にも port directory error がでていたのですが、こちらはちょっと面倒でした。 一回 pkg delete して japanese/font-kappa20 を再インストールしたのですが、 portupgrade すると何度やっても同じ「japanese/kappa20」に対する port directory error が出続けます。 「pkg info ja-font-kappa20」としてみると、 正しく「japanese/font-kappa20」が表示されます。 つまり、「japanese/kappa20」の古い記録がどこかに残されているために 起きていることだとわかります。
それがようやく、/var/db/ports/ に japanese_kappa20/, japanese_font_kappa20/ なんてのが残っているためだとわかりました。 それを手動で消してもだめで、結局 pkg delete ja-k20fonts で ようやく kappa20 の呪いから逃れることができました。
多分すぐに更新されるでしょうが、editors/libreoffice (libreoffice-7.4.1.2_1) の i386 上でのコンパイルでエラーがでました。 エラーの内容は、
/usr/ports/editors/libreoffice/work/libreoffice-7.4.1.2/vcl/unx/generic/window/salframe.cxx:650:39:
error: non-constant-expression cannot be narrowed from type
'unsigned int' to 'tools::Long' (aka 'long') in initializer list
[-Wc++11-narrowing]
maGeometry.setPosSize({ x, y }, { w, h });
これを www/firefox/files の中にコピーして make clean して make し直せばよいでしょう。
多分すぐに更新されるでしょうが、www/firefox (firefox-105.0.1) の i386 上でのコンパイルでエラーがでました。 エラーの内容は、
/usr/ports/www/firefox/work/firefox-105.0.1/modules/fdlibm/src/math_private.h:33:21:
error: typedef redefinition with different types ('double' vs 'long double')
typedef double __double_t;
/usr/include/x86/_types.h:87:21: note: previous definition is here
typedef long double __double_t;
そこのパッチと同様に、modules/fdlibm/src/math_private.h の
「typedef double __double_t;」
「typedef float __float_t;」
の 2 行を削除してコンパイルが通りました。そのパッチを以下に置きます。
これを www/firefox/files の中にコピーして make clean して make し直せばよいでしょう。
なお、うちの FreeBSD (i386) では、別なもう一台で、firefox-106.0,2 をコンパイルしたら、上のパッチだけではやはりエラーが出て止まりました。 今度はこんなやつです。
In file included from Unified_cpp_aec3_aec3_gn1.cpp:137:
/usr/ports/www/firefox/work/firefox-106.0/third_party/libwebrtc/modules/audio_processing/aec3/matched_filter.cc:168:20:
error: always_inline function '_mm_set1_ps' requires target feature
'sse', but would be inlined into function 'MatchedFilterCore_SSE2'
that is compiled without support for 'sse'
__m128 s_128 = _mm_set1_ps(0);
www/firefox の Makefile を見たら、powerpc64 の場合は、MOZ_OPTIONS に
「--disable-webrtc」というのがついています。
まさに上のエラーはそれっぽいので、
うちの i386 でも Makefile の MOZ_OPTIONS にそれを追加してみたら、
ようやくコンパイルが通って firefox が立ち上がるようになりました。
今のところこのマシンでは、WebRTC (Web 上のリアルタイム通信 ?) は必要なさそうなのでとりあえず上のようにしましたが、 もし必要になったらまた bugzilla でも探してみます。
最近 FreeBSD (i386) 13.1 の上で ports を更新して portupgrade をしたら、 libreoffice のコンパイルが通らなくなってしまいました。 ログがちょっと残っていないのですが、6 つのコンパイルエラーがでた、 とかいうものがでていました (libreoffice-7.3.5.2 ?)。
それから 2 週間位経って、昨日 ports を更新して portupgrade を再び実行したら、今度は libreoffice が無事インストールされていました (libreoffice-7.4.0.3_1)。 ただ、.pptx のファイルを開こうとしたら、 以下のようなエラーメッセージがでました。
コンポーネットが読み込めませんでした。
壊れているかインストールが完了していない可能性があります。
詳細なエラーメッセージ:
loading componentlibrary
<file:///usr/local/lib/libreoffice/program/../program/libsdlo.so>
failed
それから、i386 ではいつの間にか math/octave がインストールできなくなっています。 少し前にインストールしたものを一度消していたのですが、 ふと思いだして ports で make しようとしたら、それが使う net/mpich の下の sysutils/slurm-wlm が i386 はサポートしてない、 とか言ってきてコンパイルができません。
これは、とりあえず net/mpich で slurm を使わないようにして make してインストールできました。具体的には、net/mpich の Makefile で、
libslurm.so:sysutils/slurm-wlm」の行を削除
--with-hwloc-prefix=${LOCALBASE}」を削除
のようにして make install できました。 これで math/octave が一応 make install できましたが、 その octave の動作に問題がないかどうかはわかりません。
最近 portsnap + portupgrade で更新したら、 firefox の更新 (100.0) に失敗しました。 www/node の vulnerability のせいのようです。
その後 portsnap してみたのですが改善せず、 www/node を DISABLE_VULNERABILITIES=yes でコンパイルしてみたのですが、 今度はそのコンパイルでも失敗してしまいます。
ということで、www/node の代わりに www/node16 を入れてみたら、 こちらは vulnerability も出ず、firefox も無事インストールできました。 まともに動くのかどうかはわかりませんが、 とりあえずこれでインストールエラーは回避できるようです。
うちでは一部、cron で selenium を動かす仕事があり、 firefox のアップグレードに失敗っていうのは結構痛いので、 上記のような回避情報はどこかにあって欲しいなと思います。
ports の japanese/tex-ptex をインストールしようとして こけた問題がありました。amd64 版では起きてないようなので、 i386 版固有の問題かもしれません。
texlive-20210325-texmf.tar.xz を fetch しようとしてコケてしまいます。 コケ方は、
fetch: ftp://XXXX/texlive-20210325-texmf.tar.xz:
size mismatch: expected 2147483647, actual 3474113420
SIZE (TeX/texlive-20210325-texmf.tar.xz) = 3474113420
で、ネットで検索して以下を見つけました。
案の定、fetch のバグでした。サイズが 4byte 整数の限界を越えていたので、 正しい動作ができなかったわけです (2147483647 = 231- 1)。
上記 2 つ目のサイトに差分があったので、/usr/src/usr.bin/fetch/fetch.c にその修正を入れ、/usr/src/usr.bin/fetch 内で make install すれば 改良版の fetch がインストールされ、 これで正しく fetch できるようになりました。
freebsd-update では更新されていないので (13.0-p11 の時点)、 ちょっとわかりにくい問題かもしれません。 早急に freebsd-update に入れてもらいたいですが、 この問題があまり広まっていないのであれば (fix は 2 ヶ月前)、 i386 版のユーザで、かつ TeX を更新しているユーザがほとんどいない、 ということなのかもしれません。
全体としては FreeBSD に限った話ではありませんが、 一応 FreeBSD の環境の話として書いておきます。
手動で実行していた csh スクリプトを、 cron で定期的な処理をさせるように crontab に入れたのですが、 いくつか問題がありました。 なお、私は普段日本語は EUC-JP (ja_JP.eucJP) の環境で利用しています。
その csh スクリプト内部では、sed を使っている箇所があり、
その sed スクリプト (別ファイル) で日本語の文字変換、
具体的には機種依存文字である「全角ローマ数字」(EUC-JP では
0xAD 0x35 が「I」等) を、半角の I,II などに変換するために、
「s/\xad\xb5/I/g」のような処理をしています。
それが、kterm 上で手動で実行すると問題なく動きますが、cron からだと
「RE error: illegal byte sequence」とかいって動きません。
/usr/bin/sed がだめで、
/usr/local/bin/gsed なら問題なく動くようなのですが、
一応もう少し調べてみました。
cron からの実行だと、LANG 等の環境変数が設定されないため
それらに依存して挙動が変わるコマンドなどが影響を受けますが、
kterm 上で「setenv LANG C」(sh 系なら LANG=C)
として sed を実行しても cron で起きる問題が再現できません。
「setenv LANG ja_JP.UTF-8」として
ようやくその問題が再現しました。
しかし、まさか cron のデフォルトの LANG が「ja_JP.UTF-8」
だとは思えないので、cron での locale の状態を知るために cron で
locale コマンドを実行させてみたら
以下のようになりました。
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_TIME="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=
ということで、この問題は、内部でその sed スクリプトを実行する
csh スクリプトの先頭に
「setenv LANG ja_JP.eucJP」を入れることで解消しました
(多分 setenv LANG C でもよい)。
さらにもう一つ問題があります。 その csh スクリプト自体は EUC-JP で書いていて、その内部で、
echo "<h1>$class クラス</h1>" >> file.html
LANG が ja_JP.eucJP の場合が一番正常なものに近いのですが、 2 文字目の 8bit 目が欠けて、その後の全角文字が出力されていない、 といった感じで、引用符を変えてもだめ、echo を /bin/echo や ヒアドキュメント、gawk などに変えても (さらに -W ctype オプションを使っても) 全く状況が変わらなかったので、 もしかして csh スクリプト内に日本語を書くこと自体がだめで、 その実行前に日本語が落ちているのではないかと思い、 その csh スクリプトの実行前に LANG を変更する、具体的には crontab の
「csh -f /home/hoge/targ.csh」
を、
「LANG=ja_JP.eucJP csh -f /home/hoge/targ.csh」
に変えることでようやく文字化けが解消しました。
こうすれば最初の問題も csh スクリプト内で
LANG を設定しなくても解消します。
なお実際は、その csh スクリプトのログを取る関係で、 その csh スクリプト自体をさらに別の csh スクリプトから呼び出して実行するように cron に書いていたので、 crontab にではなく、その一段上の csh スクリプトの方で LANG を設定するようにして解消しました。
もはや FreeBSD とはほとんど関係ありませんが、 「FreeBSD: その他のメモ (01/27 2022)」 の続きの話としてここに書いておきます。
selenium + firefox でのスクレイピングですが、 「FreeBSD: その他のメモ (01/27 2022)」 で紹介した pyautogui を使う方法だと、 最近の firefox ではうまくいかないことがあることに気がつきました。 firefox は ports でも頻繁に更新されていますが、最近の firefox 98 は、 ファイルをダウンロードするとダウンロードの進行状況や履歴を表示する 「ダウンロードパネル」が自動的に立ち上がって 何かクリックするまでそれが閉じなかったりします。 それが丁度 pyautogui を実行する場所と重なってしまうと ダウンロードに失敗してしまいます。
調べてみると、そのような仕組みが firefox に採用されたのは 98.0 からのようで、以下によれば他の機能も合わせて「ダウンロードに関する改善」 だということです。
ところが、私と同じところをだいぶ不満に感じている人も多いようで、 そういう質問もかなりありました。
一致しているのは、preference として
browser.download.alwaysOpenPanel を
False にセットせよ、というものです。
実際それを行うことでうまくいきました。
ひとつ xdvi ではまったので報告しておきます。
一月ぶりくらいに ports を更新して portupgrade をかけたら、 texlive が 2015 から 2021 に (2022 2 月位)、 gs も 9.52 から 9.55.0 に更新されていました。 ということで、japanese/tex-ptex も更新したのですが、 問題は print/tex-xdvik です。 これも今回 xdvik-22.87 から xdvik-22.87.06 ベースに更新されています (2022-03-18)。
dvips, dvipdfmx は問題なく日本語が処理できるのに、
なぜか xdvi だけ日本語が表示できません。
「
ports の UPDATING にも記載はないし、 ソースを見たり、設定ファイルをいじってみたりしたのですが、 さっぱりわかりません。
仕方なくダウングレードでもしてみるかと FreshPorts ( https://www.freshports.org/print/tex-xdvik) を見てみたら、 なんと今回の更新 (22.87.06) について以下のような記載があります。
print/tex-xdvik: Update version 22.87 => 22.87.06つまり、日本語表示できる xdvi が欲しければ、 「japanese/ja-tex-xdvik」を使えということのようです。 確かに、ports あらたにそんなものが入っているので、 print/tex-xdvik を deinstall した後に japanese/ja-tex-xdvik を install して、めでたく日本語が表示されました。
While upgrading the extra japanese ptex patches has been removed as those
are not compatible with latest version and the old patches are also from
early 2008. If someone make those work with the new version the patches
are welcome. For further details or the older version of tex-xdvik with
those patches please use japanese/ja-tex-xdvik
更新されてまだ 1 週間程度なので、 UPDATING にも出てないのかもしれませんが (最終更新日は 2020-03-13)、 ちょっとはまってしまいました。
www/py-selenium の firefox driver を使って Web スクレイピングをしているのですが、 その中の画像をダウンロードしようとして なかなかうまくいかなかったことを少し報告します。 これ自体は FreeBSD とは関係ありませんが、途中で関係してきます。
img タグの jpeg ファイルを取得したかったのですが、
その URL 部分が直接画像の置き場所であれば容易にダウンロードできたのですが、
そこが「src="XXXX.aspx"」のように
ASP プログラムを実行した結果が出力されるようになっています。
Web ページ自体を保存すればその画像ファイルも一緒に保存されますし、 ブラウザの機能を使えばちゃんと保存できます。 しかし、selenium でその ASP 部分の画像をダウンロードする方法がわかりません。 そもそも表示されている時点で firefox は画像をどこかに ダウンロードしているはずだと思いますが、 それがどこにあるかはわかりません。 スクリーンショットなら selenium の get_screenshoto_as_png() でちゃんととれるのですが PNG 画像になってしまいますし、 本来の画像に比べるとやや解像度も落ちます。 ということで、本来の画像を selenium から (または同じ python スクリプトから) ブラウザの機能を使って保存することを考えてみました。
firefox の preference で browser.altClickSave
という機能を有効にすると ALT + click または ALT + enter
でカーソル位置の画像をダウンロードできる、
という情報を見つけたので、
selenium でそれをやってみたのですがどうもうまくいきません。
実際、別に立ち上げた firefox の about:config で
browser.altClickSave を
True にしてみたのですが、Alt + click も Alt + enter も効きませんでした。
カーソル位置のファイルのダウンロードには、 右クリックで出るプルダウンメニューの 2 番目の「名前をつけて画像を保存(V)」 (Save as ...) が使えるのでは、と思い、 context_click() (右クリック) と send_keys(Keys.ARROW_DOWN) や send_keys('v') などを組み合わせて「右クリック + 下矢印」、 「右クリック + 'v'」などを実現しようとしたのですが、 どうもうまくいきませんでした。 どうやら、右クリック後のキーコードの送信は、 プルダウンメニューの方ではなく、 ブラウザ画面の方に送られてしまっているようです。 実際、下矢印ではブラウザ画面の方がスクロールされてしまいました。
そのため、マウスカーソルの移動 (move_by_offset) などもやってみましたがうまくいきません。 これももしかしたらブラウザ画面の方の移動であって、 ブラウザが生成するプルダウンメニューの方を見ていないのかもしれません。
調べると、pyautogui という python モジュールを使えば、 selenium とは別にキーボード操作、マウス操作が python スクリプトから行える、 と知りましたので、それを入れてみることにしました。 残念ながら ports にはないようなので、
% pip-3.8 install pyautogui
NotImplementedError: Your platform (FreeBSD) is not
supported by PyAutoGUI.
この __init__.py に FreeBSD のエントリを追加して、 さらに x11-toolkits/py-xlib をインストールしたら ようやく pyautogui が利用できるようになりました。 その __init__.py 用のパッチを以下に置いておきます。
これにより、 selenium の get_window_position() で firefox の左上の座標を取得し、 そこからの相対位置を指定して pyautogui.click(), pyautogui.press('enter') (保存ダイアログでデフォルトを選択する) を使うことで、 firefox の右クリックのプルダウンメニューを使って、 めでたく画像を保存することができるようになりました。
なお、うちの環境では firefox で browser.altClickSave
は効きませんでしたが、FreeBSD 全般に起きることなのかはわかりませんし、
firefox ではなく、
Chrome (www/chromium) ならその方法でもいけたのかもしれません。
直接 FreeBSD とは関係ありませんが、graphics/xli 用のパッチを作りました。
大量の写真などの画像ファイルをスライドショー的にざっと目を通したい場合、
例えば gif アニメーションファイルに変換して
(「convert -delay [delay] *.jpeg anim.gif」等)、
それを animate や xanim や Web ブラウザで見る、という手がありますが、
convert での変換に時間がかかります。
xli で大量のファイルを指定して (xli *.jpeg)、
space キーで次々切り替える手もあり、これは変換が必要ないので楽なのですが、
space キー押しっぱなしだと一つ一つの画像の表示秒数を指定できず、
速すぎることが多いです。
一方で、xli にはスライドショー用のオプションがあり、
「-delay [delay]」を指定すると (「xli -delay 1 *.jpeg」等)、
その delay 間隔で自動的に指定したファイルを切り替えてくれます。
ただし、この delay 間隔は秒単位なので、これだと遅すぎます。
そこで、この delay 間隔をミリ秒単位で指定できる「-mdelay [millisecond]」 というオプションを実現するパッチを作りました。 FreeBSD 用のパッチで、/usr/ports/graphics/xli の下 (あるいはそのディレクトリをどこか別のところにコピーして、その中) で以下のファイルを展開すると、 files/ に patch-options.h, patch-options.c, patch-windows.c が追加され、patch-xli.c, patch-xli.h は上書きされます。
やってることは、秒単位の alarm() 関数を、マイクロ秒指定ができる setitimer() で置き換えているだけなので、 それをサポートしている Unix (Solaris とか) なら動くかもしれません。 ただし、指定したミリ秒間隔が厳密に守られるわけではないと思います (多分)。 また、-idelay の方は何もいじっていませんので、 そちらはまだ秒単位のままです。
とりあえずこれで「xli -mdelay 100 *.jpeg」のようにすると、
space 押し続けよりは見やすく、
「-delay 1」よりは全然早回しの約 0.1 秒間隔スライドショーになります。
最近、FreeBSD-12.2 を FreeBSD-13.0 に更新したのですが、 grep (/usr/bin/grep) のバージョンが変わったらしく、 スクリプトなどに仕込んである grep の処理が急にかなり遅くなってしまいました。 ひどい場合は 1 分で終わってた処理が数時間かかります。
grep -V で見ると、
12.2 では「grep (GNU grep) 2.5.1-FreeBSD」、
13.0 では「grep (BSD grep, GNU compatible) 2.6.0-FreeBSD」
のようです。
調べてみると、LANG=C だと早い、
という情報を見つけました。
マルチバイト処理に対応したため、LANG=C
でない場合は遅くなったということでしょうか。
確かに試してみるとそうなっているので、LANG=C
をスクリプトに追加する修正と、
awk で代用する修正を行いました。
awk の方が少し遅いようですが (GNU awk で 3 倍位、
/usr/bin/awk で 7 倍位)、awk だと LANG による違いはないようなので、
特にコマンドラインで使う場合は気が楽です。
最近 portupgrade をやったら、graphics/opencv で失敗していました。 ログを見ると、どうやら math/cblas と math/openblas の conflict が原因のようです。
現在、うちのシステムには math/openblas の方がインストールされていて、 cblas をインストールしようとしているのは、 良くみると math/py-numpy のようです。 色々情報を探して見ましたが、少しわかりにくかったのですが、 math/py-numpy で math/cblas でなく math/openblas を使うようにすればいいようで、 結局、math/py-numpy で make config して、 NETLIB (デフォルト) ではなく OPENBLAS を選択することでうまくいきました。
「FreeBSD: その他のメモ (07/03 2020)」 に続き、perl-5.005.03 + jperl5.005_03-20000401.pat も入れました。 これは、以下のような手順です (tcsh 環境)。
gunzip -c perl-5.005.03.tar.gz | gtar xf -
cd perl-5.005.03
gunzip -c ../jperl5.005_03-20000401.pat.gz | sh
gunzip -c ../jperl5.005_03-20000401.pat.gz | gpatch -p1
gpatch -p1 < ../perl553-freebsd12X-1.diff
setenv MAKE gmake
./Configure -sde -Duseshrplib -Dsh=/usr/local/bin/bash
-Dprefix=/home/hoge/perl-5.005.03
gmake
gmake test
gmake install
5.8.9 の場合に加えて、malloc(), free() の型用のマクロ Malloc_t, Free_t に関する修正、makedepend を実行する sh (bash) と make (gmake) に関する修正、cc -E が出力する 「<built-in>」、 「<command line>」に関する修正を追加しています。 とりあえずコンパイルは通りますが、gmake test は op/stat と lib/db-recno の 2 箇所で FAILED が出ました。
とある事情で、FreeBSD 12 上で 5.8 あたりの古い perl が必要になり、 自前でコンパイルしてみたのですが、どうもうまくいきません。 最初の手順は以下のような感じです。
gunzip -c perl-5.8.9.tar.gz | gtar xvf -
cd perl-5.8.9
./Configure -sde -Duseshrplib -Dprefix=/home/hoge/perl-5.8.9
gmake
-Dcc=gcc を追加して gcc でコンパイルしてもだめです。
perl-5.8.9 用の古い ports (lang/perl5.8) ってのを古い FreeBSD マシンから持ってきてパッチを眺めてみたのですが、 関係ないものばかりのようであまり参考にはなりませんでした。 実際、それらのパッチをあてても問題は解消されません。
直接のコンパイルエラーは、memchr() のマクロ展開で ':' のポインタを取得しようとしているところがだめ、 となっています。調べると、memchr() を持ってない環境では、perl.h で
#define memchr(s,c,n)
ninstr((char*)(s), ((char*)(s)) + n, &(c), &(c) + 1)
memchr(tmpbuf, ':', len)」
なんていうコードで引っかかっています。
このコード自身問題だと思いますが、このマクロが修正されたのは
perl では 5.28.0 以降なので、とりあえずその修正は保留です。
むしろ、memchr() は FreeBSD にあるのに、 ちゃんと Configure で認識されない方が問題なので、 そちらの対処をすることにしました。そうすれば代用マクロは必要ありません。 Configure を見ると、memchr() などの関数の check は、 libc にあるかどうかを見ているようなのですが、 そこが失敗しているようです。 Configure のログを見ると、memchr() だけでなく、相当多くの関数が 「NOT found」と認識されてしまっています。 ログには、
Where is your C library? [/lib/libc.so.7]
This may take a while................../usr/local/bin/nm didn't
seem to work right. Trying /usr/local/bin/ar instead...
/usr/local/bin/ar: /lib/libc.so.7: file format not recognized
/usr/local/bin/ar didn't seem to work right.
nm だけではだめで -D のオプションが必要なので、
Configure に -Anm_opt='-D'
を追加したらとりあえずそこはクリアし、
Configure 時に「NOT found」となっていた
多くの関数が認識されるようになりました。
ところが、これで gmake すると、今度は ext/attrs でエラーがでます。
cc -Bshareable -L/usr/local/lib attrs.o -o ../../lib/auto/attrs/attrs.so
ld: error: undefined symbol: main
-Bshareable がおかしくて、
正しくは -shared です。
そのために調べてみたら、これらのデフォルトの設定が
hints/freebsd.sh にありました。
最初からこれを修正すればよかったわけです。
ちなみに、これは相当古く、FreeBSD の 1.X, 2.X
用の設定しかまともには書かれていませんでした。
ということで、FreeBSD 12.X 用の、perl-5.8.9 の hints/freebsd.sh
へのパッチを以下に置きます。
これで、-Anm_opt='-D' も不要になります。
ただし、当方はとりあえず動くものがあれば、
ということで最低限の修正しかしていません。
特に、thread を有効にしたい場合は、もう少し修正する必要があると思います。
これで gmake が通るようになりました。 なお、gmake test は lib/Time/Local だけこけていましたが、 とりあえず無視しています。
最近、EPS から tgif への変換用に graphics/pstoedit をインストールしました。 インストールは問題なかったのですが、 それを使用すると以下のようなものがでます。
% pstoedit -f tgif file.eps file.obj
...
*** WARNING - you have selected SAFER, indicating you want Ghostscript
...
Error: /invalidfileaccess in --run--
...
GPL Ghostscript 9.50: Unrecoverable error, exit code 1
...
「Unix
に関するメモ等 (02/28 2020)」 にも書いたのですが、
gs は 9.28 あたりからセキュリティの関係で
-dSAFER モードをデフォルトにしていて、
gs のコンパイル時に埋め込まれた検索ディレクトリ以外のファイルを
デフォルトでは読み込まなくなりました。
あまりいいやり方ではないかもしれませんが、
これは、とりあえずは一時的に、
環境変数 GS_OPTIONS に「-dNOSAFER」
を設定すれば回避できます。
最近 python3 のデフォルトが python-3.6 から python-3.7 に上がったようで、
py36-* というモジュールが残ったまま portupgrade したら、
それらの混在のせいで devel/cmake, devel/llvm90, textproc/gtk-doc
の更新に失敗していました (unknown build error)。
そこで「pkg delete -f py36-\*」とやって
portupgrade を再開したら、cmake, llvm90 についてはなんとかいけました。
gtk-doc は、少し前から make に失敗するようになっています。 具体的には、gtk-doc-1.29/help/manual の make 時に以下のようなものが出ます。
File &qout;/usr/local/bin/itstool", line 27,
in <module>
import libxml2
ImportError: No module named libxml2
また、「FreeBSD: その他のメモ (12/27 2018)」 に書いた print/tex-luatex, print/tex-xetex の問題は、 同じ現象が起きたり、別な現象でコンパイルが止まることがありますが、 いずれも cc, c++ を使うことで回避できます。簡単にするには、
make 'CC=/usr/bin/cc' 'CXX=/usr/bin/c++'
また、最近 linux-c6 も linux-c7 に更新されたようで、
これは「pkg delete linux_bse-c6-6.10_2」のようにして
c6 の一式を消して emulators/linux_base-c7 をインストールすればいいようです。
最近 FreeBSD 上の LaTeX (latex, pdflatex) で おかしな現象に悩まされていました。 以下の LaTeX のソースのように、savebox, usebox を使うと、 その中の数式の記号 (積分記号や平方根の左部分) がずれてしまう、 という現象です。
\documentclass{article}
\newsavebox{\myboxi}
\newsavebox{\myboxii}
\begin{document}
\savebox{\myboxi}{\mbox{$I = \int_0^1 x^3dx$}}
\savebox{\myboxii}{\mbox{$c = \sqrt{a^2+b^2}$}}
\begin{quote}
\usebox{\myboxi}\usebox{\myboxii}
\end{quote}
\begin{quote}
$I = \int_0^1 x^3dx$, $c = \sqrt{a^2+b^2}$
\end{quote}
\end{document}
これは、latex, pdflatex (注: どちらも /usr/local/bin/pdftex へのリンク) ではこの問題が起き、 platex では起きていませんでした。 また、手元にある FreeBSD の 2 つのマシンではこの問題が起きるのですが、 他の OS の上にあった latex, pdflatex (TeXLive) では問題は起きなかったので、 最初は、FreeBSD の TeXLive のバージョンが古いせいかと思っていました。 FreeBSD では今だに TeXLive が 2015 のままですが、 他の OS (Windows, Solaris) に入れてあったのは TeXLive 2016, TeXLive 2017 などだったためです。 ただ、その間の pdftex の更新状況 (ChangeLog) を見ても、 それらしい問題への対処もないし、不思議に思っていました。
その問題をネットで尋ねてみたのですが、 他の OS (Windows) の TeXLive 2015 で試したが問題はない、 という報告もあり、どうやら TeXLive のバージョンの問題ではなく、 FreeBSD 固有の問題らしいことがわかってきました。
で、TeX をインストールしていない FreeBSD マシンがあったので、 そこに TeX (japanese/tex-ptex や print/texlive-full) を install, reinstall して色々試してみたのですが、 その上ではどうやら問題が起きません。 そこではたと気がついたのですが、問題が起きるマシンでは、 以下のようになっていました。
ということで、そのマシンの上で pdftex を含む print/tex-base-engines を make deinstall ; make install してみたら問題が起きなくなりました。 どうやら、portupgrade により TeXLive のある部分は更新されていたのに、 pdftex (tex-base-engines) がその更新から取り残されていたことが 原因だったようです。 platex のリンク元である /usr/local/bin/eptex も日付がだいぶ古いので、 japanese/tex-ptex も reinstall しておくといいのかもしれません。
最近また portupgrade -ac をしたのですが、 最後にこんなのが出て止まっていました。
uninitialized constant PkgDBTools::DBErrorpkg info を見ると、ruby が ruby25 に更新されていて、 そのため ruby に依存する portupgrade に問題が出てしまっているようです。
** Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ
....
/usr/local/lib/ruby/site_ruby/2.4/pkgtools/pkgtools.rb:487:
in `__system': Command failed [exit code 1]:
/usr/local/sbin/pkgdb -aFOQ (CommandFailedError)
from /usr/local/lib/ruby/site_ruby/2.4/pkgtools/pkgtools.rb: 510:in `__sudo'
from /usr/local/lib/ruby/site_ruby/2.4/pkgtools/pkgtools.rb: 516:in `xsudo'
from /usr/local/lib/ruby/site_ruby/2.4/pkgtools/pkgdb.rb: 1062:in `autofix!'
from /usr/local/lib/ruby/site_ruby/2.4/pkgtools/pkgdb.rb: 1058:in `autofix'
from /usr/local/sbin/portupgrade:519:in `block (2 levels) in main'
from /usr/local/sbin/portupgrade:855:in `block in main'
from /usr/local/lib/ruby/2.4/optparse.rb:1062:in `initialize'
from /usr/local/sbin/portupgrade:238:in `new'
from /usr/local/sbin/portupgrade:238:in `main'
from /usr/local/sbin/portupgrade:2380:in `<main>'
これに関しては、/usr/ports/UPDATING の 20190420 に解決法があり、 そこに書かれている通り、ruby のデフォルトを 2.5 に変え (2.4 に維持する方法も書かれています)、 ruby, portupgrade を更新することで問題は解消しました。
python も 20190410 にデフォルトが 2.7 から 3.6 に更新されたとありますので、 3.6 に上げる作業を行えば py27 と py36 の問題は解消するのかもしれませんが、 詳しい方法は UPDATING には書かれていないので、 とりあえずは様子見です。
portupgrade すると、py27 系のものと py36 系のものがぶつかって install に失敗したり、それが原因となって他に不具合を出すことが ままあります。 特にありがちなのは py-setuptools, py-sphinx, py-sqlite3 あたりの問題です。 最近、portupgrade -ac の際に、
** Duplicated origin - textproc/py-sphinx: py27-sphinx-1.6.5_2,1
py36-sphinx-1.6.5_2,1
** Run 'pkgdb -F' to interactively fix them.
pkgdb -F」すると
pkgdb -F not supported with PKGNG yet. Use 'pkg check' directly.
そのディレクトリに行って普通に make install すると、
どちらかのものが入れられてしまって、他方のものが入れられない、
ということもあります。今回は、どうやら py27-sphinx が途中で入り、
py27-certify が必要だったようなのですが (最終的には llvm80 用)、
security/py-certify でインストールしようとしても
py36 のものしか入らず、うまく行きませんでした。
調べると、py27 の方のものを入れるには、普通の make instal ではなく、
「make FLAVOR=py27 install」とするようです。
同様に databases/py-sqlite3, textproc/py-chardet も
py27 系のものが必要でした。
また、perl が 5.24 あたりのマシンで portupgrade すると、 shells/bash あたりでこけて、
pkg-static: Unable to access file
/usr/ports/print/texinfo/work/stage/usr/local/lib/texinfo/MiscXS.so:
No such file or directory
pkg-static: Unable to access file
/usr/ports/print/texinfo/work/stage/usr/local/lib/texinfo/Parsetexi.so:
No such file or directory
pkg-static: Unable to access file
/usr/ports/print/texinfo/work/stage/usr/local/share/texinfo/Texinfo/XS/parsetexi/Parsetexi.pm:
No such file or directory
*** Error code 74
「FreeBSD: その他のメモ (04/03 2019)」 の cargo に関する話の続報ですが、 別なマシンを FreeBSD 12 に更新して、portupgrade をしたのですが、 やはり cargo で firefox の compile にこけました。 手動で cargo を実行すると、以下のようになります。
% cargo
thread 'main' panicked at 'couldn't initialize
the libgit2 library: -1',
/usr/ports/lang/rust/work/rustc-1.33.0-src/vendor/libgit2-sys/lib.rs:
3027:9
note: Run with `RUST_BACKTRACE=1` environment variable
to display a backtrace.
どうも、cargo は参照するライブラリもそれなりに新しくしないと 問題が発生しやすいようですね。
HP Compaq dc7700 の OS を 少し前に 12.0 に更新し、portupgrade をしていたのですが、 どうも www/firefox が更新されませんでした。 cargo がコアダンプするのが原因のようでしたが、 よくわからないのでしばらく放っていました。
それが、昨日 portupgrade したらちゃんと www/firefox も更新されていたので、 cargo を調べたら cargo もコアダンプしないようになっていました。
実は cargo がコアダンプする問題は以前にもありました (「FreeBSD: インストールに関するメモ (02/08 2018)」) ので、 同じ原因かもしれません (すっかり忘れていました)。 ちなみに、現在うちの rust (cargo が含まれる) と firefox のバージョンは rust-1.33.0_1, firefox-66.0.2,1 です。
ports に関して 3 点程書きます。
/usr/ports/UPDATING にありますが、 graphics/jpeg のライブラリは今は古いらしく、 www/firefox のコンパイルでは途中で configure エラーになります。 graphics/jpeg-turbo に置き換えないといけないようで、 portupgrade なら
# portupgrade -f -o graphics/jpeg-turbo graphics/jpeg
次は、FreeBSD 11.1 (サバ太郎) 上の portupgrade の最中に起きた問題ですが、 まず 11.1 は今は古いのか、portsupgrade しようとすると 以下のようなものが表示されて中断してしまいます。
Ports Collection support for your FreeBSD version has ended,
and no ports are guaranteed to build on this system. Please
upgrade to a supported release.
No support will be provided if you silence this message by
defining ALLOW_UNSUPPORTED_SYSTEM.
setenv ALLOW_UNSUPPORTED_SYSTEM 1」(csh なので)
して portupgrade を再開しました。
また、この 11.1 では math/mpfr のパッチ当てに失敗するようで、
! math/mpfr (mpfr-4.0.1_1) (patch error)
===> Patching for mpfr-4.0.1_2
===> Applying distribution patches for mpfr-4.0.1_2
No such line 4470 in input file, ignoring
3 out of 4 hunks failed--saving rejects to doc/mpfr.info.rej
math/mpfr の Makefile に以下の 2 行を入れて patch でなく gpatch を使うようにすることで問題は解消しました。
PATCH_DEPENDS= gpatch:devel/patch
PATCH= ${LOCALBASE}/bin/gpatch
ある FreeBSD 11.2 のマシンで portupgrade したところ、
! print/tex-luatex (tex-luatex-0.80.0_9) (linker error)
! print/tex-xetex (tex-xetex-0.99992_19) (linker error)
/usr/bin/ld: Dwarf Error: found dwarf version '4',
this reader only handles version 2 information.
......
undefined reference to `std::__throw_length_error(char const*)'
c++: error: linker command failed with exit code 1
(use -v to see invocation)
*** Error code 1
Dwarf の問題は、ld の問題のようで、 /usr/bin/ld でなく /usr/local/bin/ld を使うようにすればよい、 という情報もあったので、/usr/bin/ld など (ar, ranlib も) を一旦名前を変えてやってみたら、 Dwarf のエラーはなくなったのですが、 undefined reference は相変わらず出ています。
たまたま別の FreeBSD 11.2 のマシンで print/tex-luatex が問題なく更新できていたものがあり、 それとログを比較することでわかりましたが、
ということで、うまくいってない方で、 一旦シンボリックリンクの /usr/local/bin/{gcc,g++} を消してみたら、 問題なくコンパイルできました。
いつ頃からか、www/firefox が www/firefox-i18n のアドオンでは メニューの日本語化ができなくなってしまいました。 www/firefox がうちの環境では重くなっていたこともあり、 しばらく www/waterfox を使っていたのですが、 最近 ports から www/waterfox が削除されてしまいました。 よってまた www/firefox を使うようにしてみました。
最初、gtk3+-wayland がどうとかでてきて、 うまくコンパイルできなくなっていましたが、 それは x11-toolkits/gtk30 を wayland を support するように作り直して 再 install することで解決しました。
メニューの日本語化は相変わらず www/firefox-i18n ではうまくいかなかったのですが、 以下のサイトを参考に OS によらない手順で作業をしたらうまくいきました。
「スペルチェック辞書と言語パックのページ」で Japanese Language Pack をインストールし、about:config で「intl.locale.requested」の値を ja (文字列) に設定して firefox を再起動するとうまくいきました。
以前は about:config の値は「general.useragent.locale」だったのですが、 どうやら変わったようです。 ただ、やはり以前の waterfox に比べると少し重いので、 今度は軽くする方法も知りたいと思います。
「その他のメモ (10/28 2015)」
にも書きましたが、FreeBSD の ports に含まれている dvipdfmx では
日本の B4 サイズ (jisb4) の指定ができません。
xdvi でもそれは同じで、
単に b4 を「-paper b4」と指定すると、
それは ISO の b4 (250x353mm) と認識され、
日本の b4 (257x364mm) とは少し違うサイズになってしまいます。
これらは、FreeBSD の libpaper (print/libpaper)
が jisb4 に対応していないためです。
また、xdvi のサイズ指定は、b4 など以外にも、
元々「-paper [w]x[h]」
のように直接サイズを指定できるようになっているのですが、
FreeBSD では libpaper 用のパッチが当たっているせいで、
その直接指定が無効になってしまっています。
そこで、この 2 つの問題を解消するパッチを作ってみました。
前者は print/libpaper に関するパッチです。
/usr/ports/print/libpaper/files にこのパッチをコピーして、
「make ; make deinstall ; make install」
すれば jisb4 などをサポートする libpaper ができます。
これで、xdvi や dvipdfmx でも jisb4 のサイズ指定ができるようになります。
なお、ISO の b4 は、今まで通りの「b4」以外に、
「isob4」としても指定できるようにしてあります。
後者は print/tex-xdvik に関するパッチです。 直接のサイズ指定を生かすためのものですが、 これは /usr/ports/print/tex-xdvik/files にある patch-texk-xdvik-dvi-init.c に置き換わるものなので、 以下のようにして使用します。
# cd /usr/ports/print/tex-xdvik
# mv files/patch-texk-xdvik-dvi-init.c .
# cp /hoge/fuga/patch-texk-xdvik-dvi-init-3.c files
# make
# make deinstall
# make install
-paper 250mmx353mm」
のような直接指定が使えるようになります。
最近、ThinkPad X40 で portupgrade -ac を実行すると、よく
pkg-static: vulnxml parsing error: not well-formed (invalid token)
pkg-static: cannot process vulnxml
pkg audit -F」するといいらしいというのを見ました。
しかしやってみると、その際もほぼ同じメッセージがでて、
何も更新されません。
それが、以下の情報を見て、 もしや vuln.xml 自体が壊れているのでは、 と確認したら案の定 /var/db/pkg/vuln.xml が壊れていることに気がつきました。
/var/db/pkg/vuln.xml が、/usr/ports/security/vuxml/vuln.xml よりもサイズがかなり小さく、 しかも中身は何かを取得したものではなく、 ネットワーク接続時エラーの html のようなものになっていました。 多分これをネット上から取得して更新する際に、 接続に失敗してこのようになったのだと思います。
とりあえず、上にあるように /usr/ports/security/vuxml のものを cp して (一応その前に portsnap fetch update はやってある)、 portupgrade することで無事問題は解消しました。
最近、portupgrade -a を実行したら、multimedia/mplayer の更新に失敗しました。 良くみると、こんな感じで落ちています。
libmpcodecs/vd_ffmpeg.o: In function `set_format_params':どうやら multimedia/ffmpeg によってインストールされるライブラリ (libavcodec) に av_alloc_vdpaucontext() という関数が入っていないようで、 むしろ multimedia/ffmpeg の ports の失敗のようです。
libmpcodecs/vd_ffmpeg.c:(.text+0x1734): undefined reference to `av_alloc_vdpaucontext'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [Makefile:747: mplayer] Error 1
調べてみると、ffmpeg は 2.2.8_9 から 3.2.2_4 に更新されたのですが、 その際のデフォルトのオプションが変わっていて、 make config の VDPAU というオプションが、 multimedia/ffmpeg の新しい Makefile ではデフォルトオプションになっているのですが、 過去に install した際の ffmpeg のオプションを引きずるためか、 portupdate ではそれがオプションとして設定されず、 そのため libavcodec に上記の関数が入らないようでした。
結局、multimedia/ffmpeg で make config し直して、 デフォルトで設定されるべき VDPAU (と OPTIMIZED_CFLAGS, V4L, VAAPI) を追加で設定して make reinstall したら、 今度はめでたく multimedia/mplayer がインストールできました。
(cf. 「X に関するメモ (09/22 2017)」)
「その他のメモ (12/16 2016)」 に書いた ruby のインストールの問題ですが、 以下の情報が更新されていました。
結論からいうと、ruby の問題ではなく pkg の問題のようです。 pkg-1.9.4_1 に上げるといいらしいので、 portsnap update して ports-mgmt/pkg で make reinstall したら、 今度は lang/ruby22 も問題なくインストールされました。
2 点ほど書いておきます。
下 (「その他のメモ (12/16 2016)」) に書いた、xdvik の EPS ファイルが重なる件ですが、 予想通り print/ghostscript9* を print/ghostscript7-x11 へ入れ変えても問題は解決しました。
そして、gs7 でうまくいくということは、gs の呼び出しコマンドが現在の gs に合ってないのかと思い、xdvik のソースを見てみたところ、 すでにこの問題への対応が入っているようでした。 ソースアーカイブ内の CHANGES (texk/xdvik/CHANGES) に以下のように書かれています。
* 22.77.2 (2003/10/18):ソースでは texk/xdvik/events.c あたりで対応しているようですが、 どうやらそれは gsAlpha リソースが有効な場合にしか機能しないようです。 よって、.gsAlpha のリソースを /usr/local/share/texmf-dist/dvips/xdvi/XDvi か ~/.Xdefaults あたりで設定するか、 または -gsalpha オプションで xdvi を実行すれば、 gs9 でも EPS が重ならないように表示できるようです。
....
Used another workaround for the Ghostscript `alpha' driver problem with not erasing previous images: Call `erasepage' explicitly for pages with PS graphics (#633420; many thanks to John Bowman for providing a patch).
うちは -gsalpha で対応していますが、 gs9 で 問題なく表示できるようになりました。 上にあるように、xdvi 22.77.2 からはそれで対処できるようです。
「インストールに関するメモ (05/07 2014)」 で報告したように、EPSON LP-S230DN の PostScript 機能で印刷をしている FreeBSD マシンがあるのですが、 日本語 PostScript フォントを内蔵していないので、 現在は一旦 ps2ps (gs) でラスタライズして、日本語フォントを IPA フォントでビットマップ化してから印刷しています。
ところが、私はテキストファイルは a2ps を使ったりして 4up して印刷することが多いのですが、 IPA 明朝がやや細めのせいか、 明朝体の漢字の細い横線などが欠けることがあります。 1 ページに数個くらいなので、読めなくはないのですが、 それをちょっと太くできないかと少し調べてみました。
ports には、japanese/font-takao, japanese/font-mona-ipa など、 いくつか明朝体の TrueType フォントがあるようなのですが、 いずれも IPA フォントがベースで結果は変わりません。 ウェイトの変更できるフォントは市販のものしかないのかなと思ったのですが、 以下にフリーでいくつかのウェイトを持つフォントを見つけました。 IPA 明朝フォントがベースらしく、デザインもほぼ変わりません。
これに含まれる「あおぞら明朝 Regular」を Ryumin-Light に割り当てることで、 無事 4up でも漢字が欠けて印刷されることはなくなりました。 なお、ゴシック体は特に問題はないので IPA のものをそのまま使っています。
また、gs9 の日本語フォントの設定は、現在は
/usr/local/share/ghostscript/9.16/Resource/Init/cidfmap
になっています。絶対パスで TrueType フォントを指定してみたのですが、
うまく認識されません。
gs -h を見るといくつかの検索パスが固定になっているようなので、
その一つである
/usr/local/share/ghostscript/fonts/
にフォントファイルのリンクを貼り、
そのフォントファイル名を指定しています。
ports もそうやっているようです。
2 点ほど書いておきます。
まず、ports で入れた xdvik で、EPS を取り込んだ dvi ファイルを見ると、 その EPS 画像がおかしくなります。 具体的には、他のページの、同じ位置にある EPS 画像が重なって表示されてしまいます。 例えば、1 ページ目と 2 ページ目の上部に EPS 画像が includegraphics されている場合、2 ページ目の EPS 画像を見ると 1 ページ目のものと重なって表示されます。
xdvik と ghostscript のバージョンで起きたり起きなかったりする、 といった情報もあるようなので調べてみると、 今使用しているもの (問題が起きているもの) は、 xdvik は version 22.87 (pkg だと tex-xdvik-22.87_4)、 gs は gs 9.16 (pkg だと ghostscript9-agpl-base-9.16_5, ghostscript9-agpl-x11-9.16_2) です。
実は日本語処理に関しては gs 7 の方が良かったので、 gs-7.07 も手動で入れてあります。 path の優先順位をそっちにあげて、 内部で gs-7.07 を使うようにしたら上記の問題は起きません。
よって、もしかしたら print/ghostscript7-x11 を使えば問題は起きないのかもしれませんが、 それはまだやっていません。
最近 ThinkPad X40 で portsnap をやって portupgrade をやったのですが、 途中で C-C で切ったりしたためか、lang/ruby21, lang/ruby22 のインストール (upgrade) に失敗していました。 ログを見ると、こんなものがでてこけています。
Installing ruby21-2.1.10_1,1...ruby22 もほぼ同様です。 ついでに lang/ruby23 も make install してみましたが、 全く似た感じでコケます。 まあ ruby はいらないかなと思って make deinstall したら、 portupgrade が ruby を使っているのを忘れていました。 それで ruby も install できないし、portupgrade もできないし、 という状況になっています。
pkg-static: Fail to create temporary file: /usr/local/share/ri/2.1/system/XMLRPC/Client/.new-c.ri.kJiUSBQFrYpH: File exists
調べてみると、私だけではないようで、FreeBSD Bugzilla に載ってました。
まだ解決はしていないようなので、しばらくは様子見です。
最近、FreeBSD 10.3 (p8) で portupgrade したら、print/tex-luatex のインストールにこけて、
! print/tex-luatex (tex-luatex-0.80.0_4) (install error)などと出ます。 ログを見ると、fmtutil の作業でエラーがでていて、
Shared object "libpoppler.so.58" not found, required by "luatex"などと言っているようです。 実際、/usr/local/lib/libpoppler.so.58 はなく、 /usr/local/lib/libpoppler.so.63 になっています。
これは、print/tex-luatex の更新の前に libpoppler が更新され、 そしてそれを引くような luatex (と luajittex) が print/tex-luatex の作業ディレクトリ (print/tex-luatex/work の下) に一旦作られるのですが、 print/tex-luatex の make 作業で呼びだされる fmtutil が、 作業ディレクトリにせっかく作った luatex (と luajittex) ではなく、 どうやら /usr/local/bin にある luatex (と luajittex) を呼び出してしまうため、その luatex が古い libpoppler が引けなくて (既になくなっている)、 luatex の make の一連の作業の途中 (フォーマットファイルの作成) でこけてしまう、ということになっているようです。
本来は、フォーマットファイルを作成する fmtutil が、 ちゃんと work 以下の新しい luatex (と luajittex) を見るように Makefile などを修正すべきなのですが、面倒くさいので、 とりあえずその新しい luatex (と luajittex) を /usr/local/bin に一時的にコピーして、print/tex-luatex を作り直せば、 とりあえずはインストールできるようです。
cd /usr/ports/print/tex-luatexあまりいい対応ではありませんが、 ports が改良されるまでのその場しのぎとしてあげておきます。
cp work/stage/usr/local/bin/luatex /usr/local/bin
cp work/stage/usr/local/bin/luajittex /usr/local/bin
make clean
make install
(cf. 「X に関するメモ (09/22 2017)」)
「その他のメモ (11/12 2015)」 に書いた kterm の色の問題ですが、 どうやら kterm のデフォルトのリソースファイル /usr/local/lib/X11/app-defaults/KTerm が 読めなかったためだとわかりました。
私は、自前でインストールした X クライアントのリソースファイルを 適当なところに置いているので、そういうものの置き先を環境変数 XFILESEARCHPATH に X 起動時に指定しているのですが、 その中のデフォルトのシステムのリソースファイルの置き場所の指定が、 古い設定のまま (/usr/X11R6/lib/X11/app-defaults 等) になっていたために、 ports で入れた kterm のデフォルトリソースファイルが読めなくなっていました。 よって、直接 FreeBSD-10.2 の問題ではありませんでした。 失礼しました。
FreeBSD-10.2 で ports から japanese/kterm を入れたのですが、 color パッチは当たっているようなのですが色が出ません。 -fg, -bg で色を変えられるのですが、 エスケープシーケンスの色指定を受け付けてくれません。 以前は色がちゃんとでていました。 TERM を kterm-color にしてみたりしたのですがだめです。
実際、シェルスクリプトで、
printf "\033[42m\033\m"
echo "takeno"
printf "\033[49m\033\m"
(cf. 「その他のメモ (11/17 2015)」)
FreeBSD-10.2 で ports から japanese/tex-ptex, print/tex-dvipdfmx 等を入れたのですが、 従来「dvipdfmx -p jisb4」のようにして JIS B 系列の紙のサイズを 指定できていたのですが、 今の dvipdfmx ではそれが指定できません。 「dvipdfmx --showpaper」でわかります。
いつからできなくなったのかはよくわかりませんが、 以前は ports でなく自前で ptetex 等を入れていたので、 ports の TeX では元からだめだったかもしれません。
なお、dvipdfmx で JIS B 系列の紙指定ができないのは、 FreeBSD の libpaper (print/libpaper; libpaper-1.1.24+nmu4) が JIS B 系列をサポートしていないからのようです。
とりあえず、直接数値を指定して、「dvipdfmx -p 257mm,364mm」 とすればまあなんとかなります。
(cf. 「その他のメモ (09/12 2018)」)
うちだけの問題かもしれませんが、ここに上げておきます。 FreeBSD-10.2 で ports から japanese/tgif を入れたのですが、 それだけではうまく日本語化されず、立ち上げると 「Tgif.MenuFontSet で指定されたフォントセットを読み込めません:」 のようなメッセージが表示され、文字化けしたメニュー等が表示されてしまいます。 日本語入力もうまくいきませんでした。
japanese/tgif は日本語リソース定義ファイルも入れるのですが、 そこで使用しているリソース名は、 メニューフォントでは以下のような物を使っています:
Tgif.MenuFontSet:
-*-helvetica-bold-r-normal--12-*-*-*-*-*-*-*,
-ipa-uigothic-medium-r-*--12-*-*-*-c-*-jisx0208.1983-*
Tgif.MsgFontSet:
-*-helvetica-medium-r-normal--12-*-*-*-*-*-*-*,
-ipa-uigothic-medium-r-*--12-*-*-*-c-*-jisx0208.1983-*
Tgif.BoldMsgFontSet:
-*-helvetica-bold-r-normal--12-*-*-*-*-*-*-*,
-ipa-uigothic-bold-r-*--12-*-*-*-c-*-jisx0208.1983-*
他の日本語フォントも入れた上で、 私は現在は以下のようなリソース設定を使用しています:
Tgif.HKUShowFontChar: \244\244
Tgif.GBShowFontChar: \271\372
Tgif.RyuminShowFontChar: \244\242
Tgif.GothicBBBShowFontChar: \244\316
Tgif.UseNKF: true
Tgif.CopyAndPasteJIS: true
Tgif.PreeditType: root
Tgif.Lang: ja_JP.eucJP
Tgif.MenuFontSet: -*-fixed-medium-r-*--14-*-*-*-*-*-*-*
Tgif.BoldMsgFontSet: -*-fixed-medium-r-*--14-*-*-*-*-*-*-*
Tgif.MsgFontSet: -*-fixed-medium-r-*--14-*-*-*-*-*-*-*
Tgif.BoldMsgFontDoubleByte: true
Tgif.DoubleByteInputMethod: xim
Tgif.FontSizes: 8 10 11 12 14 16 17 18 20 24 25 34
Tgif.SquareDoubleByteFonts: \n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,H,Ryumin-Light-EUC-H\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,H,Ryumin-Light-EUC-H\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,H,Ryumin-Light-EUC-H\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,H,Ryumin-Light-EUC-H\n\
\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,H,GothicBBB-Medium-EUC-H\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,H,GothicBBB-Medium-EUC-H\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,H,GothicBBB-Medium-EUC-H\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,H,GothicBBB-Medium-EUC-H\n\
\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,V,Ryumin-Light-EUC-V\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,V,Ryumin-Light-EUC-V\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,V,Ryumin-Light-EUC-V\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,V,Ryumin-Light-EUC-V\n\
\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,V,GothicBBB-Medium-EUC-V\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,V,GothicBBB-Medium-EUC-V\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,V,GothicBBB-Medium-EUC-V\n\
-*-fixed-medium-r-*--%d-*-*-*-*-*-jisx0208.1983-*,V,GothicBBB-Medium-EUC-V
元の設定よりはフォントの見栄えのバリエーションがないかもしれませんが、
これなら一応メニュー等も日本語で出ていますし、
日本語入力も使えています。
追記ですが、 「インストールに関するメモ (04/19 2013)」 にも、ほぼ同じ問題に関する話 (別の対処) が書いてありました。
FMV-6333T7, および Toshiba Dynabook (Satellite J40 140C/5, Intel 852GM chipset) (「インストールに関するメモ (08/21 2012)」, 「インストールに関するメモ (04/19 2013)」 参照) で 10.2-RELEASE にバージョンアップした際に、 いくつかのソフトを入れているときに気がついたことを 2 つ 書いておきます。
私はいまだに japanese/mh などを使っていますが、 そのインストール時に以下のようなメッセージがでました:
/usr/bin/strip: '/usr/ports/japanese/mh/work/stage/usr/local/bin/*':
No such file *** Error code 1
Stop.
make[2]: stopped in /usr/ports/japanese/mh
*** Error code 1
で、この # の出所ですが、実は /etc/services から「110/tcp」を grep して切り出しているもののようです。 それが本来なら "pop3" のようになるのですが、 うちは /etc/services の 110/tcp の行をコメントアウトしてあったので それで "#pop3" となってしまった、というわけです。 もちろん、この /etc/services の設定は japanese/mh を入れてからやるべきものだったのですが、 /etc/ の設定を先に、ということで前の設定をそのままコピーしたために 起きた問題でした。 多分よそではあまり起きない問題ではないかと思いますが、 一応起こりうる問題として情報を上げておきます。
tex を japanese/tex-ptex (texlive) で一式入れて、print/tex-xdvik, print/tex-dvipsk, print/tex-dvipdfmx を入れたのですが、 eps を includegraphics した LaTeX ファイルを dvipdfmx すると 「texlua: No such file or directory」などと言われます。
なんのことかと思って調べてみると、dvipdfmx の設定ファイルである /usr/local/share/texmf-dist/dvipdfmx/dvipdfmx.cfg に、 内部で eps の処理用に呼び出す gs の設定が書かれているのですが、 gs を直接呼び出す代わりに rungs (/usr/local/bin/rungs) なるものを呼びだす設定になっていて、 その rungs が texlua を呼び出しているようです。
よって、dvipdfmx.cfg に書かれている rungs を gs に書き直すか、 または print/tex-luatex をインストールすればいいようです。
libgd は ports でも入れられるのですが (graphics/gd)、 それは文字の回転や日本語文字にうまく対応してなかったりするので、 自前でコンパイルをしました。 しかし、multimedia/libvpx がインストールされていると、 libgd-2.1.1 も libvpx つきでコンパイルしようとしますが、 妙なコンパイルエラーがでます。
error: use of undeclared identifier 'IMG_FMT_I420'
gnuplot も自前でコンパイルをしてますが、その gnuplot 用に x11-toolkits/wxgtk28 を入れています。 しかし、この x11-toolkits/wxgtk28 は、 本来 wxgtk に付属の環境提示用スクリプトは wx-config という名前で、 gnuplot の configure でもそれを使おうとするのですが、 x11-toolkits/wxgtk28 はそれを wxgtk2-2.8-config という名前に変えてインストールしてしまうので、 gnuplot の configure で wxGtk の検出に失敗してしまいます。
一つの回避策は、wx-config へのリンクを貼ることですが、 gnuplot の configure スクリプトでは、wx-config の検出の際に 先に WX_CONFIG という環境変数を参照しています (説明はありません)。よって、リンクを貼らなくても、 「WX_CONFIG=`which wxgtk2-2.8-config`」としておけば 正しく wxGtk を参照することができます。
今の FreeBSD (FreeBSD/i386) は、 freebsd-update を使ってセキュリティアップデートが行えますが、 プライベートアドレスにあるノートパソコン (FreeBSD) から HTTP proxy を使って freebsd-update を行うと、 大きいファイルの fetch がどうもうまくいきませんでした。
具体的には、以下で報告されているように、 「gunzip: (stdin): unexpected end of file」のエラーが出ます。
プライベートアドレスからグローバルアドレスへのゲートウェイに 使っているパソコン (FreeBSD) では、 普段は delegate を使って HTTP proxy にしているのですが、 どうやらそれが原因のようで、 「その他のメモ (06/13 2012)」 と似た状況です。 delegate の設定を調整してうまくいくようにできるのかもしれませんが、 前と同じように delegate とは別のサーバを使ってみることにしました。
「その他のメモ (06/13 2012)」 と同じ plugdaemon を使ってもできたかもしれませんが、 今回はシンプルなプロキシサーバを、と思って /usr/ports/net/simpleproxy を試してみました。結論から言えば、 これで freebsd-update の fetch がうまくいくようになりました。 作業手順は以下の通りです。
これだけです。 簡単すぎて、もしかしたらセキュリティ的に多少弱いかもしれませんが、 とりあえずはこれでいけます。
先日、プライベートアドレスにあるノートパソコン (FreeBSD) から 初めて cvsup を使ってみました。 プライベートアドレスからグローバルアドレスへのゲートウェイに 使っているパソコン (FreeBSD) は、 普段は delegate を使って HTTP proxy にしているのですが、 cvsup はそれは通らないようです。 以下の cvsup の FAQ には、inetd と plug-gw なるものを使って ポート転送を行う例が書いてあるのですが、 ちょっと面倒です。
他にも、SSH を使って転送する方法などが見つかりましたが、 もっと簡単なものはないかと探したら、 /usr/ports/net/plugdaemon なるものがあり、 これを利用してみました。 これに関する情報はあまりないようですので、ここに紹介しておきます。
/usr/local/sbin/plug (plugdaemon) の使用法は以下の通りです。
これだとゲートウェイでの設定は、 テスト用の telnet を通す位でほとんどいらないので、 だいぶ楽でした。
(cf. 「その他のメモ (10/22 2014)」)
そういえば、FreeBSD に /usr/ports/japanese/xpdf で xpdf を入れた場合、 これだけでは日本語がちゃんと表示されません。 デフォルトの日本語用の設定である /usr/local/share/xpdf/japanese/dot.xpdfrc に書かれている cMapDir が、デフォルトでは
cMapDir Adobe-Japan1 /usr/local/share/fonts/adobe-cmaps
cMapDir Adobe-Japan1 /usr/local/share/fonts/adobe-cmaps/aj16/CMap
最近、新しく FreeBSD (8.1) をインストールして、 それを使えるようにしようと思っているのですが、 emacs は ports では 21 以降のものばかりのようで、 多分この マシン では非力かな、 と思ったので、昔やったのを思い出して emacs-20.7 のコンパイルを手動で行いました。
一箇所 src/emacs.c の sys_nerr を削除する必要がありましたが、 それ以外はほぼすんなりコンパイルできました。 しかし、X は lucid 版だったのですが、X で立ち上げようとすると
Fatal error (11).Segmentation fault (core dumped)などと出て立ち上がりません (emacs -nw は問題ない)。
検索してみると、色々な OS 上、色々な emacs のバージョンで同じ問題が起きているらしく、 多くの情報が見つかりましたが、その中で以下のようなものがありました。
この最後の情報を元に、
gmake 'LDFLAGS=-L/usr/local/lib -znocombreloc'とすると確かに落ちないものができました。 ただ、上のようにすると警告もだいぶでます。多分、
gmake 'STARTFLAGS=-znocombreloc'とするか、src/s/freebsd.h に
#define LD_SWITH_SYSTEM_TEMACS -znocombreloc(-Xlinker とかがいるかも) のようにする方が真っ当だと思います (未確認)。
昨年の 11 月末頃に学生用の Solaris 環境に新しいプリンタを購入したので、 以前そちらで使用していた PostScript プリンタ Ricoh IPSiO NX620N (正確に言うと、オプションの PostScript3 モジュールを追加して PostScript プリンタとして使用) を、 こちらのプライベートアドレス内のネットワークプリンタとして利用しています。 設定は難しくはありませんでした。
IP アドレス、サブネットマスク、 デフォルトゲートウェイ、アクセスコントロール、 アクセスコントロールマスク等を設定する (「アクセスコントロール」は、 プリンタを使えるアドレスを制限するためのもの)
以下のような行を追加:
ipsio|private network printer:\([IPaddress] の部分は上で設定した IP アドレスを書く)
:sh:\
:rm=[IPaddress]:sd=/usr/tmp/lpd2:mx#0:\
:lf=/var/log/lpipsio.log
# mkdir /usr/tmp/lpd2(/usr/tmp/lpd2 は /etc/printcap の sd で設定したディレクトリ、 /var/log/lpipsio.log は /etc/printcap の lf で設定したファイル)
# chown daemon:daemon /usr/tmp/lpd2
# touch /var/log/lpipsio.log
# kill -HUP [lpd-pid]([lpd-pid] は ps -ax で表示される /usr/sbin/lpd のプロセス ID)
これで a2ps の出力を lpr -Pipsio に直接流したところ、 ちゃんと印刷されました。 LIPS III のプリンタ (Canon LBP-730) のトナーに少し傷がついて、 印刷が汚れだしていたところだったので助かりましたし、 LBP-730 に比べると印字速度がかなり早いので助かっています。
ただ、一度同じプライベートアドレス内の MS-Windows XP マシンから そのプリンタに印刷した直後、 FreeBSD マシンから lpr したら印刷されない状態になったときがありました。 lpc では以下のように表示されました。
queuing is enabled何かの加減で waiting の状態になっているようです。とりあえず、 プリンタの電源を一度切って立ち上げ直したらうまく印刷されました。
printing is enabled
7 entries in spool area
waiting for [IPaddress] to come up
VZ-6000 の FreeBSD のバージョンを 4.11 から 7.0 に上げたのですが、 それに伴って気がついたことをいくつか上げます。
ftp://ftp3.jp.freebsd.org/pub/FreeBSD/releases/i386のように書くといいようです。
FreeBSD-4.11 の上で新しい gdlib (gd-2.0.35)、GD.pm (GD-2.35) をコンパイルしたときの問題について紹介します。
Solaris 9 の上では特に問題なかったので、 FreeBSD でも同じようにコンパイルしたのですが、 gdlib をインストールして、GD.pm の test をやったときに問題がでました。
% make test
...
t/GD..........Can't load './blib/arch/auto/GD/GD.so' for module GD:
./blib/arch/auto/GD/GD.so: Undefined symbol "pthread_mutex_lock"
at /XXX/lib/perl5/5.8.6/i386-freebsd/DynaLoader.pm line 230.
at t/GD.t line 14
Compilation failed in require at t/GD.t line 14.
BEGIN failed--compilation aborted at t/GD.t line 14.
...
のように言われます。
この pthread_mutex_lock なんですが、gdlib では gdhelpers.h 内で以下のように定義されています:
#ifdef WIN32
/* 2.0.18: must include windows.h to get CRITICAL_SECTION. */
...
#else
#ifdef HAVE_PTHREAD
#include <pthread.h>
#define gdMutexDeclare(x) pthread_mutex_t x
#define gdMutexSetup(x) pthread_mutex_init(&x, 0)
#define gdMutexShutdown(x) pthread_mutex_destroy(&x)
#define gdMutexLock(x) pthread_mutex_lock(&x)
#define gdMutexUnlock(x) pthread_mutex_unlock(&x)
#else
...
HAVE_PTHREAD は configure 時に確かに -pthread が使えると認識されていて
config.h 内で 1 に定義されています。
そして、Makefile では以下のようになっています:
PTHREAD_CC = gcc
PTHREAD_CFLAGS = -D_THREAD_SAFE -pthread
PTHREAD_LIBS =
ということで、取るべき道は、次のいずれかだろうと考えました。
もちろん、
それに、この pthread_mutex_*() が含まれるライブラリですが、 "libpthread" のようなものはなく、 どうやら /usr/lib/libc_r.a と /usr/X11R6/lib/libX11.a 辺りに pthread_mutex_*() が含まれているようでした。 libX11 を X の関係ないプログラムにリンクするのも何ですので、 まず libc_r.a を試してみました。
以前 FreeBSD 5.4 の場合に、やはり同様の問題で -lc_r で逃げたことがある (「その他のメモ (09/23 2006)」 参照) のですが、 一応 gdlib に fontsizetest.c なるテストプログラムが付属しているので、 これを -lc_r をつけてコンパイルしてみました。 すると、何やら妙な warning がでました:
/usr/lib/libc.so: WARNING! setkey(3) not present in the system!
/usr/lib/libc.so: warning: this program uses gets(), which is unsafe.
/usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider
using mkstemp()
...
libc_r は libc と相性でも悪いのでしょうか。
それに Makefile をよく見てみると、 PTHREAD_* という定義はされているのですが、 しかし実際にはどこにも使われていないようで "PTHREAD_LIB = -lc_r" としても何も変わりません。 となると Makefile の方でも、 実際には PTHREAD の対応はしていないということになりますから、 使わない方がいいのかもしれません。
ということで、結局 config.h を直接書き換えて HAVE_PTHREAD の行をコメントアウトして gdlib を作り直すことにしました。 これも、最初は Makefile の CFLAGS に -UHAVE_PTHREAD を入れてみたのですが、config.h を書き直さないとだめなようでした。 とりあえずこれで、GD.pm の make test も問題なく通るようになりました。
CVS 版 gnuplot の wxt terminal のテストをするために、 VZ-3000 の FreeBSD 5.4 (X.Org 6.8.2) に 新しい gtk+-2.8.20, glib-2.8.6, cairo-1.0.2, pango-1.10.4 を手動で入れて (gnuplot-current の wxt terminal は cairo-0.9.0 以上、pango-1.10.3 以上 を要求するので、ports のものだと間に合いません)、 wxWidget (wxGTK) 2.6.3 をインストールしてコンパイルしたのですが、 実行時に一瞬ウィンドウは立ち上がるのですが、 すぐに segmentation fault で core dump してしまいました。
gdb で見てみると、
#0 0x28fa131b in pthread_testcancel () from /usr/lib/libpthread.so.1と出ています。 pthread は libgthread-2.0.so が必要としているようですが、 gnuplot の make 時に gcc に -pthread オプションが使用されて それがリンクされているようでした。 その -pthread オプションを man gcc で調べてみると、
FreeBSD SPECIFIC OPTIONS
-pthread
Link a user-threaded process against libc_r instead of libc.
と書かれています。
しかし ldd で調べてみると libc_r は引いていないみたいなので、
Makefile の "-pthread" を "-pthread -lc_r" と
書き変えてみたところ、
とりあえず落ちないものが作成されました。
ただし、これが正しい対処なのかどうなのかは、まるでわかりません。
いくつかの FreeBSD のマシンでは /stand/sysinstall で package ソフトを インストールすることもあり、先日それをやったのですが、 その際ダウンロードサイトを単純にリストの一覧の中の "ftp3.jp.freebsd.org" から選んだのですが、 そうすると、(http プロクシ経由のためか) 1 つのパッケージをダウンロードする度に ftp を接続し直していて、 しかも、ディレクトリを
pub/FreeBSD/5.4-RELEASEのように探していって、 正解の pub/FreeBSD/releases/i386/5.4-RELEASE にたどりつくまでに だいぶ時間がかかるので (各パッケージ毎にこれが起こる)、 package の因果関係まで含めるといくつかのソフトをインストールするのに かなり時間 (と無駄なネットワークアクセス) がかかってしまいます。
pub/FreeBSD/snapshot/5.4-RELEASE
....
よってあらかじめ接続サイトのディレクトリを確認しておいた上で、 「リストにない ftp サイトを指定」のところで直接
ftp://ftp3.jp.freebsd.org/pub/FreeBSD/releases/i386のように指定する方がいいようです。
PC9821Xs の HD を交換する際に、 FreeBSD 5.5-RELEASE (pc98) をインストールしようと思ったのですが、 フロッピーの読み込みと、デーモン君の画面まではいくのですが、 その先に進もうとしたらリセットがかかってしまい、 結局うまくインストールできませんでした。 よって、FreeBSD (98) 4.11R-Rev01 をインストールしておきました。
現在、ノートパソコン は プライベートアドレスでメインで使用している PC (FreeBSD) につないであって、 FreeBSD と MS-Windows XP が入っているのですが、 たまに Word や Excel のファイル (たいていはメールの添付ファイル) を印刷しなければいけないときに 以下のような作業に使っていました。
この手順は面倒なので、 ftp の手順等を多少バッチ処理化したりはしていたのですが、 ノート PC の MS-Windows XP からメインの PC のプリンタに 直接印刷できることがわかり、これで少しは楽になりました。 設定はそう面倒ではありませんでした (以下、メインの PC のホストを仮に freebsd, ノート PC の MS-Windows 側を winxp とします)。
これの後で、freebsd 側の lpd を -W をつけて再立ち上げしたら、 ちゃんと winxp 側から印刷できるようになりました (実際には多少試行錯誤を繰り返しました)。
卒研で必要になったこともあり、PC9821Xp を復活させて、 OS も FreeBSD(98) 4.11R に入れ替えました。 X はあいかわらず FreeBSD 3.X 用の XFree86(98)-3.3.6 を使いましたが、 最近の FreeBSD パッケージは XFree86-4.X のライブラリに依存しているので たいていだめです。 98 で 4.X のサーバは動かないんでしょうか。
「その他のメモ (2003/07/10)」, 「その他のメモ (2003/07/11)」 に書いたスキャナの件ですが、現在はそれを使っているマシンの OS を FreeBSD 4.7 にしたため (以前は FreeBSD 2.2.8)、 sane-backends-1.0.16 をコンパイルし直して /dev/pass2 を指定して で使えるようになりました。 sane-frontends や xsane はまだ入れていませんが、 取りあえず scanimage が使えるのでこれでしばらくは良しとします。
なお、このマシンには FreeBSD 2.2.8 時代にインストールしたソフトが たくさん入っているのですが、新しいソフトをコンパイルすると、 それが必要とする shared library が a.out 形式でコンパイルされていて 使えず、それらをまた全て再コンパイルしてからでないと インストールできなくなっていて、マシン速度が遅いこともあって (Intel i486-66MHz (^^;)) 結構大変です。
以前学生に FMV-5166 に FreeBSD 4.9 をインストールしてもらったのですが (cf. 「その他のメモ (09/10 2004)」)、 PCI 用のイーサネットボード (1000BASE-T) Buffalo LGY-PCI-GT を差したら 認識してくれませんでした。
情報をいくつか検索してみたのですが、FreeBSD 4.X 系列では 4.10 でもだめ、 5.2.X ならいけた、ということだったので、 いっそ OS を 5.4 に上げました。 これでちゃんと認識して使えるようになってくれましたが、 しかし今度は今まで認識されていたグラフィックカードの認識が 悪くなったようで、今までは dmesg には
pci0: <ATI Mach64-GU graphics accelerator> at 8.0 irq 9と出ていたのですが、5.4 では
pci0: <display, VGA> at device 8.0 (no driver attached)のようになってしまいました。 しかし、X が使えなくなったわけではなく、 今まで通り使えるので特に問題はなさそうです (cf.「X に関するメモ (10/30 2005)」 )
(cf. 「X に関するメモ (10/30 2005)」 )
普段利用しているマシンを、FreeBSD 2.2.8 から FreeBSD 4.7 に 移行したのですが、そのためか色々変化が出ました。
「その他のメモ (2004/10/09)」 および 「その他のメモ (2004/10/05)」 に書いた gnuserv-3.12.6 の問題ですが、 gnuserv-3.12.7 が公開されました。 これはちゃんと configure で対処され、 HAVE_SOCKADDR_SUN_LEN が config.h で 1 となり、 特に何もしなくてもちゃんと動くものができました。 よって下のパッチは不要です。
「その他のメモ (2004/10/05)」 に書いた gnuserv-3.12.6 の問題ですが、 作者からメールが来て、 FreeBSD ユーザーからは 2 度目の報告で これはバグではなく HAVE_SOCKADDR_SUN_LEN を定義して コンパイルしてみて欲しい、と言われました。 確かに
make 'CFLAGS = -g -O2 -DHAVE_SOCKADDR_SUN_LEN'
作者によると、それでうまくいくなら、 次の版では configure で適切にそれが定義されるように 修正してくれるそうです。
FreeBSD 2.2.8 + mule2.3@emacs-19.34-alpha01 に gnuserv-3.12.6 を 入れてみたのですが、 gnuserv が /tmp に作るパイプファイルは本来
/tmp/gsrvdir[pid]/gsrv
/tmp/gsrvdir[pid]/gsr
(cf. 「その他のメモ (10/20 2004)」)
「その他のメモ (2004/09/10)」 に書いた FMV の FreeBSD なんですが、何か time コマンド付近が不安定で、
/usr/bin/time awk 'BEGIN{for(j=0;j<=100000;j++) j*j}'
1.09 real 0.00 user 1.09 sys
/usr/bin/time awk 'BEGIN{for(j=0;j<=1000000;j++) j*j}'
10.77 real 0.00 user 10.77 sys
% /usr/local/bin/time -p [program]
real 623.19
user 0.00
sys 621.96
学生に、計算機実習室のお古の FMV に FreeBSD をインストールを やってもらいました。 つまずいたのは boot マネージャの選択位で、 後はすんなりだったようです。 X の設定も楽に済んだようで、17inch のやや小さいディスプレイですが、 一応 1280x1024 の解像度が使えています (デフォルトでは 1152x864 はだめ、1152x768 は真ん中が膨らんでました)。 まだカーネルの再構築まではやっていません。
「その他のメモ (2003/07/10)」 に書いた xscanimage の件ですが、デバイス名をちゃんと指定して
% xscanimage epson:/dev/uk0
% scanimage -d epson:/dev/uk0 > file.pnm
また、xsane は locale に関するエラーが表示されていたので、 -lcrypt -lxpg4 をつけて再コンパイルしたら動くようになりました。
最近 EPSON の中古の SCSI スキャナ (GT-8700) を手に入れました。 (「使用環境: PC9821Xs」 参照)。 それ用にと思って sane の新しいもの (sane-backends-1.0.11, sane-frontends-1.0.11, xsane-0.91) をコンパイル + インストールしたのですが、 どうもうまく動きませんでした。 sane-find-scanner はちゃんと scanner を認識してくれるのですが scanimage, xscanimage 等はだめです。 これはどうやら FreeBSD 2.2.8 で使っているからのようです。
FreeBSD 3.X 以降では scanner 等への対応が多少なされたようで、 デバイス /dev/pass? と /dev/xpt? が用意されているらしいのですが、 FreeBSD 2.2.8 にはそれらはなく、/dev/uk0 (= unknown device) を使用するようです。 ところが新しい sane はソースを見ると /dev/xpt? を使うように 書かれているようで、それが原因のようです。
これは sane を少し前の物 (sane-1.0.3) にバージョンを落とすことで解決し、 何とか使えるようになりました。 ただ、xscanimage は core dump しますし、xsane もだめなようで、 コマンドライン版の scanimage しか使えません (もちろんそれで十分です)。
新しい GNU awk (3.1.1) では、multibyte 機能が本家に入っているようです (by Isamu Hasegawa) が、 それは OS が locale 周りにそれに必要な関数を持っているかどうかと 関係があるらしく、 私が普段使っている FreeBSD 2.2.8 辺りではどうもその機能は 有効にはならないようです。 (Solaris なんかも 2.6 ではダメで 7 以降が必要そう)。 AWK は日常最も良く使うソフトの一つなので、 ちょっとだけ OS を version up したくなってきました。
普段利用している 9821Xs に dclock (デジタルクロック; Dclock-pl6) をインストールしてみたのですが、 fvwm (fvwm-1.24r) 上ではその上のマウスによる focus が効かず、 キーボードによるアラームセットやオプションの切り替えなどが できませんでした (fvwm も dclock も ports や package からは 入れてませんのでもしかしたらそのせいかも知れません)。
調べてみると以下のようなパッチで対処可能らしいことが分かりました。
ところが、私が普段利用している 9821Xs の FreeBSD(98)2.2.8R + XFree86(98)-3.3.3 (+ fvwm 1.24r) では、 このパッチでも解消しませんし新しい dclock (v2.1) でもうまくいきません。 twm ではちゃんと動くので同じ問題だと思いますし、 新しい方の FreeBSD 4.5R + XFree86-3.3.6 ではちゃんとこのパッチで 問題なく動くようになりました。 その辺の挙動を比較しながら色々調べてみたのですが、 XFree86-3.3.3 のライブラリ辺りにバグがあるのかもしれません。 まあ、こんな古い環境を使っている方が悪いんでしょうが (^^;
今日、普段使用している 9821Xs のマシンが落ちて、 X が動かなくなりました。最初はディスプレイを疑ったのですが、 色々調べてみるとどうも本体のグラフィックボードに問題があるようで、 X の起動時のログが、通常は
(**) S3: chipset driver: s3_generic (**) S3: Option "necwab" (--) S3: card type: 386/486 localbus (--) S3: videoram: 2048k (--) S3: Detected an S3 SDAC 86C716 RAMDAC and programmable clock (**) S3: Ramdac type: s3_sdac (--) S3: Ramdac speed: 135 MHz (**) S3: Using S3 Gendac/SDAC programmable clock (MCLK 61.568 MHz)であるのが、
(**) S3: chipset driver: s3_generic (**) S3: Option "necwab" (--) S3: card type: 386/486 localbus (--) S3: videoram: 2048k WARNING: Did not detect a ramdac of type "s3_sdac" as specified! (**) S3: Ramdac type: s3_sdac (--) S3: Ramdac speed: 135 MHz (**) S3: Using S3 Gendac/SDAC programmable clock (MCLK 61.568 MHz)のようになっていました。 Ramdac に何らかの支障が出たようで、これには全くお手上げです。 もしかして部屋が暑かった事などが影響しているのでしょうか (今日からクーラーをなるべく使うようにします <(_ _)>)。
ただ、たまたま現在 Xs が 3 台自由に使える状態にあるので、 そのうち一台とディスク、メモリ、C Bus ボード類を入れ換えて (所要 40 分程度) 復帰しました。 しかもこの Xs はほとんど使ってなかったようで、 ホコリ等もほとんど溜っておらずしばらくは充分に使えそうです。 ついでにいろいろ拡張しても良かったのですが とりあえず元の状態と同じ状態に戻しただけです。
現在、年度変わりに合わせて研究室の計算機、プリンタ、ハードディスクなどの 整理を行なっていて環境が少しずつ変わっています。 カーネルや X の定義ファイル自身はそう変えずに整理を行なう予定ですが、 余裕があれば (なさそうですが) OS のバージョンアップもそろそろ行っても いいかなと考えています。
「その他のメモ (09/06 2000)」に書いた、 kerberos で上書きされるファイルのリストですが、 /usr/lib/libtelnet_p.a は、「kerberos で追加」ではなく、 「proflibs.?? のものを kerberos が上書き」されることが わかりました。よってこれも戻してやりました。
また、2.2.8R の方では
/usr/include/telnet.h /usr/lib/libtelnet.so.3.0の 2 つは消した方が無難なようなので消しました。
4 台の FreeBSD マシンを NIS のクライアントにしてパスワードを 共有することも一応うまく行きました。NIS のサーバマシンは Solaris 2.6 です。ホームディレクトリは共有せず、ローカルの NIS クライアント側に持つようにしています。 つまり、パスワードのみの共有です。クライアント側でやったことは
hoge:$1$XXXXXX:1003:2000::0:0:FullName:/home/hoge:/usr/local/bin/tcsh
+hoge:::2000::0:0::/home/hoge:/usr/local/bin/tcsh
なお、ypbind の前に portmap が立ち上がっている必要があります。 1 台、portmap を disable にしていたマシンがあり、ちょっとした 作業にいちいち数分ずつ位待たされて、気がつくのにも 時間がかかったため復旧にかなり手間取りました。
4 台の FreeBSD マシン (上の 2 ~ 5) を NIS client にして、 Solaris 2.6 のマシンのパスワードを共有しようと、 DES をインストールしました (international 版)。 しかし、そのとき kerberos も一緒にインストールしたのですが、 それによりいくつかのバイナリファイル、ライブラリが置き換わって しまい、不具合が生じました。たとえば FreeBSD 3.5R の方では passwd コマンドが使えなくなりました。
よって、何が置き換わったのかをチェックして kerberos を アンインストールしました。
以下に、どのファイルが置き換わってしまうかを上げます。 オンラインマニュアルファイルは除きます。
よって、bin.?? を展開し、そこから必要なものを元に戻していけば いいのですが、
# mkdir tmpdir
# cat $dist/bin.?? | /usr/bin/tar --unlink -xpvzf - -C tmpdir
(cf. 「その他のメモ (09/07 2000)」)
どうやら、PC9821Xs (X-MATE 内蔵 PCM 音源: mss0) の、 上にあげた環境では、Linux 用の RealPlayer 5.0 を Linux emulation の機能で使うことは難しいようです。
FreeBSD 用の RealPlayer 3.0 なら一応動きますが、やや不安定です。
フロッピーディスクの MS-DOS フォーマットに関して少し調べたことを まとめておきます。
FreeBSD 上でフロッピーをフォーマット (MS-DOS 形式) する場合は /usr/sbin/fdformat を行った後で MS-DOS ファイルシステムを 作りますが、それには幾つかの方法があります。
以上のテスト結果、パッチなどは fj.os.bsd.freebsd に投稿しました。 その記事、およびそれに対する柴田さんのフォローに対する返事を 下に上げておきますので、詳しくはそちらをご覧下さい。
ディレクトリ dir2 の中に、ディレクトリ dir1 をそのまま コピーするためには
cp -r dir1 dir2
cp -r dir1/ dir2
MS-DOS 領域のファイル名の制限の問題ですが、リリースノートによると 2.2.7R の頃から Win95 のロングファイルネームがサポートされ、 その頃から MS-DOS のファイル名に対する扱いが厳密になったようです。 '.', '+' 以外にも、',', ':', ';', '=', '[', ']' などが MSDOS の規格にならって使えないようになっています。
mount_msdos には -W のオプションがあり、それにより昔の型の ファイル名を扱うようにすることはできるようです。「その他のメモ (12/27 1999)」に書いた、 MS-DOS 領域のファイル名の制限の問題ですが、 '+' もだめであることがわかりました。
なお、mount_msdos には -l なるオプションがあり、 長いファイル名のファイルを作ることもできます。 ファイルを新規に作る場合は問題ないのですが、 元からそのような名前のファイルがある場合に問題があります。
あちこちの FTP サイトからダウンロードしてきたソフトを MO の MS-DOS 領域に落としているのですが、MS-DOS 領域に関する仕様も 2.2.1R と 2.2.8R では変わったようです。 2.2.1R では "2.2.2" のようなファイル名 (拡張子に . が含まれるもの) も許されていましたが、 2.2.8R ではそのようなファイル名は許されないようで、 ls では見れるのですが、ls -l や ls -F などでは、 そのようなファイルはない、と言われますし、アクセスもできなくなります。
また、今まで MS-DOS 領域のディレクトリ名の変更を mv ではできない、 という不具合がありましたが、これは 2.2.8R でもそのままです。 変更したい場合は (dir1 から dir2 へ)
mkdir dir2
mv dir1/* dir2
rmdir dir1
(cf. 「その他のメモ (12/30 1999)」)
私は他にも複数の UNIX (Solaris, HP-UX) を使っていることもあって、 FreeBSD のソフトも package や ports を使わずに (パッチや Makefile などは参考にさせてもらっています) 自分でコンパイルしてインストールしているのですが、 普段使用している Xs の OS を 2.2.1R から 2.2.8R に上げたときに いくつか問題が出ました。
Xs では 2.2.8R で 2.2.1R のバイナリを使用していたのですが、 shared library がバージョンアップしているので、 特に X のライブラリを使うプログラムは 2.2.8R 用にいくつかは コンパイルし直しました。
しかし、mule (mule-2.3@19.34) に問題があり、mule -nw 以外では core dump して立ち上がらなくなってしまいました。 結局、リンク時に -lcrypt -lxpg4 をつけて再コンパイルすることで 動くものができましたが、ライブラリの参照順序が大事なようで、 うまく入れてあげないとだめなようです。 Xp のマシンには package インストールした mule があったので、 それを参考にして -lutil と -ltermcap との間に -lcrypt -lxpg4 を 入れました。
また、LANG も適切なものに設定しておく必要があるようです。