「しおり用」と書かれた所は、それをクリックしてからブックマークに入れると、
それはページの先頭ではなく、その箇所へのブックマークになります。
ページが長くなったときには便利だろうと思います。
(04/01 2006)
そういえば、今までちゃんと説明していませんでしたので、書いておきます。
ここには、日付ごとに記事 (記事 A とします) を書いていますが、
その最後に、(cf. 「Unix に関するメモ等 (XX/XX 20XX)」)
のように別な日付の記事 (記事 B とします)
へのリンクがついているものがあります。
これは、「被参照リンク」で、
記事 B が記事 A を参照している (リンクを貼っている) ことを意味します。
つまり、記事 B の方が記事 A より後の記事であり、
記事 A の続きや追加情報、訂正などの内容であったり、
記事 A に関連する別な話題であったりしますので、
記事 A に被参照リンクがついている場合は、
是非そちら (記事 B) もご覧ください。
(01/29 2014)
- (09/24 2019)
(しおり用)
「Unix に関するメモ等 (07/19 2019)」,
「Unix に関するメモ等 (09/10 2019)」,
「Unix に関するメモ等 (09/18 2019)」
の xdvi のプレビューで gs-9.27 だと EPS が表示されない件の続報です。
どうやら、xdvik の方でも既にそれに対する修正が入っているようです
(xdvik-22.87.04; 2019-07-29)。
Debian の修正とはだいぶ違うようですが、
これを xdvi に当てても確かにうまくいくようです。
FreeBSD の場合は、以下のパッチを使うか、
ports の xdvik のバージョンが 22.87.04 に上がるのを待てば良さそうです。
- (09/18 2019)
(しおり用)
「Unix に関するメモ等 (07/19 2019)」,
「Unix に関するメモ等 (09/10 2019)」
の xdvi のプレビューで gs-9.27 だと EPS が表示されない件の続きですが、
Debian の方では、gs よりむしろ xdvi の方にパッチが当たっているようです
(xdvik-ja 22.87.03+j1.42-3)。
ということで、gs に当てずに以下のパッチを
xdvi に当てるという手もあるようです。
FreeBSD の場合は /usr/ports/print/tex-xdvik/files/
に上のファイルをコピーして「make deinstall ; make install」
すればインストールできます。
これで、gs-9.27 を修正しなくても xdvi で EPS が表示できるようになります。
gs 側もどうやら、
「Unix に関するメモ等 (09/10 2019)」
に書いたように適当に削除してしまった、というわけではなく、
それなりに理由があって削除したようですので、
むしろ gs の方の修正よりも xdvi 側の修正の方が筋のようです。
(cf. 「Unix に関するメモ等 (09/24 2019)」)
- (09/10 2019)
(しおり用)
「Unix に関するメモ等 (07/19 2019)」 に書いた、
xdvi のプレビューで gs-9.27 だと EPS が表示されない件ですが、
新出＠奈良女子大学 さんから、以下のパッチで改善する、
という情報を頂きました (Thanks 新出＠奈良女子大学 さん)。
確かにこの部分は gs-9.27 でなくなっている部分で、
これを追加してみるとちゃんと xdvi で
EPS ファイルが表示されるようになりました。
gs-9.27 の履歴ファイル (doc/ghostscript/9.27/History9.htm) を見ると、
2019-02-13 に削除したとあり、
特にセキュリティ等の理由による削除とは書いておらず、
全然使われていないから、ということのようです。
とすると、xdvi で問題になることが想定されていなかったのかもしれませんね。
新出＠奈良女子大学 さんは ghostscript の
bugzilla にも報告されるそうですので、
新しい gs ではこの問題は修正されるかもしれません。
新出＠奈良女子大学 さん、どうもありがとうございました。
(cf. 「Unix に関するメモ等 (09/18 2019)」,
「Unix に関するメモ等 (09/24 2019)」)
- (07/19 2019)
(しおり用)
うちは、TeX の dvi ファイルのプレビューは、
相変わらず xdvi でやってますが、
最近は PDF まで作って (latex + dvipdfmx, または pdflatex)、
PDF でプレビューすることが主流のようで、
xdvi の設定等ではやや苦労することが多くなってきました。
最近 xdvi (xdvik-22.87) で、
PostScript ファイルの表示ができなくなっていることに気がつきました。
どうせ xdvi では PS の表示は崩れることもあり、
普段 PS の表示は切っていたので気がつくのが遅れました。
pict2e パッケージを使用した picture 環境の画像の表示は、
xdvi では ps special を使っているようで
(pict2e パッケージの xdvi オプションは実質 dvips 指定と同じ)、
PostScript の表示ができないと、
includegraphics による EPS ファイルの表示だけでなく、
pict2e パッケージでの picture 環境の絵が出なくなってしまいます。
情報を検索し、いくつかの組み合わせで調べたところ、
以下のことがわかりました。
- xdvi と gs-7.07 との組み合わせの場合、PS は一応表示される
- xdvi と gs-9.22 との組み合わせの場合、Resource/Init/gs_init.ps
を一箇所修正すれば PS は一応表示される
- xdvi と gs-9.23, 9.24, 9.25, 9.26 との組み合わせの場合、
PS は一応表示される
- xdvi と gs-9.27 との組み合わせの場合、PS は表示されない
まず、1., 2., 3. で「一応」と書いていますが、
pict2e の picture 環境の図形の表示の場合、
xdvi の zoom レベルによって図と文字の重なり部分の表示がうまくいかず、
一部の文字が表示されなかったりすることがあるようです。
2. の gs-9.22 の場合は、xdvi を実行して PS 部分を表示させようとすると、
gs: Error: /undefined in flushpage
のようなエラーが出てしまいます。
これは、以下の redhat の bugzilla でも報告されていますが、
Resource/Init/gs_init.ps を一箇所修正すれば、
1. と同様に表示されるようになります。
3. は、9.23 - 9.25 では上の対処が既に導入されていて、
PS は一応表示されます。
4. は、2. と違い gs のエラーは表示されませんが、
PS の画像部分が表示されませんので、
原因は 2. とは違うところにあるようです。
今のところ、4. に関する情報はまだ見つかっていません。
もししばらく情報がなければ ghostscript の
bugzilla にでも報告してみようかと思います。
(cf. 「Unix に関するメモ等 (09/10 2019)」,
「Unix に関するメモ等 (09/18 2019)」,
「Unix に関するメモ等 (09/24 2019)」)
- (07/10 2019)
(しおり用)
うちの研究室では、PS プリンタとして Ricoh の IPSIO (今は SP6210)
を使用しています。
普段は Solaris の lp システムや、
FreeBSD の lpr を使って標準的な印刷を行っていますが、
一点不満がありました。
私は普段、A4 だけでなく、B5 や B4 の印刷もかなりの頻度で行いますので、
給紙は全部手差しトレイで行っています。
そして紙サイズの変更の際、いちいち本体のパネルで
手差しトレイの紙サイズの変更を行わなければいけなかったのですが、
それをソフト的に印刷の際にコマンドを送信することで行えないか、
と思っていました。MS-Windows の場合は、
プリンタドライバがそれをやってくれているようなので、
仕組みとしてはあるはずだと思っていました。
先日、IPSIO のソフトウェアガイド (付属 CD の中にある)
を見ていたら、その方法が書いてありました。
実は、これは以前も見たはずなのですが、
そのときはやり方が悪くうまくいっていませんでしたが、
今回それがうまくいきましたので、
ここに書き残しておきます。
ちなみに、現在 IPSIO はコンピュータと直接ケーブルで接続しているのではなく、
プライベートアドレス空間内で IP アドレスを与えて
ネットワーク接続をしています。
ソフトウェアガイドには、telnet などで接続して、設定を変更したり、
状態を表示させたりする解説などが書いてありますが、
印刷時の用紙設定などは、
「UNIX で使う」の「オプション指定 (UNIX)」という節に書かれています。
それによると、印刷は直接 rsh, rcp, ftp などを使って実行でき、
その際にオプションを指定するようです。
Unix 標準のプリントコマンドの lp, lpr でも設定できるかもしれませんが、
オプションに制限があるようにも書かれていますので、
今回は rsh を使いました。
なお、ssh も IPSIO には組込まれているので使えるかもしれませんが、
デフォルトでは使えず、ssh を使う場合は設定が必要かもしれません。
印刷の PS データは標準入力から与え、rsh で
「rsh [IPSIO の ipaddress] print [オプション]」
のように Unix 側で実行すれば印刷ができます。
必要なオプションは以下のもので、, (カンマ) 区切りで指定します。
- エミュレーションタイプ:
filetype=RPS
(RPS = PostScript3 エミュレータ)
- 給紙トレイ:
tray=bypass (bypass = 手差し)
- 紙サイズ:
paper=[size] ([size] = a4,a3,a5,jisb4,jisb5 等)
よって、file.dvi (a4 原稿) の B4 2up での印刷であれば、
% dvips -f file.dvi | psnup -2 | psrsize=b4
| rsh hostA print filetype=RPS,tray=bypass,paper=jisb4
(hostA は ipsio のホスト名 or IP address) とすれば、
プリンタ側のパネル設定によらず B4 の手差しの紙に正しく印刷されます。
当然、用紙は手動で差しかえなければいけませんが、
プリンタのパネル設定の変更がこれで不要になるので、
スクリプトを書いてしまえばだいぶ楽です。
本当は lpr のスプールシステムが使えるといいのですが、
まあバッググラウンドジョブにすればそう違いは感じないと思います。
- (03/04 2019)
(しおり用)
「Unix に関するメモ等 (02/28 2019)」
に書いた netpbm の pstopnm のアンチエイリアスの問題ですが、
FreeBSD の bugzilla に報告したら、
netpbm 側の連絡先を教えてもらってそっちに送るべきと言われました。
で、netpbm 側に送ったらすぐに対応していただき、
そしてそれが FreeBSD 側でも対応されたようです。
新しい ports では問題は解消されそうです。
- (02/28 2019)
(しおり用)
netpbm に、PS ファイルを画像化する pstopnm というものがついていますが、
これは内部で ghostscript を用いて PNM 画像化しています。
古い pstopnm は、gs のアンチエイリアスオプション
(-dTextAlphaBits) を使ってくれなかったので、
pstopnm で gs のアンチエイリアスを利用するときは、
gs のラッパースクリプトを使って、
「gs -dTextAlphaBits=4」を gs
と認識させるようなことをしてごまかしていました。
現在 (マニュアルによれば 10.53 以降) の pstopnm には、
「-textalphabits={1,2,4}」のオプションがついて、
対応する -dTextAlphaBits
をつけて実行してくれることになっているように読めます。
ところが実際に実行してみるとそれがうまく効いていません。
netpbm-10.85.2 のソースを見てみたのですが、
どうやらみかけ上はほぼそれができるようになっているのに、
肝心の実行部分でなぜかそれをやっていません。
以下にその対応パッチを置いておきます。
うちでは、これで使えるようになりました。
FreeBSD の ports 用に作ったので、少し長い名前になっています。
netpbm のバグレポートサイトもなんかはっきりとは見つからないので、
本家には報告していませんが、FreeBSD 側には報告してみようと思います。
(cf. 「Unix に関するメモ等 (03/04 2019)」)
- (11/20 2018)
(しおり用)
tgif の折れ線の先につく矢先ですが、
線の太さを変えると自動的に矢先の大きさも変わりますが、
単独で矢先を変えることはできないかと思って
tgif のメニューをみたのですが、どうもそれらしいものがありません。
ということで、少し調べて file.obj を手動でいじって
それを変更できることがわかりましたが、
さらに良く調べたら実は tgif のメニューから
それができるようになっていることに気がつきました。
詳しくは、以下をご覧ください。
- (06/11 2018)
(しおり用)
「Unix に関するメモ等 (04/02 2018)」
に、kterm のフォント用の X のリソース設定で、
「KTerm*KanjiFont」ならうまくいくが、
「KTerm.KanjiFont」だとうまくいかない、
それはまだ理解していない、
と書きましたが、これに関して、 Kiyoshi KANAZAWA さんから、
「kterm.vt100.kanjiFont」と指定すればうまくいくはず、
と教えて頂きました。
確かに、man kterm を見ると、kanjiFont は
xterm の vt100 ウィジェット用リソースであると書いてあります。
それで納得できました。
なお、さらに Kiyoshi KANAZAWA さんから、そうなっているのは、
元の xterm が vt100 だけでなく、Tektronix 4014
などもエミュレートできるから、と教えて頂きました。
確かに Solaris 10 の man xterm を見ると、
DEC VT102 互換と Textronix 4014 互換の端末エミュレータを提供する、
とあります。
一度 gnuplot のテストでそのあたりを使ったことがあるような気がしますが、
普段は vt100 以外を意識したことはありませんでした。
また、Kiyoshi KANAZAWA さんは kterm の開発に関わっていた方のようで、
cut & paste 時のダブルクリックによる cut の話
(xterm の場合は単語単位だが、kterm の場合は文字の種類を見て
より広い範囲を cut する) であるとか、トリプルクリックなどの話、
さらには Solaris 11 の locale サポートの変更の話
(11.4 からは ja_JP.eucJP や jserver, wnn 等の対応が悪くなる)
なども教えて頂きました。
どうもありがとうございました。
- (05/09 2018)
(しおり用)
Solaris 10 には、/usr/sfw/lib や /usr/lib に少し古い
gtk ライブラリが入っていますが、
それでは少し不十分なので、
普段は別のディレクトリにもう少し新しめの gtk のライブラリ群を作っていて、
それによって wxWidgets、gnuplot などもコンパイルしていました
(glib-2.17.3, gtk+-2.12.11, wxWidgets-2.8.12 (gtk2))。
ところが、2017 年の 2 月位から gnuplot が少し新しめの
glib (glib-2.28 以降) を仮定して書いている箇所があり、
それでその頃に gtk や glib, wxWidgets などを一度更新しました。
(glib-2.51.2, gtk+-2.24.31, wxWidgets-3.1.0 (gtk2))。
ところがそれで開発版の gnuplot をコンパイルすると、
wxt terminal の出力がおかしくなりました。
Solaris 10 のマシンの前に座って作業をする分には問題ないのですが、
別のマシンから remote で Solaris の gnuplot を実行して
wxt terminal で表示させると問題がでます。
長く放っていたのですが、最近それらを少し調べ直してみましたので、
それをここにまとめておきます。
その問題とは、
- [a] wxt terminal のグラフウィンドウが縦に細長く起動する
(デフォルトは 640x384 のはずだが 100x384 みたいな感じで立ち上がる)
- [b] 上にあるアイコンの上にマウスを移動すると出るはずの
バルーンヘルプがでない
- [c] 画像出力のアイコンを押すと何も出ずに gnuplot が固まる
(保存先のディレクトリ一覧やファイル名などのダイアログウィンドウが
起動するはず)
[a] は、その後でウィンドウをマウスで広げて、
replot とかするととりあえず正常の表示になるのですが、
かなり面倒です。
[c] は、よく調べるとダイアログが立ち上がってないわけではなく、
ウィンドウマネージャ (fvwm) のウィンドウリストに中には
ちゃんと入っていて、そこから表示させることはできます。
固まったように見えたのも、
ダイアログの方に制御が移っていてそちらが終了するのを待っている状態に
なっているようです。
見える場所に立ち上がらない理由は、
ダイアログをスクリーンに収まらない変な座標に
立ち上げようとしている可能性があります。
そこで、wxWidgets についている samples/ のプログラムを make samples
でコンパイルしてみたのですが、
そこにある samples/display/ の display というプログラムを実行すると、
現在表示している X サーバのディスプレイサイズを表示してくれます。
Solaris 10 の前で実行すると、
Size: (1280, 1024), Client area: (0, 0)-(1280, 1024)
のようにだいたい正しく表示されています。
上のアイコンを押せばプルダウンメニューが正しく表示されます。
しかし、それを remote の FreeBSD のマシン (display は 1680x1050)
から実行すると、そのウィンドウが縦に細長く起動して、
Size: (-28666, 6660), Client area: (0, 0)-(-28666, 6660)
のような無茶苦茶な値が表示されます。
wxWidgets-3.1.0 をコンパイルした glib, gtk の環境で、
wxWidgets-2.8.12 (wxGTK-2.8.12), wxWidgets-3.1.1
もコンパイルして確認してみたのですが、
3.1.1 の方は 3.1.0 と同じ、
2.8.12 はとりあえず正常サイズで起動しますが、
Size: (-28666, 6660), Client area: (0, 0)-(1680, 1050)
となります。Client area の表示だけまともになっていますが、
プルダウンメニューは出ません (見えないところに出る)。
どうやら、wxWidgets がリモート X サーバのサイズ、
geometry の取得に失敗しているような感じです。
FreeBSD 側の解像度を xrandr で変えて実験すると、
上の Size, Client area も変化しますが、正しい値にはなりません。
samples/display/display.cpp を見てみると、
Size の値は GetGeometry() method で、
Client area の値は GetClientArea() method で取得しています。
まず、GetGeometry() の方ですが、gtk=2 版の wxWidgets では、
- GetGeometry(): src/gtk/display.cpp 内で、gtk+ の
gdk_screen_get_monitor_geometry() を使って取得
(wxWidgets-3.1.0, wxWidgets-3.1.1。2.8.12 にはない)
- GetGeometry(): src/common/dpycomn.cpp 内で
wxDisplaySize() を使って取得する実装もある
(内部で gdk_screen_width(), gdk_screen_height() を実行)
(wxWidgets-3.1.0, wxWidgets-3.1.1, wxGTK-2.8.12。)
のようになっています。gtk のサンプルプログラムを書いて実験してみると、
remote からでは確かに gdk_screen_get_monitor_geometry() は不正な値を返し、
gdk_screen_width(), gdk_screen_height() は正常な値を返します。
よって、まず gdk_screen_get_monitor_geometry()
が不正な値 (負の height や width) を返す場合に、wxDisplaySize()
で値を取り直すようなパッチを書いてみました。
GetClientArea() の方は、src/gtk/display.cpp 内で、
gdk_screen_get_monitor_workarea() を使って取得しているのですが、
これも上と同様に、負の height や width になる場合に
wxDisplaySize() を使うパッチを書いてみました。
この両者を合わせたものを以下に置きます
(wxWidgets-3.1.1 用のパッチ、3.1.0 にも多分当たる)。
ついでに、gtk=2 の場合、キャストの問題でコンパイルが止まる場所も
一つありましたので、それの修正も一緒に入れてあります。
ただし、本当はマルチスクリーンの場合とか、
状況は色々あるはずなので、
こんなつけ焼き刃なパッチではまずいと思いますし、
本来は wxWidgets が悪いというよりも、
gdk_screen_get_monitor_geometry()、
gdk_screen_get_monitor_workarea()
が正しい値を返さないことの問題なので、
gtk+ の方をいじるか更新すべき問題だと思いますので、
wxWidgets の開発者への報告もまだしかねています。
しかし、とりあえずはこれで samples/display
も正常値を表示するようになりましたし、
gnuplot の [a] の問題も解消できました。
しかし、[b], [c] の問題はまだ解消していません。
[a] と同じく、いずれも、多分不正な geometry
から計算した変な場所に表示しようとして失敗しているのだと思いますが、
それはどこを修正すればいいか、まだよくわかっていませんが、
方向性は見えてきました。
ただ、[b], [c] はそれほど緊急の修正の必要性を感じていませんので、
また少し時間のあるときにでも考えてみたいと思います。
- (05/09 2018)
(しおり用)
うちには、FreeBSD マシンと Solaris のマシンがあるのですが、
普段は FreeBSD マシンで X server を使っていて、
Solaris へはリモートログインして使っていて、
Solaris のコマンドは X client として local の FreeBSD
の X server 上に表示させています。
以前は、それで問題はなかったと思うのですが、
色々更新したせいか、
Solaris の gv (3.7.4) の動作が最近おかしくなっていました。
現象としては、Solaris マシン上で PS ファイルを
gv で表示させようとすると、
ほぼスクリーン一杯の画面が開いて、
しかも PS ファイルはいつまでも表示されない、
という状態になります。
これは Solaris マシンの X server (local) で
gv を動かしたときには問題はなく、
FreeBSD から remote で Solaris 上の gv 起動するときだけ起こります。
また、gv でなく gs を直接起動した場合は、
local でも remote でも問題なく表示されます。
よって、gs ではなく gv の問題で、かつ remote で使用する場合の問題、
ということになります。
なお、man gv ではコマンドラインオプションの説明しか出てきませんが、
info gv で gv の info を見ると、
リソースやキーバインドなどの情報も書いてあります。
コマンドラインオプションとして -infoAll とすると、
起動時にメッセージウィンドウが別に起動して、
警告やエラーの詳細などが表示されます。
それを見ると、remote から gv を起動した場合は、
以下のようなものが出ていました。
Warning: Could not allocate backing pixmap in main window.
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 35
Current serial number in output stream: 35
この手のは良く見るのですが、かなり低レベルでの直接の原因の話なので、
これだけではなんともわかりません。
gv のソースを見ると、
-debug という隠しオプションでいくつかの情報が表示されることがわかります。
それを表示させてみると、FreeBSD から Solaris の remote の
gv を起動した場合は以下のようになります。
Locale1=ja
Locale2=ja
Locale3=ja
Your detected screen size is: 444 mm x 277 mm
That looks like a single monitor, as the ratio is 1.60.
Your detected screen resolution is: 1680 x 1050
Xinerama's resolution of screen 0 is: -28666 x 6660
それに対して、Solaris の local で gv を起動した場合は以下の通りです。
Locale1=ja
Locale2=ja
Locale3=ja
Your detected screen size is: 361 mm x 289 mm
That looks like a single monitor, as the ratio is 1.25.
Your detected screen resolution is: 1280 x 1024
比較するとわかりますが、remote の場合にだけ表示されている
「Xinerama's resolution of screen 0」
の値が明らかに変です。
実は gv は configure 時に「--enable-runtime-messages」
をつけると、今どこの処理をしているかという情報と
いくつかのパラメータ値を大量に出力するようになります
(1 回の実行で 1 万 5 千行ほど)。
その出力と gv のソースを見てわかりましたが、
やはり Xinerama ライブラリの XineramaQueryScreens()
が失敗して不正な値を取得しているようです。
gv は Xinerama にも対応しているようで、
Xinerama を使用している場合はその関数を使用する
コードが入っているのですが、
うちは別にマルチディスプレイでもないのにその
Xinerama を使用する方に入って不正な値 (負のスクリーンサイズ値など)
を取得してしまうために失敗しているようです。
これを回避するのは難しくなく、
gv はデフォルトでは Xinerama の利用は Auto (自動判別)
になっているのですが、それを明示的に Off (使用しない)
とすればいいわけです。
X の server 側で、「gv.xinerama: Off」
のリソースを設定することで問題は起きなくなりました。
なお、info gv に書かれているマウス操作の話は、
gv を使っていればだいたいわかるものですが、
キーバインドの話は知らないものも多く、
だいたいはマウスのメニューからの選択でも実行できますが、
知っていると便利なものも結構あります。
- (04/02 2018)
(しおり用)
古い emacs (20.7) の X での日本語表示に関する話を一つ書きます。
なお、主に FreeBSD での話なのですが、
この emacs は ports で入れたものではありませんし、
必ずしも FreeBSD で閉じた話でもありませんので、こちらに書いておきます。
私はいまだに terminal emulator は kterm を、
エディタは emacs-20.7 (+skk) を使用していて、
日本語コードも UTF-8 ではなく EUC-JP を使用しています。
21 以降の emacs はやや重くなって、
うちの貧弱なマシンでは軽快に動作しなかったことと、
emacs lisp にも色々な変化があって変えるのが面倒だったことなどが理由です。
よってやや時代遅れの話ですが、
その kterm, emacs での漢字の表示に最近一つ問題がでてきました。
今まで、日本語の X のフォント (デフォルトは 14dot) は、
FreeBSD の X ではほぼデフォルトの
-misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0
というフォントを使ってきました。
これは JISX0208.1983、いわゆる 83JIS のフォントなので、
84 区の漢字 (JIS コード 7421H 以降) は、
堯 (7421)、槇 (7422)、遙 (7423)、瑤 (7424) だけで、
それ以降は持っていません。
よって、90JIS (jisx0208.1990) で追加された 2 つの異体字
「凜」(7425; 「凛」の示が禾のもの)、
「熙」(7426; 「煕」の臣の部分が違うもの)
が、このフォントでは表示されません。
ところが前者の漢字を kterm, emacs で表示しないといけなくなったので、
そのための作業をやってみました。
まず、kterm の方ですが、jisx0208.1990-0 か jisx0213.2000-1,
jisx0213.2004-1 などのフォントを使えばこれが表示できるようになります。
FreeBSD では、例えば shinonome フォント (japanese/font-shinonome)
が jisx0208.1990 のフォントなので、これをインストールし、
X のリソースファイル ~/.Xdefaults の KTerm*KanjiFont を
KTerm*KanjiFont: -shinonome-*-medium-r-*--14-*-jisx0208.1990-0
とでも書けば OK です。なお、うちの環境では
KTerm.KanjiFont, KTerm.kanjiFont ではうまくいきませんでしたが、
そこはまだよく理解していません。
次に emacs-20.7 の方ですが、
こちらは X のリソースの定義などの仕組みをよく理解していなかったこともあり、
少し苦労しました。
emacs-20.7 に関係する X のリソースの定義は、
Emacs.font と Emacs.Fontset-[n] を考えればよいようですが、
Emacs.Fontset-[n] は日本語の表示などで使用されるフォントセットの定義、
Emacs.font は、デフォルト (起動時) に使用するフォントの定義のようです。
今までは Emacs.font は
Emacs.font: -*-fixed-medium-r-*--14-*-iso8859-1
と定義していましたが、emacs の info によると、
これはスタートアップフォントの定義で、
これの一部を置換して
-*-*-medium-r-*-*-14-*-*-*-*-*-fontset-startup
としたものを「fontset-startup」という名前のフォントセットとして
emacs は使用するようです。
ちなみに emacs のフォントセット名は、
通常の X のフォント名の最後の 2 field (エンコード部分)
を「fontset-[name]」として定義し、
その部分を適切なフォントのエンコーディング名に
置き換えて参照する仕組みになっています。
emacs で使用するフォントセットの名前としては、
上のような長い名前の他に最後の 2 field である「fontset-[name]」
も使えるようになっています。
もう一つの X リソースの Emacs.Fontset-[n] は、
自前のフォントセットを定義するものです。
[n] は 0 から順番に使うようで、これはフォントセット名とは関係ありません。
だから、例えば
Emacs.Fontset-0: -ipa-*-medium-r-*--14-*-*-*-*-*-fontset-ipa
などとすれば、このフォントセットを「fontset-ipa」
という名前で利用できるようになります。
フォントセットは、一般には英文 (iso8859-1) にはこのフォント、
日本語の漢字 (jisx0208) にはこのフォント、
日本語の半角カナ (jisx0201) にはこのフォント、
のようにフォントの組として定義するのですが、上のように定義した場合は、
「fontset-ipa」の部分だけを
それぞれの文字集合用に定義されているエンコード名に置き換えた
X のフォントを探し、もしそれを割り当てることができなければ
その文字が□で表示されたり、
デフォルトのフォントで表示されたりすることになります。
文字集合毎にフォントを指定する場合は、「[charset]:[fontname]」の形式で
追加して指定します。例えば、
Emacs.Fontset-0: \
-misc-fixed-medium-r-*--14-*-*-*-*-*-fontset-shinonome,\
japanese-jisx0208:-shinonome-*-medium-r-*--14-*-jisx0208.1990-*,\
katakana-jisx0201:-shinonome-*-medium-r-*--14-*-jisx0201.*-*
とすれば fontset-shinonome というフォントセットが定義され、
漢字 (jisx0208) には
「-shinonome-*-medium-r-*--14-*-jisx0208.1990-*」、
カナ (jisx0201) には
「-shinonome-*-medium-r-*--14-*-jisx0201.*-*」、
その他のフォント (英文等) には
「-misc-fixed-medium-r-*--14-*-*-*-*-*-[encode]」
を割り当てるものになります。
この文字集合を意味する japanese-jisx0208 等の名前については、
M-x describe-fontset で見ることができます。
なお、japanese-jisx0208 に対するエンコード名は、
emacs-20.7 のデフォルトでは「JISX0208.1983」と定義されています。
その対応は、*scratch* バッファで x-chaset-registries の値を参照する
(x-charset-registries と書いてその後ろで C-j する) ことで確認できます。
よって、漢字 (japanese-jisx0208) に jisx0208.1983 でなく
jisx0208.1990 のフォントを参照させたい場合は、
上の fontset-shinonome の定義のように
japanese-jisx0208 用のフォントを明示的に指定する必要があります。
また、[charset]: と [fontname] の間に
スペースなどを入れてはいけないようですし (少しはまりました)、
各 [fontname] の部分は、後半の -*-*-*-*-*- の部分は
-*- に省略できるのですが、
最初の fontset-[name] を定義する行は -*-
に省略するとうまくいかないようです (これも少しはまりました)。
リソースファイルでフォントセットを定義した後、
「xrdb -load ~/.Xdefault」(か再ログイン)
としてそれを読み込ませることでリソースを有効にすれば、
その後起動した emacs で M-x list-fontset、
および M-x describe-fontset RET fontset-shinonome RET などのようにして
正しく認識されているかどうかが確認できます。
この fonset-shinonome を emacs 起動直後からデフォルトとして
使えるようにするには、default-frame-alist を .emacs で修正します:
(setq default-frame-alist
(append '(
(font . "fontset-shinonome")
)
default-frame-alist))
このようにして、ようやく 7425 の「凜」の文字を
emacs でも表示できるようになりました。
なお、jisx0213.2000-1 や jisx0213.2004-1 のフォントがあれば、
さらに多くの 84 区の漢字を kterm, emacs-20.7
で表示させることもできるようになりますが、
platex ではデフォルトでは xdvi, dvips, dvipdfmx はいずれも
84 区は 7426 まで (jisx0208.1990 まで) しか表示できませんでしたので、
とりあえずは jisx0208.1990 で運用しようと思っています。
(cf. 「Unix に関するメモ等 (06/11 2018)」)
- (02/02 2018)
(しおり用)
「Unix に関するメモ等 (01/29 2018)」
で紹介した ghostscript-9.22 ですが、
縦書きの article9.ps の表示ではかっこの回転や句読点の位置は
確かに正しくなっているのですが、
ghostscript-7.07 の表示と見比べると表示位置が全体的に
少しずれているようです。
- gs 9.22 での article9.ps の表示
- gs 7.07 での article9.ps の表示
なんとなく 7.07 の方が意図した正しい表示のように思いますから、
縦書きの回転の際の原点の考え方あたりに違いがあるのかもしれません。
ただし、2 列目の章名のところは 7.07 より
むしろ 9.22 の方が正しいように見えたりもしますので、
一概にどちらがよいとも言えません (どちらも問題があるのかも)。
なお、FreeBSD では ports がまだ 9.16 なので、
手動で 9.22 を入れてみましたが、
こちらは configure に特別なオプションも必要ありませんでしたし、
パッチも必要ありませんでした。
- (01/29 2018)
(しおり用)
最近、Ghostscript 9.22 で、
縦書きのかっこなどがちゃんと回転するようになった、
という話を目にしたので、Solaris 10 にインストールしてみました。
実は、以前 9.21 をインストールしてみたのですが、
全く動かず bus error で core dump してしまい、
以前の対処 (「Unix に関するメモ等 (09/17 2013)」)
でもうまくいかなかったので放っていました。
Solaris で gs を gcc と GNU libiconv でコンパイルする場合は、
うちではまず以下の対処を行っています。
- Makefile.in の AC_CFLAGS の最後に
-DSVR4 -g を追加
- Makefile.in の EXTRALIBS と AUXEXTRALIBS の最後に
-lnsl -lsocket -lposix4 $(LDFLAGS) を追加
- 環境変数 LDFLAGS に
-RXXXX (XXXX は GNU libiconv
ライブラリの置き場所) を指定
- configure のオプションに
--prefix=YYYY --disable-compile-inits
--with-libiconv=gnu --disable-fontconfig を追加
(YYYY はインストール先、fontconfig の不使用は好みで)
最初の 2 つは Makefile.in にコメントとしても書かれていたと思います。
ここまではだいたい前と同じですが、これだとやはり examples/tiger.eps,
examples/golfer.eps を見ようとしても bus error してしまいます。
「Unix に関するメモ等 (09/17 2013)」
にある CFLAGS の対処をしても変化ありません
(それに今は必要ないはず)。
gdb で core ファイルを調べてみたら、
どうやら lcms2 の関数で止まっているようでした。
lcms2 は、現在は ghostscript2 の配布物に含まれているのですが、
そういえば以前単体で lcms2 をコンパイルして make check したときも
bus error を起こしていたことに気がついて、
そのあたりを試したり、情報を探してみたら、
以下の情報があることに気がつきました。
これを見ると、OS や gs のバージョン、ghostscript と ghostpdl
の違いはありますが、ほぼ状況は同じで、
gdb で止まっている箇所も同じです。
-dUseFastColor=true をつけて実行すると動く点も同じです。
対処としては、このリストの最後にある
「CFLAGS="-DCMS_PTR_ALIGNMENT=8"」
でいいよう (lcms2 のコンパイルで使用される) ですが、
現在の gs-9.22 には configure のオプションとして、
「--with-memory-alignment=8」
を追加指定することで、
バンドルされている lcms2 のコンパイル時に前記の
CFLAGS を使ってくれるようになるようです (Thanks to Chris Liddell)。
確かにこれで、当方の環境でも bus error しない gs ができました。
examples/cjk/article9.ps のかっこや句読点も
一応正しい位置に表示されるようになったようです。
もちろん --disable-freetype も指定しません
(cf. 「Unix に関するメモ等 (08/24 2013)」)。
- gs 9.22 での article9.ps の表示 (freetype あり、IPA フォント)
(cf. 「Unix に関するメモ等 (02/02 2018)」)
- (10/13 2016)
(しおり用)
私は、添付メールは Unix でテキストファイルとして受け取って、
それを munpack
(
ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.6.tar.gz、
FreeBSD だと converter/mpack)
で展開する、というかなり原始的な受信方法を行っています。
ところが、最近 MS-Word の添付ファイルを受信したら、
そのファイルが壊れている事例がいくつか起きました。
file コマンドでみても、
「Composite Document File V2 Document, Cannot read section info」
などと表示されてしまいます (FreeBSD 10.3 の file)。
調べると、どうやら munpack が問題でした。
MS-Word の添付ファイルの Content-Type は、
通常なら applicatin/msword などが適切なのでしょうが、
一部のメーラでは (Thunderbird とか)、
text/rtf にしてしまうものがあるようです。
munpack は、Content-Type が text/... である添付ファイルからは
decode の際に CR (0x0d) を取り除いてしまう仕様になっていて、
それでバイナリファイルの MS-Word ファイルが壊れてしまっていました。
本来なら、送信側の Content-Type の設定を修正してもらうべきなのでしょうが、
munpack 側でも以下のパッチを適用して対応しておきました。
CR の取り除きはすべての場合でやめてもいいのですが、
一応 text/plain と text/html の場合だけ
CR を取り除くことにしておきました。
- (03/18 2016)
(しおり用)
「Unix に関するメモ等 (03/03 2016)」
に書いた FreeFem++ の続報です。
Solaris 10 (sparc) で gcc + OpenGL (/usr/openwin/lib/libGL*)
で FreeFem++ 3.38-1 をコンパイルした場合、
remote の FreeBSD から ffglut の出力が表示されない (BadValue)、
という問題を紹介しましたが、
その後 Mesa を Solaris 10 に入れてそれを
OpenGL の代わりに使うようにしたらちゃんと
remote の FreeBSD からでも ffglut 画面が表示されるようになりました。
その Solaris への Mesa のインストールにも多少説明が必要ですので、
以下に書きます。
まず、最新の Mesa
(http://www.mesa3d.org/)
は 11.X なのですが、
新しい Mesa は GLUT が分離されています (freeglut 等) し、
PC 用の Xorg 用のカスタマイズがかなり行われ、
Solaris 10 では簡単にはコンパイルできなくなっています (glproto 等が必要)。
よって、GLUT も一緒にコンパイルできる少し前のバージョンの 7.11.2
を使用しました (MesaLib-7.11.2.tar.bz2, MesaGLUT-7.11.2.tar.bz2)。
通常なら、MesaLib-7.11.2.tar.bz2, MesaGLUT-7.11.2.tar.bz2 を展開して、
Mesa-7.11.2 の中で
「./configre --without-gallium-drivers; make; make install」
とすればいいのですが、Solaris ではいくつか問題があります。
いくつかコンパイルエラーがでますが、
それを修正してインストールしたライブラリを使用しようとしたら
大量に「undefined symbol」がでてリンクできませんでした。
原因はどうやら以下の 2 つがあるようです。
- libGLU を作るときのマップファイルがおかしい
- 中間ライブラリの libglsl.a がリンクされていない
よって、それを回避する以下のようなパッチを作って対処しました。
コンパイルエラーとなる部分の対処も含まれています。
configure 前にパッチを当て、
「./configre --without-gallium-drivers; make; make install」
でだいたい OK です。
なお、configure 形式でない Mesa-6.1 では、
configs/ 以下の sunos5-gcc をまねて sunos10-gcc を作って
(それ用のパッチを少し当てて) コンパイルすれば特に問題はなく、
ライブラリの参照の問題もありませんでした。
- (03/03 2016)
(しおり用)
フリーな有限要素法ソフトウェア FreeFem++
(http://www.freefem.org/ff++)
を、Solaris (10) (sparc) と FreeBSD (10.2) にインストールしました。
備忘録も兼ねてここに書いておきます。
- Solaris 10 の場合
まず、FreeFEM++ の最新版は 3.44 なのですが、3.43-2 を試した際、
うちの環境では examples++-load/Element_Mixte3d.cpp
のコンパイルに失敗します。
gcc は 4.7.2 を使っていますが、5.1.0 でもだめでした。具体的には、
cc1plus: out of memory allocating 6040 bytes
after a total of 392880128 bytes
のようなメッセージが出て g++ のコンパイルが止まります。
3.38-1 あたりからこのファイルはだいぶ変わっているようで、
情報もないようなので、
あきらめて少し前の版の 3.38-1 に戻しました。
FreeFEM++ は、configure 時に --enable-download をつけて実行すると、
FreeFEM++ が必要とするフリーソフトがインストールされていない場合は、
それをネットからダウンロードして、
それらを先にコンパイルするようになります。
しかし、その辺が曲者でもあり、
何度もコンパイルが止まってしまいました。
実際の作業は、LDFLAGS, CPPFLAGS 等の環境変数を設定して、
./configure --prefix=[PREFIX] --enable-download
download/getall -a
make
make check
# make install
という作業をするだけです (すんなりいけば)。
「download/getall -a」が、
インストールされていないソフトをダウンロードして
チェックサムのチェックも行います。
なお、これらのスクリプトは perl で書かれていますが、
/usr/bin/perl を仮定していますので、
別な場所にある環境は、それらも修正が必要です。
まずは、download/nlopt/nlopt-2.2.4 のコンパイルで止まりました。
適当に修正してみたのですが、
make し直すと、またダウンロードしたファイルを展開しだすので、
結局修正が効かない、という状態になりますので、
その上位の Makefile を修正する必要があります。
例えば、nlopt の場合は、展開される download/nlopt/nlopt-2.2.4
内のファイルは、download/nlopt/Makefile に従ってコンパイルされるので、
まず download/nlopt/Makefile を修正して
patch 当て作業自体をその Makefile に書かないといけません。
Solaris 10 + gcc (4.7.2) では C++ 関連のエラーが何箇所かでました
(src/femlib/gmres.hpp, src/fflib/AFunction.cpp,
src/fflib/InitFunct.hpp)。
また、hdf5 のヘッダーファイルを $local/include でなく
$local/include/hdf5 を見てくれないためのエラーもありました
($local は hdf5 のインストール先)。
これは、configure 時に CPPFLAGS に -I$local/include/hdf5
を追加し、examples++-load/WHERE_LIBRARY-config の最後の
hdf5_INCLUDE にも追加しておきます。
さらに、make install で、examples++-load/ 内の作業で、
「./ff-get-dep: null directory」のようなメッセージがずらっと出ます。
これは、ff-get-dep というスクリプトで「cd ""」
というコマンドを実行している箇所があるのですが、
/bin/cd だとそれは通るようですが、
実際には csh builtin の cd が呼ばれてしまって、
それが理由でエラーとなっていました。
同じく examples++-load/ で、
「diff: WHERE_LIBRARY-download: ファイルもディレクトリもありません。」
というものもでましたが、それは Makefile を修正しました。
また、Solaris の ld では、shared library は
-R で置き場所を指定しないといけないことが多いのですが、
既にインストールされているライブラリ用の
-R がうまくついてくれず、なかなか苦労しました。
結局、少し強引に、環境変数 CXX と CC に直接 -R オプションをつけて
(CXX = "g++ -R$prefix/lib ..." 等) としてごまかしました。
ダウンロードされるものでパッチが必要だったのは scotch と nlopt
くらいですが、既にインストールされているライブラリによって
何をダウンロードするかは変わりますので、
環境によっては他にもパッチが必要なものもあるかもしれません。
うちでは、BLAS, ARPACK, GSL, HDF5, fftw
あたりは既にインストールしてあったものを使っています。
また、グラフを書く場合は OpenGL を使っていて、
Solaris には OpenGL は最初から入っていますが、
GLUT が必要になるので、
freeglut などを事前にインストールしておく必要があります。
使用したパッチと、作業手順を以下に置いておきます。
- 作業手順:
gunzip -c freefem++-3.38-1.tar.gz | gtar xvf -
cd freefem++-3.38-1
ln -s ../scotch-1.diff .
ln -s ../nlopt-1.diff .
patch -p1 < ../freefem-338-sol10-1.diff
set prefix = ~/freefem++-3.38-1
set local = /usr/local
setenv LDFLAGS "-L$local/lib"
setenv CPPFLAGS "-I$local/include -I$local/include/hdf5"
setenv CXX "g++ -L$local/lib -R$local/lib"
setenv CC "gcc -L$local/lib -R$local/lib"
./configure --prefix=$prefix --enable-download |& tee log0
vi examples++-load/WHERE_LIBRARY-config
(一番最後の行の hdf5 INCLUDE に -I$local/include/hdf5 を追加)
download/getall -a |& tee log1
make |& tee log2
make check |& tee log-check
make install |& tee log3
- パッチ
インストール後に、以下のサイトのセクション 2.2 にある
poisson.edp で試してみたところ、
ちゃんとその説明通りにグラフが表示されました。
なお、OpenGL による画面表示は、
インストールしたマシンでは正しく動作するのですが、
リモートの FreeBSD マシンからネットワーク経由で
X のクライアントとして FreeFem++ を動作させると
FreeBSD 上にはうまく表示されず、
以下のようなメッセージが出ます。
X Error of failed request: BadValue
(integer parameter out of range for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 24 ()
...
両者のマシンでは使っている OpenGL ライブラリもだいぶ違いますので、
X のプロトコルレベルでの問題などがあるのかもしれません。
- FreeBSD 10.2 の場合
現在の ports には FreeFem++ はないようなので、
自前でコンパイルしてみました。
10.2 ではデフォルトのコンパイラは clang のもの (3.4.1) ですが、
いくつかのライブラリのコンパイルに fortran が必要になるので、
gfortran を使用しました。
具体的には、ports から math/arpack をインストールすることで、
gcc (4.8.5), gfortran, arpack, blas
などがまとめてインストールされます。
さらに、math/gsl と、build/download スクリプトで必要になる
security/p5-Digest-MD5 もあらかじめ入れておきます。
もちろん、graphics/libGL, graphics/libGLU, graphics/freeglut
なども必要です。
また、make が gmake でないとコンパイルが通らないものがあるようですが、
Makefile に「make」と直接書いてあるものもあるので、
それらを手直しする代わりに、
path で /usr/bin/make などよりも前に ~/bin を参照するようにしておいて、
pushd ~/bin
ln -s /usr/local/bin/gmake make
popd
rehash
とでもして、「make」で GNU make が参照されるようにしておきます。
あとは Solaris と同様にいくつかパッチを当てることで
とりあえずコンパイルはできたのですが、
Solaris 同様 FreeFem++ に poisson.edp を食わせたら、
segmentation fault でコアダンプしました。
実際には、FreeFem++ が内部で呼びだす表示用のツール
ffglut がコアダンプするようです。
FreeFem++ は、-fglut オプションを使って、
ffglut に食わせるデータファイルを出力できます:
FreeFem++ -fglut data1 poisson.edp
ffglut data1
しかしこれもだめでした。
ffglut にオプションをつけずに実行しても、
segmentation fault で落ちました。
gdb や printf デバッグを試みたのですが、
どうも ffglut のソースの問題というよりも、
それが引いているライブラリに問題があるようです。
「ldd ffglut」で参照しているライブラリを見てわかりましたが、
ffglut が /usr/libc++.so と、/usr/local/lib/gcc48/libstdc++.so
の 2 種類の C++ クラスライブラリを参照していました。
これがぶつかっている可能性があります。
なぜこのようになっているかと言えば、
まず gfortran を入れたので gcc もインストールされていますので、
configure は clang の cc ではなく gcc、
clang の c++ でなく g++ を自動的に検出します。
そのため、g++ で今回コンパイルしたものは
/usr/local/lib/gcc48/libstdc++.so を使用します。
また、gfortran を使うために、LDFLAGS に
/usr/local/lib/gcc48 を見るようにも設定していました。
一方、FreeBSD 10.2 のデフォルトのコンパイラが clang であるため、
事前に FreeBSD にインストールしたライブラリの多くは
clang の cc, c++ でコンパイルされていて、
それらは /usr/libc++.so を使用している可能性があります。
実際、/usr/local/lib/libGLU.so が /usr/libc++.so を引いていました。
そのためにそれらを ffglut にリンクした際に
/usr/libc++.so と /usr/local/lib/gcc48/libstdc++.so
が一緒に参照されるようになってしまったようです。
仕方がないので、
「g++ バージョンの (libstdc++ を参照する) libGLU.so」を作って、
それを別のところに置いて、それを参照するようにすることにしました。
具体的には、ports の graphics/libGLU で
CC, CXX, PREFIX を指定してコンパイルして、
install は通常のインストール「ではない」作業を行います:
# set dir1 = [適当な場所]
# cd /usr/ports/graphics/libGLU
# make "CC=gcc" "CXX=g++"
"PREFIX=$dir1"
# ( cd work/glu-9.0.0 ;
make "prefix=$dir1" install )
# make clean
その後で、LDFLAGS に /usr/local/lib より前に
その場所を参照するようにしておけば、
そちらのライブラリを見ることになります。
rpath も設定しておく必要があると思います。
実際にやった作業とパッチは以下の通りです。
- 作業手順:
gunzip -c freefem++-3.44.tar.gz | gtar xvf -
cd freefem++-3.44
gpatch -p1 < ../freefem-344-fbsd102-1.diff
set prefix = ~/freefem++-3.44
set local = /usr/local
set gccd = $locald/lib/gcc48
set dir1 = [libGLU を入れた場所]
setenv LDFLAGS "-L$gccd -Wl,-rpath=$gccd"
setenv LDFLAGS "$LDFLAGS -L$dir1/lib -Wl,-rpath=$dir1/lib"
setenv LDFLAGS "$LDFLAGS -L$local/lib"
setenv CPPFLAGS "-I$local/include"
./configure --prefix=$prefix --enable-download --with-hdf5=no
|& tee log0
download/getall -a |& tee log1
make |& tee log2
make check |& tee log-check
make install |& tee log3
- パッチ
こちらのパッチでは、build/ にあるスクリプトの先頭部分のパス指定、
および configure スクリプトの expr に対する修正、
Makefile の m4 の指定順序の修正などとなっています。
make check でいくつか XFAIL となるものがありましたが、
とりあえず poisson.edp の表示は出るようになりました。
これも FreeBSD から FreeBSD へのリモートで
ffglut の表示を確認してみたのですが、
最初はうまく出ませんでした。
X クライアントの方は intel driver、
X サーバ側が mga driver で、
サーバ側では専用の DRI driver を使っていなかったので、
クライアント側でも DRI driver (/usr/local/lib/dri/i915_dri.so)
を使わないようにしたら、
逆にちゃんとリモートでも表示できるようになりました。
まだ両者ともそれほどテストはしていませんが、
とりあえずは使えるようになったようです。
なお、今回は ffglut という OpenGL を利用するソフトで多少苦労しましたが、
FreeFem++ の src/Graphics/ というディレクトリに Xrgraph.cpp
という X 用のソースがあります。
どうやら以前のバージョン (FreeFem++-3.23 以前あたり)
で使用していたソースらしいのですが、現在は使用されていません
(同等のソースがほかにも置かれているようです)。
試しに FreeFem++-3.20 をコンパイルしてみたら、
そちらには src/x11 というディレクトリに FreeFem++-x11 という
OpenGL でなく X を直接使うバージョンが作られ、
それは普通に表示してくれました。
せっかくなら、OpenGL がうまく使えない環境のために
FreeFem++-x11 用の Makefile
くらい残しておいてくれてもいいような気がします。
残念ながら 3.20 の src/x11 の Makefile を単純に
3.44 に持ってきただけでは、うまくコンパイルできませんでした。
時間があるときにでもまた試してみたいと思います。
さらに、FreeFem++ は ffglut 以外の表示ツールを
オプションで選択することもできるようになっているので、
OpenGL を利用しない X 用のクライアントを置いてくれてもいいように思います。
Xrgraph.cpp を -DFREEFEM
つきでコンパイルすればそうなるのかなと思ったのですが、
それもうまくいきませんでした。
そのあたりも時間のあるときにでもまた調べてみたいと思います。
(cf. 「Unix に関するメモ等 (03/18 2016)」)
- (02/25 2016)
(しおり用)
「Unix に関するメモ等 (02/07 2015)」
にも書きましたが、久しぶりに Blade 150 を立ち上げたら
2, 3 台まとめて NVRAM が干上がってました。
ほぼ以前と同等の作業をやりましたが、
2 点ほど注意点を書いておきます。
ひとつは電池です。最初にやったとき
(「Unix に関するメモ等 (10/13 2014)」) は、
NVRAM の電源端子に導線をハンダ付けし、
その導線に NVRAM 用の電池 (CR-2032) を直接ハンダ付けしました。
しかし、電池に熱を与えるのはよくないらしいので、
2 回目 (「Unix に関するメモ等 (02/07 2015)」)
にやったときは、実は導線の先に CR-2032 を接触させて適当に
セロハンテープをまいていました。
本当は電池ホルダーを使えばいいのでしょうが、
売っている店が近くにはなさそうだったので、
とりあえずそうしていたのですが、今回そのマシンも止まっていました。
開けてみたら見事にテープで止めたはずの導線が外れていました。
今回のために電池ホルダーを 5 つ位手に入れてあったので、
それを使って今回はつなぎ直しました。
ところが、今度は一つ結線を逆にしてつないでしまいました。
幸い今のところ NVRAM が壊れたりはしていないようですが、
危険だったかもしれません。
もう一点は、
「Unix に関するメモ等 (10/13 2014)」
にも書いてある、『ok プロンプトで「set-defaults して」』の部分です。
うかつにも 1 台、最初に「set-defaults」するのを忘れて
作業を進め、書き終えた後で boot してみたのですが、
ネットワークブートしようとしたので、
あれおかしいな、とそのまま一旦電源を落として再立ち上げしてみました。
すると、今度は全く立ち上がらなくなりました。
HD やファンは回っているみたいなんですが、画面は黒いまま何も出ない、
電源ランプもつかない、といった状態で、
もしや Blade 150 が死んだのかと思ったくらいです。
他の同様のマシンの NVRAM の復帰作業をやっているときに
「set-defaults」しないといけなかったことに気がつき、
立ち上がらなくなったマシンで NVRAM を抜いてから刺し直してみたのですが、
まだ変化ありません。
結局、NVRAM につけた電池を一旦外して NVRAM を初期状態にして、
それからブートし直したらようやく ok プロンプト画面を出すことができました。
ちょっとした手順を忘れるだけで、
結構はまってしまいます。今回の対処も、
NVRAM から電池が簡単に外せる状態になってたから復旧できたわけですが、
新しい NVRAM でも買ってやっていた作業だったらどうなったか、
と思うと少し恐いです
(しかし、今ごろこんな NVRAM は新品では買えないだろうから、
そういう心配は必要ないかな ?)
- (06/05 2015)
(しおり用)
Solaris 10 でやや妙な現象に会っています。
z = atan2(y, x) という数学関数がありますが、
これはよく「y/x の逆正接 (アークタンジェント)」と説明されていますが、
値の範囲は -π ≦ z ≦ π の範囲、となっているので実際は少し違います。
通常アークタンジェント (z = arctan x, tan-1 x) は、
-π/2 ＜ z ＜ π/2 範囲の値を返します。
正確には、z = atan2(y, x) の値は、
(x, y) という点の原点から見た偏角を意味します。
すなわち、原点と (x, y) との距離
r = (x2 + y2)1/2 に対し、
x = r*cos(z), y = r*sin(z) が成り立つ角、を意味しています。
とすると、本来その値が一意に決まるためには 2π幅の半開区間、
例えば -π ＜ z ≦ π であるべきなのですが、
-πの方にも等号がつく理由はマニュアルを参照するとわかります。
最近のコンピュータでは、「符号つきのゼロ」を許していて (例えば IEEE 754)、
-0 が +0 と区別されています。
Solaris 10 のマニュアルでも、atan2(y, x) の値は、
「y が ±0 で x < 0 の場合は ±πになる」と書かれています。
偏角を -π ≦ z ≦ π で考える場合、x 軸の負軸がその境目になるので、
y が +0 (= 0) のときはπ、-0 のときは -πとなるのは
極限から考えても自然です。
実際、Solaris10 上の gcc 4.7.2 で atan2(0, -1), atan2(-0, -1)
の値を計算させると、それぞれπ、-π、となります。
この挙動は FreeBSD でも同じです。
問題は、x, y が±0 の場合です。
以前はこのような値では角を未定義として
エラーを出していた場合もあったようですが、
最近の atan2() はそれなりに適切な値を返します。
FreeBSD でも、Solaris でも、マニュアルでは
以下のような値を返すことになっています。
- atan2(+0, +0) = 0
- atan2(-0, +0) = 0
- atan2(+0, -0) = π
- atan2(-0, -0) = -π
そして実際、そういうソースを書くとそういう値が返るのですが、
なぜか以下のソースで、うちの Solaris 10 + gcc-4.7.2
はおかしなことが起こります。
#include <stdio.h>
#include <math.h>
int main(void)
{
double xp = 0.0, xm = -0.0;
printf("(1) atan2(+0, -0) = %f\n", atan2(+0.0, -0.0));
printf("(2) atan2(-0, -0) = %f\n", atan2(-0.0, -0.0));
printf("(3) atan2(+0, -0) = %f\n", atan2(xp, xm));
printf("(4) atan2(-0, -0) = %f\n", atan2(xm, xm));
return 0;
}
(1), (2) は期待通りにπと -πが出力されるのですが、
(3), (4) はなんと 0 が出力されます。
FreeBSD ではもちろん (3), (4) もπと -πが出力されます。
「定数」ではいいのに、「変数」だとだめ、という変な状況になっています。
なぜそうなるのか、そういうことが起こりうるのか全くわかりません。
マニュアルからすれば (3), (4) がおかしいのですが、
Solaris 10 の atan2() のマニュアルは、「c99」とか書いてあるので、
もしかすると gcc ではだめなのかもしれません。
なお、Solaris10 の man atan2() では、long double 版の atan2l(),
float 版の atan2f() も表示され、それらでも double を long double,
float に変えたもので試してみましたが、
atan2f(), atan2l() はそれぞれ問題なく (Solaris 10 + gcc-4.7.2)、
(3), (4) も正しく π、-πが出力されます。
つまり問題があるのは double 版の atan2() だけです。
(つまり、問題の回避策として、(double)atan2l() で代用する、
という手はあります。)
Solaris 10 の atan2() の問題なのか、gcc との相性の問題なのか、
ちょっと今のところわかりません。
ところで、これは gawk でのテストで気がつきました。
gawk にも atan2() が用意されているのですが、
それは内部で OS (標準数学ライブラリ) が提供する atan2() を
「変数」代入の形で使いますので、この問題が gawk でも再現します。
なお、最新の gawk-4.1.3 には任意精度計算を行える -M (--bignum)
オプションなるものがついていて、
それを指定すると標準ライブラリの代わりに GNU MPFR, GNU MP
ライブラリを使用します。
この場合は atan2() も標準的ではないものに切り替わるためか、
問題は起きませんでした。つまり -M では gawk では
(3), (4) のようなコードでもπと -πが返ります。
ただ、この問題はたまたま見つけただけで、
もちろんなんらかの実害がでているわけではありません。
- (02/07 2015)
(しおり用)
「Unix に関するメモ等 (10/13 2014)」
に続いて、もう一台 Blade 150 の NVRAM の電池が切れました。
今回はやる作業はわかっていたので、修理はあっという間に終わりました。
しかも、今回は前回の失敗を教訓にして、
- IC ソケットを使用した
- 彫刻刀ではなく金属加工用のヤスリ (棒やすり) を使って削った
としたため、安全でしたし、ピンも折れませんでしたし、
あっという間に終わりました。
IC ソケットは、NVRAM が 28 ピンなので、
それより少し足の多いもの用のものを他の研究室の方からゆずって頂きました
(実は柏崎だと手に入れにくい)。
これで足を折らずに済みますし、
さらにソケットを段ボールなどに刺して作業すれば
NVRAM を固定することもできるので、前回よりも作業がかなり楽になりました。
万力がいるかなとか考えていたのですが、
全く必要ありませんでした。
また、前回は彫刻刀を使ったのですが、一回指に刺してしまいました。
棒ヤスリ、特に新しいものは簡単に削ってくれます。
5 分もすれば金属部分に達し、
接続先を露出させて内蔵電池との接点を切るのに
30 分とかかりませんでした。
あと 4,5 台 Blade 150 等の Sun のワークステーションがありますが、
おかげでこの後もあまり不安はなくなりました。
(cf. 「Unix に関するメモ等 (02/25 2016)」)
- (10/13 2014)
(しおり用)
うちの研究室の Sun Blade 150 の NVRAM の電池が切れてしまいました。
その交換の話を備忘録もかねてここにまとめておきます。
なお、NVRAM の電池切れの対応については
既にいくつかのサイトで情報があがっていますが、
それらとは違う状況もありますので、無益ではなかろうと思います。
なお、これを参考にする場合は、もちろん自己責任でお願いいたします。
まず、うちの Blade 150 の一台が、
以下のようなものがでてブートしなくなりました。
The IDPROM contents are invalid
Power On Self Test failed. Cause: NVRAM U13
Aborting auto-boot sequence
調べると、NVRAM の電池切れのようです。
使用している NVRAM は M48T59Y-70PC1 ですが、すでに生産終了品のようで、
有名どころのパーツ屋の Web ページにも見当たらず、
メールで 1 件連絡してみたのですが、やはり手に入らないと断わられました。
やや面倒そうですが、いくつかのサイトで「NVRAM を分解して電池交換する」
という話も紹介されていますので、
だめもとでそれをやってみることにしました。
なお、hostID と mac-address はあらかじめ記録してあったので
とりあえずは良かったですが、
NVRAM に貼ってあるバーコードシールで mac address はわかりますし、
hostID もほぼその mac address と一定のルールで知ることは可能です。
NVRAM の電池交換については、以下のサイトを参考にしました。
NVRAM の型番が同じ [b]
のサイトを主に参考にして、
彫刻刀で端子を削り出して、中に入ってる電池への接続をニッパーで切って、
端子とリチウム電池 (3V の CR2032) をリード線でつなぎました。
リチウム電池ケースはすぐには手に入らないので、
リード線は直接リチウム電池にはんだずけしましたが、
後から考えたらテープで巻く程度でも良かったかもしれません。
彫刻刀で削る作業は、ある程度力もいりますし、
NVRAM の足を折らないようにするのが面倒で、かなり大変でした。
なお、その後 NVRAM を差すときに、
元からついていた NVRAM のカバーのようなものを使ったのですが、
NVRAM の足が少し曲がっていたようでうまく刺さらず、
強引に押したら足を 1 本折ってしまいました。
仕方がないので、そこからもリード線を伸ばして
むりやり IC ソケットにはんだメッキしたリード線を刺してます。
NVRAM カバーは使わずに足を見ながら刺した方が無難かもしれません。
さて、ここからの作業については
[b] にはあまり書いてなくて、
[a] や、
以下のサイトを参考にしてみました。
易しそうなのですが、Blade 150 の場合は実はここからも問題があります。
基本的には、ok プロンプトで「set-defaults して、
mkp で hostID と mac address の値を書いていって、ブートするだけ」
という感じで書いてありますが、
実は Blade 150 ではその mkp がうまくいきません。
それについては、以下にも書かれています。
Blade 150 は最初から OpenBoot のバージョンが 4.x なのですが、
それが原因のようだと書かれています。
このサイトには、よってうまくいく方法がわからない、のように書いてあります。
仕方がないので、
[e] の FAQ にある別の方法の、
「Other more arcane methods for modifying the IDPROM」
というセクションのところを試してみることにしました。
これは、mkp でなく、cl か c! で直接 eeprom に書く、という方法です。
結果から言えばこれでうまくいきました。
行った手順を順に追いながら説明します。
- ブートすると ok プロンプトで止まるので、そこで「set-defaults」する
- 次に「show-devs」して、eeprom の場所を探す
うちの Blade 150 の場合は、
/pci@if,0/ebus@c/eeprom@1,0
のように見つかりました。
- 「cd /pci@if,0/ebus@c/eeprom@1,0」して「.properties」を実行
うちでは以下のように表示されます。
model mk48t59
address fff4a000
reg 00000001 00000000 00002000
device_type nvram
name eeprom
- 「device-end」する
大事なのは、この address です。
この後、
[e] の FAQ では、
map-page を使って IDPROM の物理アドレスを仮想アドレスにマップして、
cl (c!) で書き込むという説明があるのですが、
その物理アドレスを調べるコマンド
「fff4a000 pgmap?」がうまくいきませんでした。
OpenBoot 4.x のマニュアル (816-1177-10) を見ると、
一応 pgmap? はあるようなのですが、どうも使えません。
仕方がないので、直接 fff4a000 から始まる該当するアドレス部分に
c! を使って書きこんでみることにしました
(OpenBoot 4.x では cl ではなく c! のよう)。
sun4u のマシンでは、その部分のオフセットは 0x1fd8 だとあります。
実際、fff4a000 + 1fd8 = fff4bfd8 のあたりを
「fff4bfd0 20 dump」のようにして見てみると、
確かに現在の変な設定 (「.idprom」で確認できる)
であるメモリの並びが現れます。
よって、その部分を c! で直接書き換えてみることにしました。
ok> 01 fff4bfd8 c!
ok> 83 fff4bfd9 c!
...
最後の 16 byte 目の fff4bfe7 は checksum なのですが、
それはこの 15 byte の XOR のようなので、
FORTH で計算させる、というのが上の資料には書いてあるのですが、
別のプログラムで計算した値を書き込みました。
このあと、「.idprom」しても値は変わっていませんが、
「fff4bfd0 20 dump」で正しい値が書かれていることを確認したあと、
ブートするとちゃんと mac address と hostID が正しく設定された状態で
OS がちゃんと起動されました。
なお、本当はブートの前に日付を「date ...」で設定するらしいのですが、
うちは ntpdate を使っているので、その手順は省略しました。
実際、時刻の設定は問題なく ntpdate で行えたようです。
これでまたしばらくはこの Blade 150 も使えそうです
(ここまでして使う必要はあるのか...)
(cf. 「Unix に関するメモ等 (02/07 2015)」,
「Unix に関するメモ等 (02/25 2016)」)
- (09/12 2014)
(しおり用)
octave-3.8.1 を Solaris 10 + gcc-4.7.2 でコンパイルするときに
色々苦労しました。長いですが、備忘録代わりにここにまとめておきます。
まず、octave が必要とするライブラリをいくつかインストールしたのですが、
以下はそれほど問題はありませんでした。
- gperf-3.0.4
- fftw-3.3.4 (configure に
--enable-shared をつけて
install して、make clean 後に
--enable-single --enable-shared で install するくらい)
- glpk-4.54
- GraphicsMagick-1.3.19 (
--enable-shared をつけるくらい)
しかし、以下はいくつか問題があり、
自前のパッチを当てるなどを行っています。
- hdf5-1.8.13
setenv CXX g++ (tcsh 環境なので),
setenv FC gfortran した上で configure に
--enable-fortran --enable-cxx をつけるのですが、
そのままだと CFLAGS に -std=c99 が入ってしまったり、
Solaris の native コンパイラ用のフラグがついたりしてしまいますので、
configure 前に config/solaris2.x に以下のパッチを当てています。
- qhull-2012.1
Solaris では、リンカオプションとして、
shared ライブラリの置き場所を
-R で指定してオブジェクトに埋め込む必要があり、
configure 時にはよく「setenv LDFLAGS -R/usr/local/lib」
のようなものを使うのですが、
qhull は configure 系ではないのでそれができず、
make のオプションとして指定する必要があります。
調べると、CC_OPTS2, CC_OPTS3, CXX_OPTS2 に入れる必要がありそうだったので、
make "DESTDIR=/hoge/fuga" \
"CC_OPTS2=-R/usr/local/lib:/hoge/fuga/lib" \
"CC_OPTS3=-R/usr/local/lib:/hoge/fuga/lib" \
"CXX_OPTS2=-R/usr/local/lib:/hoge/fuga/lib"
のような形で make と instal を行っています
(実際のインストール先は /usr/local/lib でも /hoge/fuga でもないです)。
- gl2ps-1.3.8
これはいまどきのフリーソフトには珍しく、configure もなければ、
Makefile すらありません。
よって自前でコンパイルする必要がありますが、以下のようにやりました。
set opt = "-g -O3 -shared -fPIC -DPIC -DHAVE_ZLIB -DHAVE_PNG"
set prefix = /hoge/fuga
gcc -Wall -c $opt -o gl2ps.o gl2ps.c
gcc $opt -o libgl2ps.so gl2ps.o -lGL -lpng -lz -lm
#install -c -m 0755 libgl2ps.so $prefix/lib
#install -c -m 0644 gl2ps.h $prefix/include
最後の 2 行は root での作業です。
ライブラリの作成部分 (4 行目) は、環境によっては
-L, -R のオプションを追加する必要があるかもしれません。
- fltk-1.3.2
これは、dillo 用に static ライブラリを入れてあったのですが、
後で shared ライブラリが必要なことがわかりましたので、
--enable-shared で shared ライブラリを作りましたが、
configure 時に LDFLAGS を設定して -L, -R などを指定していたのですが、
それが shared ライブラリ作成のリンカオプションに反映されないので、
make 時に「make 'DSOFLAGS+=$(LDFLAGS)'」
(環境変数が参照されないように '' で囲む) などとする必要がありました
(GNU make)。
- blas, lapack-3.5.0
これも後で shared ライブラリが必要なことがわかりましたので、
share ライブラリを作るようにしましたが、
標準の Makefile にはそのオプションが書いてなかったので、
適当にやりました。
BLAS の方は、make.inc に以下のパッチを当てて make しました。
/usr/local/lib などは適当に変える必要があるかもしれません。
make 後に blas_SOLARIS.so を libblas.so として install
(-m 0755) します。
LAPACK (lapack-3.5.0) の方はもう少し面倒で、
make.inc.example を make.inc にコピーして make するのですが、
サブディレクトリまで含めた Makefile ツリーがやや未熟なので、
一旦 lapack-3.5.0 から上に出て、
cd ..
ln -s lapack-3.5.0/liblapack.so .
ln -s lapack-3.5.0/libtmglib.so .
と、少し妙なリンクを貼ってやる必要があります。
これは、途中で作られるテストプログラムの
make される作成場所と実行される場所が違うために、
実行時に shared ライブラリが見つからない、
という問題を解消するための措置です。
もちろん他の対処もあると思います。
また、それ以外に以下のパッチも必要でした。
-frecursive を取っているのは test プログラム (xeighstz) の
segmentation faults を避けるためで、
後はだいたい shared ライブラリ生成用の変更です。
ライブラリの場所などは適宜変更が必要かもしれません。
make と make lapacke_example を実行し、
liblapack.so, liblapacke.so, libtmglib.so を手動で install しました。
- arpack-ng-3.1.5
これは、デフォルトで shared ライブラリを作りますが、
以下のパッチを使いました。
これは、Makefile の $(LAPACK_LIBS) と
$(BLAS_LIBS) の参照順をすべて入れ替えるものです。
うちの環境ではそうでないとだめだったようです (確か)。
他の、pcre, readline, curl, freetype, gnuplot, qt, fontconfig, zlib, OpenGL
などは、OS に付属しているものや、
別の機会に既にインストールしてあったものを利用しています。
その後、いよいよ octave-3.8.1 の make ですが、
これもいくつか問題がありました。
- 以下のようなものがでる:
../../libgnu/stdio.h:1034:1: error: 'char* gets(char*)'
conflicts with previous using declaration 'char* std::gets(char*)'
make[4]: *** [Faddeeva/libcruft_la-Faddeeva.lo] Error 1
これは、libgnu/stdio.in.h にある gets の部分に問題があるようなので、
そこをコメントアウトして済ませました
(後述のパッチ参照)。
- static のライブラリしかないと symbol 参照エラーが出る
実は最初は BLAS, LAPACK や fftw, fltk, GraphicsMagick などは
デフォルト通りに static のものしか作ってなかったのですが、
それだと参照エラーが大量に出ます。
それでライブラリをすべて shared に作り直しました。
- libinterp 内で以下のようなものが出る
octave-value/ov-usr-fcn.cc:785:42: error:
'Fwarning' was not declared in this scope
この F なんとかっていうものは、インターネット上には
libinterp/builtin-defun-decls.h を消せ、
とかいう情報があったのですが、結局は make が自動的に作成する
libinterp/builtin-defun-decls.h が正しく作られていないために
このメッセージがでることがわかりました。
色々と調べてみたのですが、
最終的には、libinterp の Makefile 内で実行しているシェルスクリプト
libinterp/find-defun-files.sh 等が、
「/bin/sh」のシェルスクリプトなのに、
実際には bash スクリプトである (bash でないとうまく動かない)、
という問題であることがわかりました。
この手の問題は実は最近はありがちで、
今は Unix のフリーソフトの作者や Unix ユーザは
大半が Linux ユーザだと思いますが、
Linux では /bin/sh = bash が普通なので、
Unix 用に書かれたフリーソフトに付属する B-shell スクリプトが
bash 方言を使っていることが良くあります。
その場合、/bin/sh が bash ではない
Solaris や FreeBSD ではうまく動かない事例が発生するわけです。
make 時に「make 'SHELL=/bin/bash'」とすると、
そのスクリプトの起動は確かに /bin/bash -c
でやってくれるようになるのですが、
/bin/bash -c だと、そのスクリプトの 1 行目に書かれた
「#!/bin/sh」がまた起動されてしまうので、
結局それらのスクリプトの 1 行目の /bin/sh を、
全部 /bin/bash に直す必要があります
(後述のパッチ参照)。
- libinterp/corefcn/oct-stream.cc で以下のようなものがでる:
corefcn/oct-stream.cc: At global scope:
corefcn/oct-stream.cc:3656:1: error: duplicate explicit
instantiation of 'octave_idx_type octave_stream::write(const
Array<T>&, octave_idx_type, oct_data_conv::data_type,
octave_idx_type, oct_mach_info::float_format)
[with T = char; octave_idx_type = int]' [-fpermissive]
これは、libinterp/corefcn/oct-stream.cc 内の
「INSTTANTIATE_WRITE (char)」
というテンプレートが問題のようなので、
とりあえずそれをコメントアウトすることで回避しています
(後述のパッチ参照)。
- libinterp/corefcn/toplev.cc で以下のようなものがでる:
corefcn/toplev.cc: In function 'int wait_for_input(int)':
corefcn/toplev.cc:843:16: error: 'select' is not a member of 'gnulib'
corefcn/toplev.cc:843:16: note: suggested alternative:
In file included from ../libgnu/sys/select.h:36:0,
from /usr/include/sys/types.h:606,
from ../libgnu/sys/types.h:27,
from /usr/include/sys/wait.h:20,
from /usr/include/stdlib.h:22,
from ../libgnu/stdlib.h:36,
from
/usr/local/bin/../lib/gcc/sparc-sun-solaris2.10/4.7.2/../../../../include/c++/4.7.2/cstdlib:66,
from corefcn/toplev.cc:29:
/usr/include/sys/select.h:140:12: note: 'select'
これは、libgnu/sys/select.h で
__sun によって Solaris 用の条件分岐しているプリプロセッサ部分が
悪さをしているようなので、そこを逆に __sun なら見ないようにして
回避しました
(後述のパッチ参照)。
- libgui 内で以下のようなものがでる:
make[2]: Entering directory `/hoge/fuga/octave-3.8.1/libgui'
uic -o src/ui-settings-dialog.h src/settings-dialog.ui
/bin/bash: uic: command not found
make[2]: *** [src/ui-settings-dialog.h] Error 127
これは、uic は qt の付属のバイナリなのですが、
qt (4.7.4) や fltk (1.3.2) のライブラリの場所は指定していたものの、
付属バイナリの置き場所にパスを通してなかったことが問題でした。
うちでは、少し変なところにインストールしていて、
通常はそこにパスを通していないのでこういう問題が起きます。
これは単に make の前に
「set path = ( $path $fltkdir/bin $qtdir/bin )」
とするだけです。
- libgui 内で以下のようなものがでる:
qterminal/libqterminal/unix/kpty.cpp:
In member function 'bool KPty::open()':
qterminal/libqterminal/unix/kpty.cpp:379:21:
error: 'I_PUSH' was not declared in this scope
make[3]: ***
[qterminal/libqterminal/unix/qterminal_libqterminal_la-kpty.lo]
Error 1
これは、Solaris 10 では kpty.cpp のコンパイルには
「-DHAVE_UTMPX -DHAVE_SYS_STROPTS_H」が必要そうなのに、
それが (config.h などに ?) ついていないためのもののようです。
しかたがないので、強制的に libgui/Makefile の
CXXFLAGS にそれを追加して回避しています
(後述のパッチ参照)。
これらのうち、特に 2., 3. が苦労しました。
2. は、上にも書きましたが、いざ shared ライブラリを作ろうと思ったら
Makefile に何も shared ライブラリの記述がないソフトもあったりして、
しかも一つ一つのライブラリもコンパイルにかなり時間がかかるので、
それ自体で数日かかりました。
3. も、最初は libinterp/builtin-defun-decls.h に
必要なエントリがないことに気がついたので、
必要そうなエントリを、最初は手動で、次は Makefile を細工して
作るようにしてみたのですが、実行バイナリがうまく動かないとか、
doc/ の方でも似たような問題 (make が自動的に作る libinterp/DOCSTRINGS
のエントリに抜けがある) とかが発生したので、
よくよく調べてみて (GNU make のソースまでみた) 上のことがわかりました。
ちなみに、実行バイナリがうまく動かない、というのは octave 起動時に、
error: 'nargin' undefined near line 35 column 7
error: called from:
error: /usr/local/share/octave/3.8.1/m/help/__unimplemented__.m
at line 35, column 3
error: /usr/local/lib/octave/3.8.1/oct/sparc-sun-solaris2.10/PKG_ADD
at line 1, column 1
のようなものがでる症状でした。検索してもよくわかりませんでしたが、
何か抜けてる感じがしたので、
「抜け」を解消することを考えて結果的に 3. のように対処しました。
とりあえず、現在は簡単な octave の命令は通るようになっていますし、
グラフもとりあえず描けました。
octave-3.8.1 用の全体のパッチを以下に置きます。
- (07/14 2014)
(しおり用)
うちの Web サーバは、FreeBSD + Apache で構成していますが、
先日 FreeBSD のバージョンを上げたところ、不具合が生じました。
FreeBSD に起因するものなのか、Apache の問題なのかよくわかりませんので、
とりあえず FreeBSD のページよりもむしろこの辺に書いておきます。
従来、FreeBSD-8.4 + Apache Httpd 2.4.9 で運用していたときは
筑に問題はなかったのですが、
今回 OS を FreeBSD-10.0 にバージョンアップして、
同じ Apache 2.4.9 で同じ設定で運用を始めたら、
ブラウザで見るといくつかのページが「接続中」のまま
何も起こらない状態になりました。
Apache は、ports ではなく、自前でコンパイル、インストールしているのですが、
FreeBSD 10 では C コンパイラが gcc から FreeBSD clang (3.3)
に変わっているので、
gcc を入れてそちらで再コンパイルしてみましたが変わりませんし、
configure のバグ (freebsd10 が freebsd1 と認識される)
を修正しても変化なし、
ports の Apache でも同じ症状が起きるようでした。
実際には問題が起きるページと起きないページがあるようだったので、
その症状などを細かくみてみると、以下のような感じでした。
- 比較的新しいブラウザによる HTTP/1.1 でのアクセスでその問題が起き、
古いブラウザによる HTTP/1.0 だと問題は起きない
- apache のログを見ても、特に問題は起きているように見えず、
接続中のファイルも status は 200 になっている
- wget (HTTP/1.1) で確認すると、
ダウンロードできるのは 3820 byte 以上のサイズのファイルで、
ダウンロードできないのは 3819 byte 以下のファイル
(mod_gzip などは使用していない)
Web で検索してみましたが、残念ながら似たような事例は見つかりませんでした。
FreeBSD 10 では DNS 回りもだいぶ変更されているので
(bind 系ではなくなり、nslookup などもデフォルトで入ってない)、
HTTP/1.1 で必要となる (らしい) 名前解決の問題かと思いましたが、
よくわかりませんでした。
HTTP/1.1 でだめで HTTP/1.0 でよい、というあたりを検索したところ、
KeepAlive の設定の話が見つかりましたので、
試しに KeepAlive を Off にしてみたら、
とりあえず問題は解消したようです。
別な問題は起きるかもしれませんが、とりあえずはこれで運用したいと思います。
- (01/29 2014)
(しおり用)
CVS 版 gnuplot 用に、Solaris 10 で
libcaca の新しいものをコンパイルしたのですが、
その際の問題点などを書いておきます。
まず、giflib 4.2.3 をコンパイルしたのですが、
configure で X11/Xutil.h チェックに失敗し、以下のようなものが出ます。
checking X11/Xutil.h usability... no
checking X11/Xutil.h presence... yes
configure: WARNING: X11/Xutil.h: present but cannot be compiled
configure: WARNING: X11/Xutil.h: check for missing prerequisite headers?
configure: WARNING: X11/Xutil.h: see the Autoconf documentation
configure: WARNING: X11/Xutil.h: section "Present But Cannot Be Compiled"
configure: WARNING: X11/Xutil.h: proceeding with the compiler's result
configure: WARNING: ## ------------------------------ ##
configure: WARNING: ## Report this to esr@thyrsus.com ##
configure: WARNING: ## ------------------------------ ##
checking for X11/Xutil.h... no
これは、Solaris (10) の X11/Xutil.h (/usr/openwin/include) が、
内部で X11/Xlib.h をインクルードしていないために起きている問題です。
いくつかのソフトの configure で起きるので、
直接システムの X11/Xutil.h を修正してもいいのかもしれませんが、
私は configure の方で、X11/Xutil.h をチェックするときに
X11/Xlib.h もインクルードするように修正を入れることで対処しました。
以下がその差分です。
また、make の最後の方で xmlto がない、と言われました。
ドキュメントの生成に関係するもののようで、
xmlto をインストールすれば解消するのでしょうが、
これを入れるには他にも色々入れないといけないようです。
調べると、ドキュメント等には書いてないのですが、
Makefile に対処法が書かれていて、単なる「make」の代わりに
「make coverity」とすれば xmlto を使う以外の
make 作業をやってくれるようです。
次は imlib2 1.4.6 をコンパイルしましたが、
src/bin/imlib2_view.c のコンパイルの際に、
XK_q が定義されていない、とか出てきました。
これは、Solaris (10) の X11/Xutil.h (/usr/openwin/include) が、
内部で X11/keysym.h をインクルードしていないために起きている問題です。
ヘッダで、X11/Xutil.h のインクルードの次あたりに
X11/keysym.h をインクルードすれば解消します。
また、その次の libcaca のコンパイルの際に、
「gcc: エラー: @my_libs@: ファイルもディレクトリもありません。」
とか言われたのですが、良く調べるとこれも imlib2 の問題のようで、
imlib2 のインストール時の設定を教えてくれる imlib2-config
(ソース配布では imlib2-config.in) スクリプトの中に、
--libs のオプションのときの出力部分にこの「@my_libs@」が書かれています。
通常こういった変数は、
インストール前に実際の値に置き換えられてからインストールされるのですが、
@my_libs@ は置き換えられる仕組みが作られていないみたいで、
よって手動で書き直さないといけません (ドキュメントにも書いてありません)。
この @my_libs@ をコンパイル時に使用した
LDFLAGS の値などに置き換えて書き直すことで、この問題を解消できました。
これでようやく libcaca ですが、
gnuplot が要求するのは、安定版の古い libcaca-0.9 ではなく、
新しい 0.99.beta15 以降のようなので、
最新の 0.99.beta18 をコンパイルしました。
C++, Python, Java, Ruby などへの対応も含まれているらしく、
configure がそれらの check などもやるのですが、
それらも曲者です。
- Ruby は、1.8 あたりを想定しているようで、
Ruby 1.9 あたりをインストールしていると、
libcaca の configure が Ruby のヘッダファイルの置き場所を
正しく検出してくれないし、
struct RArray が len というメンバを持たない、というエラーもでる
(これも 1.8 のよう)。
- Java 関係は、
コンパイル時に「fatal error: caca.h: No such file or directory」
とかいうエラーが出る。単に Makefile が不出来なだけのような気もする。
- Python 関係は、インストール時にエラーが出る。
ということで、これらは結局全部 disable にして
「--disable-ruby --disable-java --diable-python」を
configure オプションに追加しました。
さらに、/usr/lib の pango や、/usr/sfw の freetype もうまく探せない、
socket 系のライブラリのリンクもちゃんとやってくれない、
といったことがあり、
setenv LDFLAGS -R/usr/sfw/lib
setenv LIBS "-lsocket -lnsl"
setenv PKG_CONFIG_PATH /usr/lib/pkgconfig
を configure の前にする必要がありました (ちなみにうちは tcsh 環境)。
実際には、ncurses (ncursesw) も有効にしましたので、
LDFLAGS にはその場所も追加していますし、
CPPFLAGS にそのヘッダーファイルの場所も設定しています。
そしてもう一つ、上の giflib の場合と同様の X 関係のヘッダファイル
(X11/XKBlib.h) のチェックの際に失敗するので、
giflib の場合と同様の修正を configure にほどこしました:
説明の順が前後してわかりにくいかもしれませんが、
結局 setenv ... を行って、configure に上のパッチを当てて、
そして --disable-... のオプションつきで configure を実行しました。
Ruby や Python 用のものもコンパイルしたい場合は、
より色々修正が必要かもしれません (が、私はやっていません)。
とりあえずこれでようやく libcaca が使えるようになりました。
CVS 版 gnuplot でもちゃんと使えているようです。
- (01/14 2014)
(しおり用)
あまりネット上にも情報がありませんでしたので、
ここに備忘録として書いておきます。
FreeBSD 上で普段 PDF ファイルを見るときは acroread ではなく、
xpdf (3.02) を使っています。
たまに日本語フォントがないとか言われることがありますが、
それに応じて ~/.xpdfrc に displayNamedCIDFontTT
に代用フォントを設定していけばいいだけで、
段々そういうものは出なくなってきます。
以前は、印刷するときは acroread を使っていたのですが、
最近 xpdf 上でそのまま印刷もやるようになりました。
ただ、Windows 上の TeX ユーザからもらった PDF ファイルを
xpdf で印刷しようとすると
Error: Couldn't find a font to substitute for
'GothicBBB-Medium-Identity-H' ('Adobe-Japan1' character collection)
Error: Couldn't find a font to substitute for
'Ryumin-Light-Identity-H' ('Adobe-Japan1' character collection)
と出て、印刷も日本語が化けるような状態になっていました。
要するに印刷の場合の代用フォントが見つかっていないようです。
実際には、xpdf ではなく pdftops が出しているメッセージのようですが、
pdftops は xpdf 付属のツールで、やはり ~/.xpdfrc を見ています。
man xpdfrc などを調べた結果、結局 ~/.xpdfrc に
psNamedFont16 Ryumin-Light-Identity-H H
Ryumin-Light-H ISO-2022-JP
psNamedFont16 GothicBBB-Medium-Identity-H H
GothicBBB-Medium-H ISO-2022-JP
のようなものを入れるといいことがわかりました
(詳しくは man xpdfrc 参照)。
他にも、文字集合毎に代用 PS フォントを設定する psFont16 や
フォント名の置き換えだけを行う psFont という設定コマンドもありますが、
明朝とゴシックなどのフォント毎の対応をするには
psNamedFont16 を使うのが良さそうです。
ただし、新しい xpdf-3.03 ではこれらは設定の名前が変わっている、
といったような情報もあるようです。
- (12/13 2013)
(しおり用)
相変わらずの Solaris (9) ネタです。
うちで Solaris 9 が動いている Blade 150 のうちの 1 台に
DVD-ROM ドライブ (MATSHITA SR-8589) がついているので、
これを利用して Solaris 10 の DVD イメージのインストールサーバにしようと
DVD-ROM を使ってみたときの問題について書き残しておきます。
まず、Solaris では通常 CD-ROM 等は vold で
自動的にマウントされるものと思っていたのですが、
CD-ROM を入れても、DVD-ROM を入れてもどうもうまくマウントされません。
eject でも取り出しができず、OS をブートしないと取り出せませんでした。
調べてみると、Solaris 9 からは、
inetd.conf で rpc.smserverd がデフォルトで無効になっているために
vold で CD-ROM でマウントできないんだそうです。
- UNIX処方箋：Solaris 9におけるCDの自動マウント (IT media)
http://www.itmedia.co.jp/enterprise/articles/0809/30/news020.html
早速そこにある対処を行い、これで確かに「CD-ROM」は
vold 管理でマウントされるようになりました。
しかし、DVD-ROM のメディア (Solaris 10 のインストールディスク)
を入れたら、これは相変わらずだめです。
手動でマウントしても、
# /sbin/mount -F hsfs -o ro /dev/dsk/c0t1d0s0 /cdrom
mount: /dev/dsk/c0t1d0s0 is already mounted, /cdrom is busy,
or the allowable number of mount points has been exceeded
といった調子です。なお、デバイスファイル /dev/dsk/c0t1d0 は、
/usr/sbin/cfgadm -al で確認できます。
この手動のマウントに失敗するのは、vold が動いているかららしいので、
一旦 vold を「/etc/init.d/volmgt stop」で止めてみましたが、
相変わらず、上のメッセージがでます。
もしや、と思ってマウント先を /mnt に変えてみたところ、
なんとマウントできてしまいました。
CD-ROM を 1 回マウントしたせいなのかなんだかわかりませんが、
とりあえず /cdrom 以外ならいけそうなので、/dvdrom を作っておいて、
vold を止めて、手動で /dvdrom にマウントすればいける、
ということがわかりました。
おかげで Solaris 10 のインストールイメージを
コピーすることもできました。
- (12/07 2013)
(しおり用)
tgif-4.2.5 を使っていて気がついた問題を一つ紹介しておきます。
tgif-4.2.5 で XPM 画像を export したら、
ちゃんとした画像が生成されない場合があることに気がつきました。
tgif-4.1 系列では特に問題はなかったのですが、調べてみると、
4.1 系列では XPM 画像は直接作っているようですが、
4.2 系列では PPM をまず作り、
それを ppmtoxpm で XPM 画像に変換しているようです。
確認すると、PPM 画像も失敗しているようでした。
tgif-4.2.5 はうちでは、
Solaris 10 のマシン (big endian) と
FreeBSD 8.2 のマシン (little endian)
にインストールされているのですが、
FreeBSD のマシンでローカルに使用している場合、
および FreeBSD と Solaris で相互にリモートの tgif を実行して
PPM 画像を出力させた場合に問題が出ました。
以下にサンプルを上げます。
元は、単に○に a という文字を書いただけのものですが、
色がついたり、真っ黒になったり、変にゆがんだりしてしまっています。
- 問題ない出力:
PPM データ、
それを gif に変換したもの :
- 色がついてしまうもの no.1:
PPM データ、
それを gif に変換したもの:
- 色がついてしまうもの no.2:
PPM データ、
それを gif に変換したもの:
- 真っ黒になってしまうもの:
PPM データ、
それを gif に変換したもの:
- ゆがんでしまうもの:
PPM データ、
それを gif に変換したもの:
調べると、PPM への export は、画像データを XImage 構造体に保存し、
それを 1 pixel データずつ直接 memcpy() を使って読み込んで
直接 PPM 画像を書いているようでした (xbitmap.c)。
ところが、XImage 構造体はやや曲者で、
X サーバ側の endian に従って色々な byte order, bit order で
データを保存できるようになっているようです。
だから、そのデータを直接読み書きする場合は、
データの endian が何であるかをちゃんと見ないといけないようですし、
また RGB の bit データの保存形式も少し変わっている場合があるし、
X サーバの Visual class (Pseudo Color とか TrueColor とか)
にも依存するようです。
例えば、Solaris マシンの tgif を FreeBSD の X サーバから使う場合、
X サーバは little endian なので XImage データもそれに従いますが、
実際に memcpy() するのは Solaris なので、
データの解釈は big endian で行われてしまうわけです。
よって、直接 memcpy() で読み込むのはちょっと危険なようです。
幸い X には XImage 構造体の 1 pixel データを読み込む関数
XGetPixel() が用意されていて、
それを使えば endian については考えなくてよさそうなので、
それに変えてみたら、とりあえず上の問題はすべて解消されました。
以下にパッチを置きます。
一応作者には報告済みで、次のリリースでは修正してもらえるそうです。
- (11/08 2013)
(しおり用)
Solaris 10 (UltraSPARC-IIi) に Guile を入れるために
libffi-3.0.13 を入れたのですが、
そのとき単純な問題が起きましたので、報告しておきます。
libffi は、マシンのアーキテクチャ、
CPU タイプを configure で細かく判別するのですが、
sparc 版 Solaris の場合には prtdiag
(/usr/platform/sun4u/sbin/prtdiag)
の出力を「grep -i sparc」にかけた文字列を見ているようです。
そして、その出力の文字列の '-' と空白を削除して (tr -d ' -')、
大文字を小文字に変換して (tr)、
その文字列が「ultrasparciv」にマッチすれば ultrasparc4、
「ultrasparciii」にマッチすれば ultrasparc3、
それ以外の「ultrasparc」にマッチすれば ultrasparc と判別しています。
ところが、この判別法だと、
うちの「UltraSPARC-IIi」は「ultrasparc3」になってしまいますが、
「UltraSPARC-IIi」は「ultrasparc」と判別されるべきなので
(IIi は 3 じゃなくて II グループ の II-i)、
configure のここを修正する必要があります。
例えば、「| tr -d ' -'」と「| tr $as_cr_LETTERS $as_cr_letters」の間に
「| sed 's/SPARCIIi/SPARCII/'」を噛ませればいいでしょう。
UltraSPARC-IIi のマシンと libffi の組み合わせでのみ起こる、
ごくまれな問題だと思いますが、
一応紹介しておきます。
- (09/17 2013)
(しおり用)
「Unix に関するメモ等 (08/24 2013)」
に書いた、ghostscript-9.X の件ですが、
9.07 以降で、Solaris 10 (+ gcc-4.7.2) では
examples/cjk/article9.ps の表示で Bus error を出して core dump する、
と報告しましたが、
でたばかりの ghostscript-9.10 でもだめでした。
そして、この問題を本家に報告したところ、
Bus error を回避する方法を教えてもらいました
(Thanks to Chris Liddell)。
configure 時には、私は
./configure --prefix=$prefix --disable-compile-inits \
--with-libiconv=gnu
のようにしているのですが、そこに
./configure --prefix=$prefix --disable-compile-inits \
--with-libiconv=gnu \
CFLAGS="-DGS_USE_MEMROY_HEADER_ID=0 -DGS_OFFSET_T=int32_t"
というものを追加するといいようです。
なお、これはとりあえずの回避策で、
次回はこうしなくてもいいように直す、と言われました。
ghostscript-9.10 で試しましたが、
確かにこれで examples/cjk/article9.ps で core dump はしなくなります。
ただ、相変わらず Solaris の TTF フォントでは縦の見出しが重なり、
IPA フォントだと重なりはなくなるのですが、
かっこや句読点の縦横の回転がされません。
これは、--disable-freetype でも今のところ解消していません。
なお、右上にちょっとだけでるのではなく、
ちゃんと全体が表示されてはいますので、だいぶ改善はされています。
ちょうど、9.05, 9.06 の --disable-freetype を使っていない状態と同じ状態、
といったところです。
あともうちょっとのような気がしますので、
時間があったらもう少し試してみたいと思います。
- (09/03 2013)
(しおり用)
うちの Solaris 10 に git (1.8.4) をコンパイルして入れてみたのですが、
どうやらその拍子に /dev/null が変になってしまいました。
調べてみると、0644 の普通のファイルになってしまっています。
これは、git のインストールだけで起きるわけではなく、
他の場合でも起こることがあるようで、
例えば Solaris 9 での openssl のインストール時の事例が
以下で紹介されています:
Makefile のスクリプトなどが凝ったものだと、
環境によってはそうなってしまうこともあるようなので、
修復する方法も知っておく必要がありそうです。
Linux などでは mknod により作成するようですが、
Solaris では /dev のファイルはほとんどがリンクになっていて、
/dev/null も /devices/pseudo/mm@0:null へのリンクなので、
上の Web ページにも書いてありますが、
その変な /dev/null を消してリンクを貼り直すだけでいいようです。
# cd /dev
# rm /dev/null
# ln -s /devices/pseudo/mm@0:null null
管理コマンドとしては、devfsadm というものがあるようで、
それを使う方が真っ当かもしれません。
なお、私は /dev/null が変になったことに気がついたあと、
reboot でもすれば修復するかなと思い、
ついうかうかと Solaris 10 を reboot してしまいました。
しかも普段は /usr/sbin/shutdown を使って落とすのですが、
/usr/sbin/reboot を使ったせいか / (root) に fsck
をしなければならなくなったようで、
全然 boot しなくなってしまいました。
具体的には、OS が立ち上がって / をマウントしようとするところで
check をしようとしてそのまま reboot する、
ということを繰り返してしまいます。
ok prompt に落としてからの boot -s, boot -a, boot -r も
いずれもだめで、
結局 Solaris 10 の CD-ROM を使って boot cdrom でブートして、
root 権限のコンソールを使って、
そちらで /dev/dsk/c0t0d0s0 を fsck して、
ついでに /dev/null へのリンクも修復して、
それでやっと元通りにブートできました。
かなり冷や冷やしましたので、
備忘録を兼ねて、事例として紹介しておきます。
- (08/28 2013)
(しおり用)
先日、Solaris 10 にフリーの音声合成エンジン hts engine
http://hts-engine.sourceforge.net/
と、音声合成クライアント Open JTalk
http://open-jtalk.sourceforge.net/
をインストールしたのですが、
sparc チップ上の Solaris のような big endian の環境では、
hts engine にバグがあります。
big endian を little endian に変換する部分があるのですが、
そこが変になっています。以下にそのパッチを置いておきます。
hts_engine_API-1.06 用のパッチですが、a
最新版の 1.07、あるいは古い版でも効くと思います。
- (08/24 2013)
(しおり用)
「Unix に関するメモ等 (12/20 2011)」
で Solaris 上に ghostscript 9.04 をインストールして
縦書き (examples/cjk/article9.ps) がうまくいった、
という報告をしましたが、
その後の ghostscript の 9.05, 9.06, 9.07, 9.09 について報告します。
なお、現在、OS は Solaris 9 から 10 へ、
gcc も 3.4.3 から 4.7.2 に変わっています。
まず、ghostcript 9.04 をこの環境で入れ直してみましたが、
それは 「Unix に関するメモ等 (12/20 2011)」
と同じ状況でした。9.05 も全く同様でした。
しかし 9.06 は、状況は違いました。
--disable-freetype をしないでコンパイルすると、
縦の見出しが重なってしまうのですが、
フォントを IPA フォントに変えると、重なりはなくなりますが、
かっこの位置が崩れます。ここまでは 9.04 と同じです。
- gs 9.06 の article9.ps (freetype あり、IPA フォント) の出力画像
しかし --disable-freetype でコンパイルすると、
今度はほとんど何も出なくなりました。
右上に横向きに「日本」と少し表示されるだけで、
それ以外が全くでません。
- gs 9.06 の article9.ps (freetype なし) の出力画像
これは IPA フォントでも HG-* フォントでも変化ありません。
configure のオプションなどを変えてみたり、
FreeBSD の ports にあるパッチを当ててみたりも
したのですが、結局うまく行きませんでした。
次は gs 9.07 で試してみましたが、
今度は --disable-freetype に関わらず日本語フォントの 2 つ目を
読みこむあたりで Bus error で core dump してしまいます。
gs 9.09 の場合は、--disable-freetype なしだとやはり core dump します。
--disable-freetype をすると今度は core dump はしませんが、
9.06 の場合と同じで右上に「日本」が横向きにでるだけです。
ということで、今のところうちの Solaris 10 の上で縦書きで使えそうなのは、
gs 9.05 までという感じです。
なお、元々は、FreeBSD 上の Opera (12.16) で印刷用に吐く PS ファイルを
PS printer も今までの gs も受けつけない
(Error: /invalidfont in --.type42execchar-- と出る) ので、
gs 9.X ならどうかなと gs のバージョンを上げてみたのですが、
これは逆に --disable-freetype の方がだめで、
--disable-freetype なしの、つまり freetype つきの
gs ならちゃんとエラーなく表示されます。
よって、今のところ縦書きも Opera の PS ファイルも
両方がうまくいくような gs ができていないのですが、
もう少し調べてみたいと思います。
(cf. 「Unix に関するメモ等 (09/17 2013)」)
- (08/23 2013)
(しおり用)
Solaris 10 + gcc-4.7.2 で古い freetype-1.3.1 をコンパイルしていたら
次のようなエラーがでました (test/ftdump.c):
ftdump.c:172:1: error: pasting "."
and "glyph_object" does not give a valid preprocessing token
同様のものがいくつか出たのですが、調べるとこれは
どうやら次のようなマクロが引き起こしている問題のようでした:
#define FOOTPRINT( field ) Save_Memory( &memory_footprint.##field )
これを「FOOTPRINT( glyph_object );」のように呼び出していることによる
エラーです。
これは、## がその前後のトークンを連結するプリプロセッサ命令なのですが、
どうやら ## の前にある '.' がトークンに使用できない文字なので
「トークンとしての連結ができない」というエラーのようです。
よくよく調べたら、今の gcc ではこれは単に
#define FOOTPRINT( field ) Save_Memory( &memory_footprint.field )
と ## を取ってしまえば解決するようです。
なお、test/ftdump.c ではもう一つ PRINT_MEM
でも同様の ## が使われていますので、
そちらも同様の修正が必要です。
- (08/06 2013)
(しおり用)
Solaris (10) 用のブラウザは Firefox のバイナリ版があるので
それを使えばいいのですが、
やはりそれなりに重いので
今まで Solaris 9 の上でも古い Netscape 3 や
w3m などを使用していました。
今回 Solaris 10 ではさすがに Netscape 3 もないだろうと思って
軽いブラウザの dillo を入れることにしました。
今は新しい dillo (3.X) があるようですが、
日本語化されているのは 0.8.6 のようなので
それをコンパイルしました。
ところが、FreeBSD の ports 版はちゃんと動くのですが、
Solaris 10 では同様のパッチ、configure オプションでコンパイルしても、
いくつかの日本語文字が欠けてしまう現象が起きました。
調べてみると UTF-8 の先頭バイトが E4h や E8h の文字が欠けるようでした。
色々調べてみたところ、
ようやく Solaris 10 の isspace() が問題であることに気がつきました。
dillo 0.8.6 では、一旦 UTF-8 にした後でバイト毎にそれがスペースか、
全角文字かなどをチェックしているところがあるのですが、
UTF-8 文字の 1 byte 目の E4h や E8h が Solaris 10 の isspace()
では真となってしまうようで、
それでその全角文字がスペースとみなされるようです。
そもそも isspace() に int でなく char として渡しているのが
良くないのかもしれません。
ということで、FreeBSD の ports のパッチも一部使用し、
上の障害を解消する差分を使って
ちゃんと日本語が表示できるようになりました。
それを以下に置いておきます。
dillo-0.8.6 を展開し、
dillo-0.8.6-i18n-misc-20060709.diff を適用した後で
上を適用します。
なお、その後で、うちでは
touch aclocal.m4
touch Makefile.in
touch configure
touch config.h.in
としておかないと configure の作成などをやろうとして
エラーになってしまいました。
configure オプションは、FreeBSD の ports のものをまねて
--disable-dlgui \
--disable-ipv6 \
--disable-meta-refresh \
--enable-anti-alias \
--enable-cookies \
--enable-nls \
--enable-ssl \
--enable-tabs \
--enable-threaded-dns
としましたが、多分多くは指定しなくてもデフォルトでそうなると思います。
ipv6 は gethostbyname2() がないと言われたので disable にしてあります。
dillo は相当軽いですね。
今後は Solaris 10 上では主にこれを使うことになりそうです。
- (07/27 2013)
(しおり用)
うちは、最近 Solaris 9 のディスクがクラッシュしたため、
入れ替えを予定してインストール作業中だった Solaris 10 に
急遽入れ替えたのですが、
その作業を含め色々ネタができました。
順次時間のあるときに報告したいと思いますが、
まずは metamail について紹介します。
metamail (2.7) は、Solaris 9 のときは割りとすんなりできたのですが、
Solaris 10 + gcc-4.7.2 でコンパイルしようとしたらちょっと面倒でした。
metamail 2.7 はかなり古く、configure ではなく
Makefile を手で修正する形式ですが、
-DSYSV と選んだだけではうまくいかず、
関数のプロトタイプがいちいち引っかかってしまいました。
そのときに使用したパッチを以下に置いておきます。
今さら入れる人もいないかもしれませんが、
私は今でも mmencode とか良く使うのでないと困る方です。
他にいいものもあるのかもしれませんが良く知りません。
- (07/23 2013)
(しおり用)
「UNIX に関するメモ等 (07/19 2013)」
に書いた libcerf ですが、
Solaris 9 にその改変版を入れて、
CVS 版の gnuplot のソースにもそれに対応する修正を多少入れて
コンパイルしたらちゃんとうまくいきました。
gnuplot の libcerf 用のデモも、
gnuplot の本家で紹介してある通りのグラフができました。
なお、その後その作業を行った Solaris 9 のマシンのハードディスクが
クラッシュしたため、
残念ながら gnuplot の方の修正データは手元に残っていないのですが、
gnuplot の方の改変はそれほど大変な作業ではなく
数行の修正で済んだように記憶しています。
- (07/19 2013)
(しおり用)
最近 gnuplot の CVS 版で、複素誤差関数が外部ライブラリ libcerf
を利用して実装されました。
libcerf は、C99 の複素数ライブラリ (complex.h) を利用して、
複素誤差関数などを提供するライブラリです。
ところが、これをインストールしようとして気がつきましたが、
Solaris 10 には complex.h がありますが、
うちでまだ現役の Solaris 9 には complex.h がありません。
複素数ライブラリは、GNU Scientific library (GSL;
http://www.gnu.org/software/gsl/)
にも入っているので、最初はこれで代用して、
それ用の wrapper のマクロを complex.h として書こうと思ったのですが、
GSL 自体結構大きいですし、libcerf を見ると必要なのは、
- double _Complex (= cmplx) という型
- z の実数部分、虚数部分を返す creal(z), cimag(z)
- 実数 a, b から複素数の値を返すマクロ CMPLX(a,b)
- cexp(z) (exp(x) の複素数版)
くらいのようだったので、それなら cmplx 型は GSL に習って
「typedef struct { double dat[2]; } cmplx」
とすればよさそうで、creal(z), cimag(z) も GSL にマクロがあり、
CMPLX(a,b) も構造体代入を使って
#define CMPLX(a,b) (cmplx){ {(a),(b)} }
で代用できそうなので、パッチを作って済ますことにしました。
cexp(z) は、自作してもよかったのですが、
実際の libcerf のソースを見ると、上記以外にも、
複素数の和、差、積などをやっているところがあり
(特に cexp() を使っているあたりで)、
また、複素数型と定義した変数に実数を
そのまま代入している箇所などもあり、
それらも修正しなければいけなかったので、
実際は cexp() 自体は作らずに、exp() と sin(), cos() で
直接それらの部分を修正して回りました。
ただ、後からわかったのですが、
- isinf() を使っている (Solaris 9 にはない)
- INFINITY を使っている (Solaris 9 にはない)
も必要でした。isinf() はインターネット上に
「#define isinf(x) (!finite(x) && (x)==(x)」という代用品が見つかった
(finite() は ieeefp.h にある) し、
INFINITY は、libcerf 自体に (1./0.) で代用するコードがあったので、
それを使っています。
make が済んだら、test/test_libcerf_1 を実行すると、
libcerf が定義している各種関数値と
その理想値 (vs. と書かれている値) の比較が表示されます。
それを見るとうまくいっているかわかります。
こちらではとりあえずそれらしい値になりました。
これを gnuplot で使うには、多分 gnuplot の方も
コードを多少修正しないといけないような気がしますが、
それで問題が出たら、また報告したいと思います。
なお、Solaris 10 (+ gcc 4.7.2) では、
パッチなど当てなくても全く問題なく libcerf はコンパイルでき、
test/test_libcerf_1 も綺麗に小さい誤差で実行してくれました。
- (05/17 2013)
(しおり用)
現在うちの HTTP サーバは Apache 2.4 系になりました。
2.4 系は設定がかなり変更されていて、
当初はマニュアル以外の情報が少なく、
以前の設定を引き継ぐのにもかなり苦労していましたが、
最近はかなり情報が見られるようになってきて、
それなりに探せるようになってきました。
多くの方が同様の苦労をしているために、
むしろそういう情報が増えてきているのだと思いますが、
逆に言えば、Apache のマニュアルを見ただけでは、
やりたいことをやることがかなり難しくなってきているような気がします。
先日も探すのに苦労したことがありましたので、
他の人の参考になるかもしれませんので、
ここで紹介しておきます。
やりたかったことはあるページの .htaccess によるアクセス制限なのですが、
- AAA.BBB.CCC.DDD, AAA.BBB.CCC.EEE, ... の ip address のホストからは
認証もなくそのまま見えるようにする。
- PPP.QQQ.RRR.SSS という ip address のホストからは
ユーザ認証の上で見えるようにする。
ただし、この場合は HTTPS でのアクセスのみを許可する。
従来 (Apache 2.2 以前) の deny, allow の設定だと
.htaccess だけでこれを行うのはかなり難しいと感じていました。
実際色々試したのですが、なかなかうまくいきませんでした。
次に、2.4 には <If> という条件判断を行うディレクティブがあるので、
アクセスは 1., 2. ともに許可して、
後者の方だけ <If> で認証をつけたらどうだろう、
HTTPS の条件の方は mod_rewrite を使って
HTTPS の URL に書き換えてやればいいのでは、
ということでこんなものを書いてみました:
<Limit GET POST>
require all denied
allow from AAA.BBB.CCC.DDD AAA.BBB.CCC.EEE ...
# これは素通し
allow from PPP.QQQ.RRR.SSS
# これは認証つき
</Limit>
<If
"%{REMOTE_ADDR} == 'PPP.QQQ.RRR.SSS'
&& %{HTTPS} == 'off'">
RewriteEngine On
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
<If
"%{REMOTE_ADDR} == 'PPP.QQQ.RRR.SSS'
&& %{HTTPS} == 'on'">
Require valid-user
</If>
<If> 文があまり綺麗でないですが、
最初は、外側の <If> で変数 %{REMOTE_ADDR} のアドレスを判別し、
内側の <If> で %{HTTPS} で HTTPS かどうかを判別するといった
<If> のネストの形で書いたのですが、
<If> のネストは許可されていないのか、うまくいきませんでした。
また <If> は <Limit> の中に書くこともできないようだったので、
<Limit> の外に出して書いています。
Rewrite... が URL を書き換えてそちらに飛ばすためのもので、
http://... でアクセスしてきたものを https://...
に書き換えてそちらを参照する設定です。
しかしこれだと、飛ぶ先は確かに https://... のようなのですが、
認証時の接続 (パスワードの入力時) が HTTP なのか HTTPS なのかが
やや不明でした。
よって、次は HTTPS への URL への書き換えは行わず、
https へのアクセスはユーザに任せて最初から
https:// でアクセスしてもらうことにして、
HTTPS 以外は拒否するように以下のように修正してみました:
<Limit GET POST>
require all denied
allow from AAA.BBB.CCC.DDD AAA.BBB.CCC.EEE ...
# これは素通し
allow from PPP.QQQ.RRR.SSS
# これは認証つき
</Limit>
<If
"%{REMOTE_ADDR} == 'PPP.QQQ.RRR.SSS'">
<RequireAll>
Require expr %{HTTPS} == 'on'
Require valid-user
</RequireAll>
</If>
しかしあとで調べたら、これはさらに簡単に以下のように書けるようです:
<Limit GET POST>
require all denied
<RequireAny>
Require ip AAA.BBB.CCC.DDD AAA.BBB.CCC.EEE ...
# これは素通し
<RequireAll>
Require ip PPP.QQQ.RRR.SSS
Require expr %{HTTPS} == 'on'
Require valid-user
</RequireAll>
</RequireAny>
</Limit>
この最後のものが一番シンプルで一番分かり易いですし、
アドレスの追加なども容易に行えます。
ただ、最初にも書いたように、
ここにたどりつくのに相当時間がかかりましたし、
相当 try and error を繰り返しました。
その辺りはどうにかならないかと思ってしまいます。
- (04/04 2013)
(しおり用)
「Unix に関するメモ等 (08/02 2011)」
に書いた、
FreeBSD (8.1) から remote で Solaris (9) の Tgif (4.2.5) を起動すると
メニューの日本語が表示されない件ですが、
やはりフォントの指定をやり直したら表示されるようになりました。
具体的には、FreeBSD 側 (X サーバ側) で以下のようにしました。
Tgif.MenuFontSet: -*-fixed-medium-r-*--14-*-*-*-*-*-*-*
Tgif.BoldMsgFontSet: -*-fixed-medium-r-*--14-*-*-*-*-*-*-*
Tgif.MsgFontSet: -*-fixed-medium-r-*--14-*-*-*-*-*-*-*
色々試行錯誤したのですが、結局同じフォントです。
もちろん、X のサーバ側でどんなフォントが入っているかに依存すると思います。
- (02/07 2013)
(しおり用)
私は普段 tcsh をログインシェルとして使っていますが、
現在の FreeBSD では csh = tcsh になっていたり、
Linux では sh = bash になっていたりして、
フリーソフトの make 用のスクリプトなどには、
本来の sh (Bourne shell), csh にはないような bash, tcsh の機能が
標準と思われていることが出てきていたりします。
Linux 全盛のためか、
最近は特に sh = bash という仮定が多いように思います。
先日も、GNU sharutils-4.13.3 をコンパイルしてみたのですが、
make check がうまくいかないので良くみたら、
tests/shar-2 という sh スクリプトに「cd -」という行がありました。
しばらくなんのことかよくわからなかったのですが、
もしかして bash の方言かと思い調べてみたら、
bash では cd する前の古いディレクトリを覚えていて、
その前のディレクトリに戻るのが「cd -」らしいです。
今回はそこを「cd ..」のようにしたらとりあえずうまくいきました
(開発元にも報告済み)。
今回は割と簡単にすみましたが、
FreeBSD や Solaris のように sh = bash ではない OS では、
そういう場合に苦労することが多いですし、
相当修正が面倒な場合もありますので、
できるだけ bash に依存しない書き方をしてもらいたいものです。
- (01/30 2013)
(しおり用)
デフォルトの grep を、新しい GNU grep (grep-2.14) にしていたら、
automake の make check がいつになっても終わらなくなりました。
大きいファイルの処理に手間取っているようなのですが、
grep-2.4.2 くらいだとすぐに終わります。
調べてみると、LANG=C だと新しい grep でもすぐに終わるようで、
マルチバイトに関連する問題のようです。
GNU sed や GNU awk も最近のものは同様で、
LANG=ja_JP.eucJP なんかだと極端に遅くなります。
例えば、Solaris (9) 上で 100000 行位のファイルに対して
「sed 's/^[ ]*TEST/s/TEST/test/g'」を行うと、日本語ロケール上では、
- /usr/bin/sed : 1.10u 0.27s 0:01.38 99.2%
- GNU sed-4.2.2 : 10.62u 0.12s 0:10.82 99.2%
- GNU sed-2.05+mb1.06 : 1.23u 0.10s 0:01.35 98.5%
- GNU sed-3.02+mb1.09 : 3.05u 0.09s 0:03.20 98.1%
のようになります。sed-4.2.2 は /usr/bin/sed の 10 倍程度時間がかかります。
これが、LANG=C だと sed-4.2.2 以外はほとんど時間が変わらず、
- GNU sed-4.2.2 : 2.79u 0.12s 0:02.95 98.6%
となりました。相当速くはなりますが、やはり sed-4.2.2 は少し遅いようです。
awk も同様で、
「awk '/^[ ]*TEST/{gsub(/TEST/,"test"); print}'」で比較すると、
日本語ロケールでは
- /usr/bin/nawk : 2.09u 0.13s 0:02.26 98.2%
- GNU awk-4.0.2 : 9.78u 0.18s 0:10.04 99.2%
- GNU awk-3.0.6+mb1.15 : 3.18u 0.13s 0:03.37 98.2%
LANG=C では、
- GNU awk-4.0.2 : 4.09u 0.16s 0:04.29 99.0%
となっています。やはり LANG によって速度に相当違いが出ますが、
LANG=C にしてもまだ多少ほかのものに比べると遅いようです。
よって、うちではデフォルトは少し前のものにしてあります。
- (12/20 2012)
(しおり用)
例えば beamer の出力のように、プレゼンテーション用の PDF でよくある
横長 (landscape) の形式の PDF ファイルがあって、
それを 4up (= 1 ページに 2x2 の 4 ページ分を縮小配置)
して印刷することを考えたのですが、
Solaris 9 の Acrobat Reader 7.08 (8 以上は Solaris 10 用) では
バグがあるようで 4up があまりうまくいきません
(今の新しい Acrobat Reader では問題ありません)。
まずそれを説明します。
acroread の 4up では、オプションとして、「方向」(縦/横; デフォルトは縦)、
「ページの順序」(横/横 (右から左)/Vertical/縦 (右から左); デフォルトは横)
があります。
なお、多分「ページの順序」の「Vertical」は多分「縦」で、訳し忘れでしょう。
landscape の PDF では「方向」を「横」にすると
「ページの順序」の設定がうまくいくのですが、
acroread 7.08 では「方向」を「横」にすると A4 縦の紙に
landscape が回転されずに中央に小さく (A5 サイズで) 印刷されてしまいます。
「方向」を「縦」にすると印刷は回転されて A4 横型に印刷されるのですが、
「ページの順序」の設定がうまくいきません。
「ページの順序」の設定がうまくいかない、というのは、
「方向」が「縦」の場合は、landscape (横長) の紙を
90°反時計回りに回転させた縦長と見て、
それで縦長の紙に対する「ページの順序」の設定がなされてしまうのです。
例えば、4up の場合、縦長の紙ならば、
- 「方向」が「横」(default)
[1 ページ] [2 ページ]
[3 ページ] [4 ページ]
- 「方向」が「横 (右から左)」
[2 ページ] [1 ページ]
[4 ページ] [3 ページ]
- 「方向」が「Vertical」(今の acroread だと「縦」)
[1 ページ] [3 ページ]
[2 ページ] [4 ページ]
- 「方向」が「縦 (右から左)」
[3 ページ] [1 ページ]
[4 ページ] [2 ページ]
となるのですが、「方向」が「縦」の横長の紙の場合は、
一旦 90°反時計回りに回転させて上を適用して印刷するので、
結果としては印刷された紙を 90°時計回りに回転して横長に戻すことになるので、
上のが 90°時計回りに回転したものになってしまうわけです:
- 「方向」が「横」(default)
[3 ページ] [1 ページ]
[4 ページ] [2 ページ]
- 「方向」が「横 (右から左)」
[4 ページ] [2 ページ]
[3 ページ] [1 ページ]
- 「方向」が「Vertical」(今の acroread だと「縦」)
[2 ページ] [1 ページ]
[4 ページ] [3 ページ]
- 「方向」が「縦 (右から左)」
[4 ページ] [3 ページ]
[2 ページ] [1 ページ]
欲しいのは 1. か 3. の形なので、これではうまくありません。
次に、Solaris の acroread では、
印刷の代わりに PS ファイルとして出力させることができるので、
一旦 PS ファイルとして出力して、
それを psnup 等で 4up させてみることにしました。
PS ファイルとして出力する方法は、
「方向」は「縦」(「横」だとだめです) にして、
- (a) 1 ページに 2 ページ分を出力
- (b) 1 ページに 1 ページ分を出力
を利用し、(a) を 2up (psnup -2) する、(b) を 4up (psnup -4) する、
の 2 通りを試します。
なお、この場合、(a) の 2up の方は端に余白ができますが、
(b) の 4up の方は端の余白がほとんどなく、画面一杯に大きく印刷され、
そのため、下が少し切れることもあるようです。
psnup には -l (landsape ファイル用), -r (seascape ファイル用),
-c (縦方向; デフォルトは横方向) のオプションがあり、
これらも使用してみます。
なお、landscape は紙を 90°反時計回りしたものを意味し、
seascape は紙を 90°時計回りしたものを意味します。
まず (a) の方は既に 1 ページ目、2 ページ目が
1 枚に縦に並んでまとまっているので、
2up しても 1. の形 (横長にして) の配置にはならず、
3. か 4. の配置にしかできませんが、
問題は 3. にできるかどうかです。
試したところ、「psnup -2」「psnup -2 -l」「psnup -2 -c」では
いずれも 4. の形の配置になってしまうのですが、
「psnup -2 -r」とすると 3. になりました。
通常縦 (portrait) の A4 ファイルを psnup -2 したものとは
どうやら逆の配置になっていますので、
どうも (a) の PS ファイルは上下が逆になってしまっているようです。
次は (b) の psnup -4 ですが、この場合はそれぞれ以下のような配置
(横長にして) になります。
- 「psnup -4」のときは 4. の配置
- 「psnup -4 -l」のときは 1. の配置
- 「psnup -4 -r」のときは 8. の配置
- 「psnup -4 -c」のときは 7. の配置
- 「psnup -4 -l -c」のときは 3. の配置
- 「psnup -4 -r -c」のときは 6. の配置
これは、「psnup -4 -l」「psnup -4 -r」の結果からして、
(b) の PS ファイルは landscape になっていることが予想されます。
「psnup -4」の結果は、横長を 90°反時計回りに回転させた縦長
(landscape) と見たまま 4up したものですし、
ほかのものもそう考えるとつじつまが合います。
よって、とりあえずは (a) の「psnup -2 -r」(3.) か、
(b) の「psnup -4 -l」(1.)、「psnup -4 -l -c」(3.)
でうまくいくことになります。
最も確実に行うには、acroread では 1 ページ 1 ページで出力し、
それを pstops でより細かく制御する方法でしょう。
例えば、(b) の PS を
pstops -pa4 "4:0@.5(0cm,0cm)+1@.5(10.3cm,0cm)
+2@.5(0cm,14.8cm)+3@.5(10.3cm,14.8cm)"
とすれば 3. の配置に、
pstops -pa4 "4:0@.5(0cm,0cm)+1@.5(0cm,14.8cm)
+2@.5(10.3cm,0cm)+3@.5(10.3cm,14.8cm)"
のようにすれば 1. の配置になるようです。
余白や拡大率などもこの方法ならば細かく調整できます。
- (11/26 2012)
(しおり用)
procmail をインストールすると formail とかいうものがついてくるのですが、
今まで使ったことはありませんでした。
これは、ヘッダを書き換えて転送するのに使えるようです。
formail のオプション等を少し調べてみましたが、
特に利用したいヘッダの追加、置き換えに関する
-a/-A/-i/-I オプションを調べてみると以下のような感じでした。
- -a "[HeaderField]: [string]"
または -a "[HeaderField]:"
[HeaderField]: のヘッダ行がなければこれをヘッダに追加。
Message-ID: の場合は、unique ID を新たに入れてくれる。
- -A "[HeaderField]: [string]"
または -A "[HeaderField]:"
このヘッダ行を追加。
- -i "[HeaderField]: [string]"
または -i "[HeaderField]:"
このヘッダ行を追加するが、既にそれがあればそちらのヘッダ行には
"Old-" をつけて残してくれる。
[string] がない場合は追加しない。
- -I "[HeaderField]: [string]"
または -I "[HeaderField]:"
このヘッダ行を追加するが、既にそれがあればそちらのヘッダ行は削除する。
[string] がないと単に削除するだけ。
いずれも基本的には追加なのですが、
しかしこれだけではよくわからないので色々テストしてみました。
すると、追加するかどうか、残すかどうかは、
だいたい以下のようになっているようです。
|
[string] あり |
[string] なし |
|
既にある場合 |
ない場合 |
元のを残すかどうか |
既にある場合 |
ない場合 |
元のを残すかどうか |
| -a |
追加しない |
追加する |
残す |
追加しない |
追加する |
残す |
| -A |
追加する |
追加する |
残す (*1) |
追加しない |
追加しない |
残す |
| -i |
追加する |
追加する |
Old- つきで残す |
追加しない |
追加しない |
Old- つきで残す (*2) |
| -I |
追加する |
追加する |
削除 |
追加しない |
追加しない |
削除 |
*1: 既にある場合は、その HeaderField 行が、
追加するものと合わせて 2 行できることになる。
*2: 元のものは Old- つきのものに変えるし、
追加もしないので、ある意味では残してはいない。
ヘッダ名の変更は -R でできますが、
現在は、ある種のメールをヘッダを書き換えて転送するのに、
-i, -I, -R を使用したレシピを .procmailrc に入れて、
それをパイプで sendmail に渡しています。
- (09/12 2012)
(しおり用)
LaTeX で極端に大きいフォントを使用したい場合、
古い LaTeX では、
\font\minTitle=min10 at 20pt % 日本語用
\font\cmrTitle=cmr10 at 20pt % 英数字用
\begin{center}
\minTitle\cmrTitle
ほげほげhogehoge
のようにする手がありました。現在の LaTeX2e では、
{\fontsize{4cm}{0pt}\selectfont ほげhoge}
のようにするようですが、そのままだと英数字があまり大きくなりません。
この場合「\usepackage{type1cm}」を使うといいようです。
フォントサイズを変える方法以外にも、\usepackage{graphics} のもとで、
\scalebox{7}{\bf ほげhoge}
のようにする手もあります。
- (07/14 2012)
(しおり用)
csh スクリプトの中では行末に \ (バックスラッシュ) を置くことで
長い行を複数行に分けて書くことができます。
私は普段それを利用して、csh スクリプトから
awk のスクリプトを実行させたいときに、
csh スクリプト中に直接 awk スクリプトを書いたりしています。例:
#!/bin/csh -f
awk '{x += $1; xx += $1*$1; y += $2; yy += $2*$2; xy += $1*$2}\
END{\
Sxx = xx - x*x/NR;\
Syy = yy - y*y/NR;\
Sxy = xy - x*y/NR;\
r = Sxy/sqrt(Sxx*Syy);\
printf "(m_x, m_y) = (%f, %f)\n",
x/NR, y/NR;\
printf "(Sxx, Syy, Sxy) = (%f, %f, %f)\n",
Sxx, Syy, Sxy;\
printf "r = %f\n", r;\
}' $argv[1]
ところが、awk スクリプト内部にも同じルールがあり、
1 行でつなげて書くべき文を改行して書く場合は \ で改行して書く、
ということになっています。先日、それが混同したバグを作ってしまいました:
#!/bin/csh -f
awk '{print \
gensub(...)}' file
こうするとどうも、gensub() 部分が効いていない出力がでるようでした。
この \ は awk の行末の \ としては機能せず、
そして csh スクリプトの行末の \ として機能するようですが、
その場合どうやら awk スクリプトを一行にして
「'{print gensub(...)}'」のようにしてくれるわけではなく、
awk には「print」の後ろが改行されたスクリプトが渡されているようです。
awk は、; で文が切れるわけでなく、改行で一旦文が切れるので、
「print」の後ろが改行されると「print」(= 行をそのまま出力) が行われるので、
それで gensub() が効かない行が出力されていた、というわけです。
なかなか気がつきませんでしたが、結局 \ を \\ にして、
#!/bin/csh -f
awk '{print \\
gensub(...)}' file
として、csh スクリプトにも \ を渡し、
awk スクリプトにも行末の \ を渡すことでうまくいきました。
- (03/02 2012)
(しおり用)
less をバージョンアップしたら、-p オプションに日本語が通らなくなりました。
実は、私は普段この less -p を利用する、
ほぼ以下のようなことを行う csh スクリプトを多用しています:
set pat = $1
shift
less -p "$pat" `grep -l $pat $argv`
すなわち、検索文字列 ($1 = $pat) を最初の引数に指定して、
その後ろに複数のファイル名 (通常はワイルドカード) を指定して、
この文字列が含まれるファイルのみを less で参照し、
その検索文字列を反転表示させる (そこにジャンプする)、
というものです。
多量の C のソースファイルや、多量のメモのファイルの中から、
目指すキーワードが含まれている部分をみつけだして参照するのに
よく利用しています。
less は従来は「less version 290+zcat+iso2.p1」を使用していたのですが、
FreeBSD の package で「less 382+iso262+regex_cs-lwp9k」を入れたところ、
この -p オプションに日本語がうまく通らなくなってしまいました。
他の 358, 332 などの他のバージョンや、
-K オプションを試してみましたがうまくいきません。
configure 時に --with-regex=pcre としてみましたがそれでもだめです。
/usr/bin/less は「less 436」ですが、これもだめです。
日本語検索ができないとかなりつらいので、
結局「less version 290+zcat+iso2.p1」に戻しています。
- (01/17 2012)
(しおり用)
gnuplot でタイトル (set title) として「の」を含んだ文字を入れ、
そのフォントを "Ryumin-Light-EUC-H" として
EPS ファイルとして出力し、
それを LaTeX ファイルに graphicx パッケージでとりこんで、
その dvi ファイルを dvipdfmx で PDF にしたら、
グラフのタイトルの「の」の幅が半角みたいに狭くなって、
次の文字が重なってしまいました (下図)。
- その PDF ファイルの一部を拡大したもの (xpdf)
ただしこの現象は、環境 (OS) によっても起きませんし、フォントを
"GothicBBB-Medium-EUC-H" にすると起きません。
PDF ファイルのフォントを調べてみると、
どうやら EPS ファイル部分のタイトルのフォントは
(多分 ghostscript により) "IPAMincho"
に置き換えられているようです。
別な環境 (Solaris) だと "HG-MinchoL" に置き換えられていて、
その場合はこのような問題は起きないですし、
上の GothicBBB-Medium-EUC-H の場合は IPAGothic に置き換えられて
その場合はこの問題は起きないので、どうやら IPAMincho の問題のようです。
現象としては、以下の話に似ているので、原因もそのあたりなのかもしれません。
とりあえずは replacecjkfonts にかけて、
PDF ファイルの IPAMincho を Ryumin-Light にしてしまえば
問題は解消するようです。
- (12/23 2011)
(しおり用)
tgif で絵を書いて LaTeX に張り込む場合、
psfrag を使って絵の中の文字も LaTeX 文字に置き換えることが多いのですが、
それを pdf ファイルに変換する場合は dvipdfmx が使えないので、
dvips + ps2pdf + replacecjkfonts で pdf ファイルを作っていました。
その手順が面倒なので、簡単なスクリプトを書いて
その作業を自動化していたのですが、
あるとき ps2pdf がエラーを起こすことに気がつきました。
そのスクリプト内では、tgif による eps ファイルの更新もやるようにしていて、
tgif の obj ファイルから eps ファイルへの変換を、
tgif -print -eps *.obj
と行っていて、その後で LaTeX にかけていたのですが、
どうやらそれがダメらしく、
tgif を対話的に立ち上げて C-p で一つ一つ
eps に変換した場合にはうまくいっていました。
どうも変なので、両者の eps を比較したところ、
コマンドラインから一発で変換した方は、
日本語文字に関する妙なコードが残っていることがわかりました。
結論から言えば、
tgif -print -eps *.obj
でも確かに各 obj 毎に eps ファイルを作ってくれるのですが、
どうやら前に処理した obj ファイルの設定が相互作用を起こして
妙なことを起こしているようでした。
よって、一度ではなく、ファイルを一つ一つ tgif に処理させるように
foreach i ( *.obj )
tgif -print -eps $i
end
としたら (csh スクリプト)、問題ないようでした。
- (12/20 2011)
(しおり用)
これまで Ghostscript は、日本語対応がちゃんと取れていた
7.07 を使用していたのですが、
最近は 8.6X, 9.0X もよくなっている、という話を目にしていたので、
9.04 をインストールしてみました。
環境は Solaris 9 + gcc 3.4.3 です。
ghostscript-9.04.tar.gz には freetype や jasper, lcms などのソースも
付属していますが、それが結構新しいものなので、
インストールされているヘッダファイルを見にいって
コンパイルエラーになることがあります。
私も最初インストールされている lcms や jasper が古かったので
そういう問題が起きましたが、
jasper については gs 付属のものは独自にパッチを当ててあるようで
うまく問題を解消できなかったので、
./configure --prefix=$prefix --without-jasper --disable-compile-inits
のようにしてコンパイルしました。
--disable-compile-inits は、cidfmap という設定ファイル用に必要なようです。
なお、それ以外にも LDFLAGS に -liconv を入れて、
GNU iconv をリンクするようにしています。
それでだいたい問題なくコンパイルでき、
Resource というディレクトリを $prefix/share/ghostscript/9.04
にコピーして (make install ではコピーされなかった)、
とりあえず使えるようになりました。
日本語の設定は、
$prefix/share/ghostscript/9.04/Resource/Init/cidfmap
で行いますが、Solaris に付属する TrueType フォント用に以下のようにしました:
/Ryumin-Light /HG-MinchoL ;
/GothicBBB-Medium /HG-GothicB ;
/HeiseiMin-W3 /Ryumin-Light ;
/HeiseiKakuGo-W5 /GothicBBB-Medium ;
/HG-MinchoL << /FileType /TrueType /CSI [(Japan1) 6]
/Path (/usr/openwin/lib/locale/ja/X11/fonts/TT/HG-GothicB.ttf) >> ;
/HG-GothicB << /FileType /TrueType /CSI [(Japan1) 6]
/Path (/usr/openwin/lib/locale/ja/X11/fonts/TT/HG-MinchoL.ttf) >> ;
この後 $prefix/share/ghostscript/9.04/examples/cjk/article9.ps
を見たのですが、残念ながら文字が重なったり、
句読点やかっこが縦書きに対応した位置に出ない状態になります。
- gs 9.04 の article9.ps の出力画像
調べてみたのですがネット上にはあまり情報はありませんでした。
フォントを IPA フォントを使うように変えると、
文字の重なりは解消するのですが、句読点やかっこはそのままです。
freetype ライブラリの問題らしいという情報を見つけたので、
./configure --prefix=$prefix --without-jasper --disable-compile-inits \
--disable-fontconfig --disable-freetype
のようにしてコンパイルし直したところ、
ようやくちゃんと表示できるようになりました。
- freetype を使わない gs 9.04 の article9.ps の出力画像
freetype を使う方が問題があるとは考えなかったので、
やや気がつきにくい話でした。
そういう情報もあまり見られませんので (自前でコンパイルする人が少ない ?)
ここに残しておきます。
(cf. 「Unix に関するメモ等 (08/24 2013)」)
- (12/10 2011)
(しおり用)
Solaris 9 + gcc 3.4.3 で Qt 4.7.4 をインストールしてみたのですが、
修正がかなり必要だったので、ここで紹介しておきます。
Qt は、qt-everywhere-opensource-src-4.7.4.tar.gz を
http://get.qt.nokia.com/qt/source/
からダウンロードして使いました。
修正したのは以下の点です。
- float 関数に関する修正 (ceilf(), fmodf())
- trunc() がないことに関する修正
- stdint.h がないことに関する修正
いずれも Solaris 9 ではありがちなものですが、
実は Qt 4.7.4 は、マルチプラットホーム指向というだけあって
ソースを見るとある程度その辺りの対応もできているのですが、
Solaris 9 への対応ができていない (抜けている ?)
部分が上のパッチの対象部分です。
なお、configure オプションの指定によっては、
さらに修正が必要になるかもしれませんが、
その場合は上のパッチを参考にすればいいだろうと思います。
以前、Qt 4.5.2 をコンパイルしたときはこのようなパッチは
必要なかったように思いますが (qt-x11-opensource-src-4.5.2.tar.gz)、
今回このようになったのは、
Solaris でコンパイルする人が減っているのか、
または今どき Solaris 9 を使っている人がいないか
(Solaris 10 には float 関数も trunc() も stdint.h もあるようです)
のどちらかなんでしょうか。
- (10/28 2011)
(しおり用)
「Unix に関するメモ等 (03/06 2009)」
に書いた Solaris 9 での ming-0.4.2 のコンパイルの問題の件ですが、
最近 ming-0.4.4 が出たのでコンパイルしてみたら、
いくつかは解消されているようですが、
やはり同様の問題が起きたので、ML に報告してみました。
そうしたら私のパッチにも多少問題があることがわかって、
修正しましたので、それを下に置きます。
今回気がついた問題は以下のものです。
- perl_ext/Makefile.PL の LIBS の設定のため
freetype 等のライブラリが認識されない
([ $libs ] を "-L/hoge/lib -R/hoge/lib $libs" に変える)
- test/actionscript/ActionScriptTest.c に
util/makeswf.c にある vasprintf() を追加
- util/parser.c の for 文というよりも
むしろ初期化がされない可能性があることが問題
(listswf の出力する GlyphIndex[] の値が不正になる)
- util/read.c の little endian を仮定して書かれている
readDobule(), readFloat() を big endian にも対応させる
- test/Video/test0{1,4,5}.php に、
必要なら「set_time_limit(0)」などを入れる
(非力なマシンでは、これを入れないと 30 秒のタイムアウトに引っかかる)
- tcl を標準でないディレクトリにインストールしている場合に、
実行バイナリはみつかるのにライブラリ、ヘッダファイルが見つけられない
(パッチにある configure, configure.in の修正で対応可能)
- python, perl, php の test (make check) 用のスクリプトが、
/usr/bin にバイナリがあるとして書かれている
- perl_ext の Makefile (Makefile.PL が生成) で、
install ターゲットに「PREFIX=$(prefix)」がつくので、
perl とは違う場所に ming をインストールしようとすると
perl 用のライブラリが適切な場所に入らない
(手動で perl_ext/Makefile を修正するのが楽 ?)
- py_ext/Makefile.in の all-local のターゲットでは
LDFLAGS の設定が反映されないので、コンパイルに失敗する
(強引に CFLAGS= の中に $(LDFLAGS) も入れれば解消する)
- py_ext/Makefile.in の install ターゲットに、
$(prefix) で prefix を指定しているところがあるので、
python とは違う場所に ming をインストールしようとすると
python 用のライブラリが適切な場所に入らない
($(prefix) を `python-config --prefix` に変えれば解消する)
- make check で test/Media/font-kerntest.fdb がないと言われる
(http://bugs.libming.org/attachment.cgi?id=29 から取得できる)
上のパッチで解消している問題もありますが、
そうでないものもかなりあります。
なお、パッチや上の問題なども、
次のバージョンでいくつかは直してもらえることになりそうです。
なお、7. については、「#!/usr/bin/php」等を「#!/bin/bin/env php」
に変えたらどうか、といった話もしていました。
こちらの方が汎用性があっていいですね。
- (09/08 2011)
(しおり用)
Tgif 4.2.5 ですが、EPS ファイルに export した日本語が化けることがある、
という問題が起きました (というか気がついていませんでした)。
.obj ファイルの str_seg 行に文字列が保存されていますが、
日本語の場合はそこに日本語フォント名が入り、_DoubleByte フィールドが
1 になります。そしてその次の _DBModBytes フィールドなんですが、
これが何をするものなのかよくわからないのですが、
どうやらこの値によって文字化けしているようです。
それが 1 のときは文字化けし、0 のときは文字化けしません。
1 のときは、できた EPS ファイル内の 2 バイトコード (EUC-JP)
の 8 bit 目が落ちているようです。
昔の .obj ファイルを見たら、一つの .obj ファイル内で、
_DBModBytes フィールドが 0 の日本語文字列の str_seg 行と、
_DBModBytes フィールドが 1 の日本語文字列の str_seg 行が
混在しているものもありました。
これは tgif 4.2.5 で処理すると、当然一部の文字列は化けず、
一部は化ける、となります。
問題のコードはすぐに見つかり、
tgif-4.2.3 からそのパッチが入っているようですが、
作者に報告したところ、以下のパッチで改善する、と連絡がありました。
詳しくは
http://bourbon.usc.edu/tgif/download.html#tgif-QPL-4.2.5b
を参照してください。
EUC-JP の環境では、とりあえず問題は解消するようです。
- (08/04 2011)
(しおり用)
「Unix に関するメモ等 (08/01 2011)」
に書いた、Tgif 4.2.X が SIGSEGV で落ちる件ですが、
作者に報告したところ、以下のパッチの方が正しい、
という返信がありました。
各最終フィールドの SVG のエントリが抜けていたようです。
次期バージョンには反映されるようです。
- (08/02 2011)
(しおり用)
「Unix に関するメモ等 (08/01 2011)」
に書いた、Tgif 4.2.5 のメニューの日本語が正しく表示されない件ですが、
普段 remote の FreeBSD (8.1) から作業していて
そちらからだと表示されないのですが、
Solaris 本体で使用したら問題なく日本語が表示されました。
よって、フォントかリソースの設定の問題で
remote からは表示できないだけのような気がします。
なお、Xutf8TextListToTextProperty() を持っているような
新しい X lib を無理矢理 tgif に Solaris 9 上でリンクしてみたら、
FreeBSD からでもちゃんと日本語が表示されるようになりました。
とすると、もしかしたら X (X lib) のバージョンによる問題なのかもしれません。
(cf. 「Unix に関するメモ等 (04/04 2013)」)
- (08/01 2011)
(しおり用)
tgif 4.2.2, 4.2.5 を Solaris 9 + gcc-3.4.3 でコンパイルしたのですが、
いずれも左上の Print/ExportFormat menu (「LaTeX(EPS)」と表示されているもの)
を何回かクリックしていると
「SIGSEGV signal received.」というメッセージを出して落ちてしまいます。
これは、以下のパッチで解消されるようです。
なお、Solaris 9 は UTF-8 関連の X の関数がまだ入ってなくて、
tgif 4.2.X をコンパイルしようとすると
Xutf8TextListToTextProperty() がないと言われます。
これは、tgif 4.2.5 では -D_NO_XUTF8FUNCTIONS
をつけることでコンパイルが通るようになっています。
しかし、そのためかどうかわかりませんが、
4.2.5 では今度は -DENABLE_NLS をつけてコンパイルしても
メニューの日本語が正しく表示されなくなってしまうようです。
これについては、もう少し調べてみたいと思います。
(cf. 「Unix に関するメモ等 (08/02 2011)」,
「Unix に関するメモ等 (08/04 2011)」)
- (03/30 2011; no.2)
(しおり用)
Solaris 9 で autogen-5.X をコンパイルしていたのですが、
どうしてもエラーがでて困っていました。
Web で検索しても適当な情報が見つかりませんでしたが、
なんとか解決したのでまとめておきます。
コンパイル環境は、Solaris 9, gcc-3.4.3, guile-1.8.8, libxml2-2.7.8,
rx-1.5 (,bash-4.2) です。
configure では以下のようにしています (csh 環境上):
set prefix = /usr/local
setenv LIBS "-lrx"
setenv CPPFLAGS "-I$prefix/include"
setenv LDFLAGS "-L$prefix/lib -R$prefix/lib"
setenv CONFIG_SHELL $prefix/bin/bash
./configure --prefix=$prefix --with-regex-header="rxposix.h"
--disable-shared
configure してみると言われるのですが、
正規表現ライブラリは POSIX のものが要求される
(例えば rx を使えと言われる) ので、
librx.a, rxposix.h を使うために LIBS, CPPFLAGS, LDFLAGS,
および configure オプションの --with-regex-header
を指示通りに指定しています。
しかし、その後で make すると xml2ag/ の中の make
で以下のようなエラーが出て止まってしまいます:
top_builddir=.. top_srcdir=.. PATH=`cd ../columns;pwd`:$PATH ;
export top_builddir top_srcdir PATH ;
/hoge/fuga/autogen-5.11/agen5/autogen -MFstamp-opts -L../autoopts
--definition=./xmlopts.def
Error in template /hoge/fuga/autogen-5.11/autoopts/optlib.tpl, line 373
DEFINITIONS ERROR in
/hoge/fuga/autogen-5.11/autoopts/optlib.tpl line 373 for xmlopts.h:
Error: value for opt output is `O'
must be single char or 'NUMBER'
Failing Guile command: = = = = =
(error (sprintf
"Error: value for opt %s is `%s'\nmust
be single char or 'NUMBER'"
(get "name") (get "value")))
autogen-5.8, 5.9, 5.10 でもほとんど変わりません。
そもそもエラーメッセージに矛盾があるようにも見えます
('O' が一文字でなければならない ?)。
上記のエラーの箇所を色々調べてみたところ、
どうも autogen バイナリの正規表現のマッチングが
うまくいってないことに気がつきました。
つまり、せっかく指定してリンクしているはずの rx ライブラリが
使われていないようなのです。
実は、Solaris 9 には libc 内に正規表現関数 (regcmp() 等)
が既に用意されているようですが、
それが autogen では使えない (POSIX でない ?) らしく、
それを使おうとすると configure にはじかれてしまいます。
それで rx を使うために指示通りに上のように configure 時に
LIBS で -lrx を指定したのですが、なぜかそれが使われておらず、
libc 内の正規表現関数が使われてしまっているのがエラーの原因のようでした。
コンパイルログを見るとそれは libtool の仕業で、
libtool が勝手に -lrx よりも前に -lc をつけてしまっています。
よって、agen5/Makefile.in に以下のようなパッチを当てて、
-lc を -lrx よりも後ろにくるように autogen を make したら
ようやくうまく行きました。
一応 autogen-5.11.6 用ですが、どのバージョンでもそう違わないと思います。
- (03/30 2011)
(しおり用)
Unicode 関連で 2 点報告します。
-
PDF ファイルの表示に最近は xpdf-3.02 を使用しているのですが、
LaTeX の utf パッケージで生成した文字 (「日の下に立」の漢字)
を dvipdfmx で作った pdf ファイルを見ようとしたら、
*-Identity-H がないとか言われました。
xpdfrc (~/.xpdfrc) に以下のような displaCIDFontTT
の設定を入れたら出なくなりました:
displayCIDFontTT Adobe-Japan1 /XXX/YYY/ipam.ttf
また、このままだとゴシック体も明朝体も全部 ipam.ttf
になってしまいますが、それも以下のような設定で解消しました。
displayNamedCIDFontTT Rymin-Light /XXX/YYY/ipam.ttf
displayNamedCIDFontTT GothicBBB-Medium /XXX/YYY/ipag.ttf
-
上の、utf パッケージを利用した出力は、xdvi, dvipdfmx はいいんですが、
dvips の出力の表示/印刷がうまく行きませんでした。
調べてみると、dvips の設定というよりは、
表示の gs の設定やプリンタの問題のようでした。
上の utf パッケージを使用した文字は、dvips の出力では
Ryumin-Light-UniJIS-UTF16-H になっているようです。
gs は gs7.07 を使っているのですが、
CMap のディレクトリには UniJIS-UCS2-H はありますが、
UniJIS-UTF16-H が入っていませんでした
(acro5-cmaps-2001.tar.gz, adobe-cmaps-200204.tar.gz)。
よって、xpdf の日本語化で使用したファイル (xpdf-japanese)
に含まれる UniJIS-UTF16-H を
gs の CMap ファイルのディレクトリにリンクを貼ることで
正しく表示されるようになりました。
印刷は、PS プリンタでやっているのですが、
これはプリンタ内の PS インタプリタの問題でどうにもならないので、
コンピュータ側で ps2ps でラスタライズしてから
プリンタに送ることでうまく印刷できるようになりました。
なお、UniJIS-UTF16-H は aj16.tar.Z に含まれているようです。
- (02/21 2011)
(しおり用)
学生のデータ持ち帰り用として、
Solaris 9 での USB メモリの利用について調べてみました。
まず、UnixUser 2005 11 月号にある、という情報を見つけましたが、
これは第 2 特集である「何でも接続 ! USB 活用術」の方ではなく、
p134-135 の「UNIX 処方箋」の方に書いてあります。
Blade150 (Solaris 9) では、USB メモリを差して
vold に HUP シグナルを送れば自動的に認識してくれて、
eject -n でそれに対応する項目が出力される、
と書いてあるのですが、残念ながらそれはうまく行きませんでした。
ルートで volrmmount -i rmdisk0 とするとマウントされる、
と書いてあるのですが、それもだめです
(うちも Solaris 9 の Blade 150 なんですが)。
しかし、dmesg を見ると一応それらしい表示はあるので、
つながってはいるようです。volcheck -v をすると、
USB メモリをつないでいないときは「媒体が見つかりませんでした」
となるのですが、つなぐと「媒体が見つかりました」と出ますので、
それなりに認識されているようです。
/usr/sbin/cfgadm でも、つないだ場合には
Ap_Id Type Receptacle Occupant Condition
c0 scsi-bus connected configured unknown
usb0/1 unknown empty unconfigured ok
usb0/2 usb-storage connected configured ok
usb0/3 usb-kbd connected configured ok
usb0/4 usb-mouse connected configured ok
のように表示されます (usb0/2 の usb-storage が USB メモリ)。
ということで手動でのマウントをしてみました。dmesg の出力から、
usb0/2 に対応しているのは /dev/dsk/c2t0d0s0 だとわかりました
(ls -l /dev/dsk と dmesg のデバイス名を比較してみるとわかる) ので、
# /sbin/mount -F pcfs /dev/dsk/c2t0d0s0 /mnt
としてみたのですが、
「mount: /dev/dsk/c2t0d0s0 is already mounted, /mnt is busy,
or allowable number of mount points exceeded」
のように表示されるだけでマウントできません。
s0 を s1, s2 のように変えてみても変化なしです。
さらに情報を探してみると、どうやらデバイス名の最後に
:c のようなものをつけるらしい、とありましたので、
# /sbin/mount -F pcfs /dev/dsk/c2t0d0s0:c /mnt
とやったらうまくいきました。これを sudo で学生に許可すれば、
家にデータを持ってかえるのも楽にできそうです。
- (02/08 2011)
(しおり用)
UTF-8 への対応や SVG 出力ができる Tgif-4.2.2 が出ていました。
内部で Xutf8TextListToTextProperty() なる
UTF-8 用の関数を使っているようですが、
Solaris 9 にはありません。
XmbTextListToTextProperty() は libX11.so 内にあるようです。
よって、ローカルに新しい libX11 (libX11-6.2.1)
を必要なもの (例えば libXau-0.1.1) とともにインストールして、
そちらを参照するようにしてコンパイルしました。
しかし、そのせいか不安定なようで「SIGSEGV signal received.」
などと言って落ちることがあるようです。
ちなみに SVG への出力は自前ではなく、pstoedit などを使用するようです。
- (02/04 2011)
(しおり用)
OpenOffice 3.X は Solaris 10 を要求するようなので、
Solaris 9 用に OpenOffice 2.4.2 を入れてみました。
OOo_2.4.2_SolarisSparc_install_ja.tar.gz をダウンロードして、
展開して root で
./update
とすると GUI のインストーラーが立ち上がって対話的にインストールが進みます。
/opt/openoffice.org2.4/program/soffice
を実行するととりあえず使えるようなので、
パスの通っているところにこれのリンクを貼りました。
- (12/31 2008)
(しおり用)
うちの Solaris 9 には、今まで firefox は、
以下の contrib/ にあるボランティアによる Solaris 8 用の
コンパイル済みバイナリをインストールしていまいた。
ところが、以下のような事情で、
今回は 2.0.0.20 のソースを自前でコンパイルしてみました。
- firerox 3.X の Solaris 用のコンパイル済みバイナリは、
Solaris 10/OpenSolaris 用のものしかなく、
それらはうちの Solaris 9 では動作しない
- firefox-2.0.0.19 の直後に出た firefox-2.0.0.20 の
Solaris 用バイナリがいつになっても出てこない
- 今後は、firefox 3.X もソースからコンパイルしないといけないかもしれない
実は今までもコンパイルしてみたことはあったのですが、全然うまくいかず、
しかも Solaris でのコンパイルに関する情報が
ほとんどなかったのであきらめていたのですが、
今回は少し気合いを入れてやってみました。
そのときの話をここにまとめておきたいと思います。
従来の Solaris 8 用のバイナリは gtk1 でコンパイルされていたのですが、
Solaris 9 には、gtk は以下のように 2 種類入っているようです。
- gtk+/glib 1.2 (/usr/sfw/include, /usr/sfw/lib)
- gtk+/glib 2.0 (/usr/include, /usr/lib)
まずは /usr/lib の方を使って gtk2 でのコンパイルを試みました。
コンパイラは gcc-3.4.3 です。
-
環境変数を以下のように設定します (うちは tcsh)。
set path = ( $prefix/bin /usr/bin $path )
setenv PKG_CONFIG_PATH
"$prefix/lib/pkgconfig:/usr/lib/pkgconfig"
setenv LDFLAGS
"-L$prefix/lib -L/usr/lib -R$prefix/lib:/usr/lib"
setenv CPPFLAGS "-I$prefix/include -I/usr/include"
なお、$prefix はインストール先ですが、
ここは最初は何もインストールされていないディレクトリです。
これらの変数に /usr/sfw を入れてしまうと
そちらの glib.h などをインクルードしようとして失敗しますので、
この場合は /usr/sfw を入れないようにします。
-
pango は /usr/lib には pango-1.0.0 しか入ってないのですが、
configure では 1.1.0 以上を要求されます。
よって先に $prefix にそれより新しい pango を入れる必要があります。
ただし、pango-1.1.5 以上だと glib-2.1.3 以上を要求されるのですが、
/usr/lib には glib-2.0.7 しか入ってません。
だから、pango-1.1.4 などを入れる必要があります。
しかし、pango は freetype ライブラリを必要としますので、
pango のコンパイルでは /usr/sfw を入れないといけません
(/us/lib には freetype ライブラリが入ってない)。
よって、pango のコンパイル時だけ
上の PKG_CONFIG_PATH, LDFLAGS, CPPFLAGS に
/usr/sfw の各ディレクトリを追加してコンパイルしました。
また freetype に関して、直接「#include <freetype/freetype.h>」
と書いてあるところは、以下のように変更する必要がありました。
#include <ft2build.h>
#include FT_FREETYPE_H
-
X のディレクトリの /usr/openwin は自動的に認識してくれるのですが、
そこにある Xrender.h (/usr/openwin/include/X11/extensions/Xrender.h)
は古いのか PictStandardA4 等が定義されてなくて、
それでコンパイルに失敗します。
よって、render-0.8.tar.gz, xrender-0.8.3.tar.gz を
$prefix に入れておきます。
これはほぼ configure ; make ; make install でできます。
-
/usr/include/gnome-vfs-2.0/libgnomevfs/gnome-vfs-{file-info,xfer}.h の
enum の定義の最後に ',' が残っているところでエラーが出ますので、
それを削除しておきます。
-
mozilla/.mozconfig は、とりあえず以下のように設定しました。
. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff
ac_add_options --disable-libxul
#ac_add_options --enable-debug --disable-optimize
ac_add_options --disable-debug --disable-test --enable-optimize
ac_add_options --enable-shared --disable-static
#ac_add_options --disable-shared --enable-static
ac_add_options --disable-crashreporter
ac_add_options --enable-svg
ac_add_options --prefix=$prefix
debug と tests を disable にしておかないと、
できあがったバイナリを実行すると
ずらずらとデバッグメッセージが表示されるものができます。
--disable-libxul, --disable-crashreporter は、
Solaris に関する情報としてあったようなのでつけておきました。
これで gmake -f client.mk build すると、gtk2 などを認識してくれます。
この設定でコンパイルすると、
そのバイナリ等は mozilla/obj-ff/ 以下にできます。
-
リンクオプションに不正なオプションがあったので、
configure が済んだあとで mozilla/obj-ff/config.status を見ると、
s%@MOZ_FIX_LINK_PATHS@%-Wl,-rpath-link,$(DIST)/bin%g
となっていました。これは Solaris の ld では
s%@MOZ_FIX_LINK_PATHS@%-R $(DIST)/bin%g
とならないといけません。よって、configure を直接修正して、
そのようになるように変えました。
-
うちは gcc を /usr/local/GNU に入れてあるのですが、
できたバイナリ、shared library が libgcc_s.so が引けない
問題が起こることがあるので、
それを -R/usr/local/GNU/lib として入れる必要があります。
それを LDFLAGS とデフォルトの設定
(mozilla/security/coreconf/SunOS5.9.mk) に入れておきます
(LDFLAGS だけではうまくいかないようです)。
setenv LDFLAGS "$LDFLAGS -L/usr/local/GNU/lib
-R/usr/local/GNU/lib"
-
せっかく上で $prefix に Xrender をインストールしたのですが、
cairo のコンパイル時にコンパイルオプションとして
/usr/openwin を $prefix より先につけてしまうので、
$prefix の方を読んでくれません。
よって、環境変数として以下を追加する必要がありました。
setenv X_CFLAGS
"$prefix/lib/pkgconfig:/usr/lib/pkgconfig"
setenv X_LIBS
"-L$prefix/lib -L/usr/lib -R$prefix/lib:/usr/lib"
-
freetype ライブラリのヘッダファイルも必要となるようなのですが
(mozilla/gfx/src/ps/nsFontMetricsPS.h)、
そのヘッダファイルを探せないようなので、
$prefix にヘッダファイルへのリンクを入れ、
configure スクリプトに freetype ライブラリ (に必要なもの) を追加しました。
pushd $prefix/include
ln -s /usr/sfw/include/ft2build.h .
ln -s /usr/sfw/include/freetype2/freetype .
popd
-
コンパイルは gmake -f client.mk build とせよ、とあるのですが、
インストールについてはあまりちゃんと書いてありません
(インストーラーを作るには、なんてのはあるみたいですが)。
けどそれは、gmake -f client.mk install でできました。
とりあえずこれで一応動くものができましたが、
やはりだいぶ感じが違っています (し、多少問題もありました) ので、
インストールした $prefix ディレクトリの名前を一旦 mv で変えておいて、
今度は 2.0.0.19 のバイナリ配布物と同じようなもの (gtk1)
を作ってみることにしました。
-
mozilla/.mozconfig の設定はよくわかりませんが、
ldd で 2.0.0.19 の引いているライブラリと 2.0.0.20 のライブラリを比較して、
違っているところを設定するようにして、今度は以下のようにしてみました。
. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff2
ac_add_options --disable-libxul
#ac_add_options --enable-debug --disable-optimize
ac_add_options --disable-debug --disable-test --enable-optimize
ac_add_options --enable-shared --disable-static
#ac_add_options --disable-shared --enable-static
ac_add_options --disable-crashreporter
ac_add_options --enable-svg
ac_add_options --enable-crypto
ac_add_options --enable-default-toolkit=gtk
ac_add_options --prefix=$prefix
変更点は、obj-ff2 にしたこと、
--enable-crypto と --enable-default-toolkit=gtk (gtk1) としたことです。
-
環境変数は今度は以下のように設定します。
set path = ( /usr/sfw/bin $prefix/bin /usr/bin $path )
setenv PKG_CONFIG_PATH
"/usr/sfw/lib/pkgconfig:$prefix/lib/pkgconfig"
setenv LDFLAGS
"-L/usr/sfw/lib -L$prefix/lib -L/usr/local/GNU/lib"
setenv LDFLAGS
"$LDFLAGS -R/usr/sfw/lib:$prefix/lib:/usr/local/GNU/lib"
setenv CPPFLAGS
"-I/usf/sfw/include -I/usr/sfw/lib/glib/include
-I$prefix/include"
setenv X_CFLAGS "$CPPFLAGS"
setenv X_LIBS "$LDFLAGS"
この場合は /usr/lib を入れないようにします。
-
libIDL が必要なようです。
/usr/lib にも入ってるのですが、
これは glib-2.0 を引いていますので多分使用できません。
少し前の libIDL を入れる必要があるようなので、
libIDL-0.6.8 を $prefix に入れました。
ほぼ configure ; make ; make install でできるのですが、
途中で libtool が LDFLAGS に入れてある -R の設定を抜いてしまうようで、
できたライブラリが /usr/sfw/lib の shared ライブラリを
一部引けていませんでした。よって、make の際には、
( setenv LD_RUN_PATH /usr/sfw/lib ; make )
としました。
-
Xrender の問題はやはり起こるようだったので、
先にコンパイルした Xrender のヘッダとライブラリを
新しい $prefix にもコピーしました。
-
obj-ff2/dist/include/gfx/nsIFreeType2.h で FTC_Image_Cache がない
とかいうエラーがでました。
確かに freetype のヘッダファイルにはそういうものはないようでしたが、
FTC_ImageCache はあったので、その変更だけすればいいのかな、
と思ったらそうではありませんでした。
これは検索したら情報が見つかりました。
主にこの後者を参考に、以下のようなパッチを作って対処しました。
とりあえずこれでめでたくそれなりに使えるものができました。
なお、上の .mozconfig では native の svg を有効にしてあるのですが、
実際に svg ファイルを開くと firefox が落ちてしまいます。
あまり安定していないようなので、
もう少し様子を見て外そうかと思っています。
- (09/08 2008)
(しおり用)
私は今まで HTML ファイルは主に emacs-19.34 (mule-2.3) を使って書いていて、
html-mode は元々 emacs 付属の sgml-mode のまま、
font-lock も色を多少変える程度で
ほとんどカスタマイズもせずに使っていました。
今後、HTML を emacs-20.7 で書かないといけなくなったのですが、
コメントの部分の font-lock の表示が以下のように変わってしまっていて、
今までと同じ作業をするのがやや面倒になってしまいました。
- emacs-19.34 の html-mode (sgml-mode) では、
- 複数行にわたるコメント行 (<-- のある行と --> のある行が異なる)
もそのコメント部分全体がコメントの色になる
- コメント内にタグ (<b> など) があっても
それは無視され全体にコメントの色がつく
- コメント内に文字列 (" " で囲まれたもの) があっても
それは無視され全体にコメントの色がつく
- emacs-20.7 の html-mode (sgml-mode) では、
- 複数行にわたるコメント行 (<-- のある行と --> のある行が異なる)
にコメントの色 (font-lock-comment-face) がつかない
- コメント内にタグ (<b> など) があると、
内部のタグ部分にそのタグ用の色などがついて、コメントの色がつかない
- コメント内に文字列 (" " で囲まれたもの) があると、
内部の文字列部分にその色がついて、コメントの色がつかない
HTML ファイルを更新するときに、[Update] などの強調表示部分や、
あるブロックをコメントアウトしたりすることはよく行うので、
そこがまるまるコメント部分らしく表示されないと、
どこがコメントアウトされているのかそうでないのかが非常にわかりづらく、
更新作業にやや支障をきたし始めていました。
インターネットで情報を検索したり、
両者の font-lock.el や sgml-mode.el を比較してみたりしたのですが、
どうもよくわかりませんでした。
他の html-mode (yahtml, psgml) などを見てもよくわからなかったのですが、
結局 html-helper-mode (のβ版) を参考にしながら、
以下のようなもので適当に逃げることができました。
(font-lock-add-keywords
'html-mode
'(("<!--\\([^-]\\|-[^-]\\)*-->"
0 font-lock-comment-face t)))
html-helper-mode には、コメント内の "--" の扱いを考慮して
もうちょっと複雑に書いてあるのですが、
私はまあコメント内に "--" を書くことはほとんどなかろうと思って
簡単にしてあります。
とりあえず上のような対処で、
今までのように HTML ファイルの一部分を
簡単にコメントアウトできるようになってほっとしています。
- (05/05 2008)
(しおり用)
学生が Mew を使っているのですが、
署名がついていないことに気がついて、
はて、自動的に署名をつけるにはどうするのかと調べてみました。
インターネットで検索すると、
以下のようにするという情報が 2 件ほどみつかりました:
(setq mew-signature-insert-last t)
(add-hook 'mew-send-hook 'mew-draft-insert-signature)
1 行目のものは、signature を本文最後にとりこむための設定、
2 行目のものが、メール送信時に C-c TAB を行ったのと
同じ動作をさせるための設定です。
ただ、これだと Draft バッファでメール本文を作成したときには署名はなくて、
最後に C-c C-c でメールを送信しようとしたときに署名がつきます。
だから、署名を C-c TAB で取り込んだ後にメールを送信してしまうと
2 つの署名をつけてしまいますし、
逆に署名を消してメールを送ることができません。
これを解消するためには、「Draft バッファが開いたときに
signature を自動的に取り込むようにする」とすればいいのですが、
Mew のソースを見ながらテストしてみたら、
以下のような感じでそれができそうなことがわかりました:
(setq mew-signature-insert-last t)
(add-hook 'mew-draft-mode-hook 'mew-draft-insert-signature)
(add-hook 'mew-before-cite-hook
(function (lambda ()
(goto-char (mew-header-end))
(forward-line))))
この 2 行目は、Draft モードになったときに最後の方で実行される設定です。
しかし、これだけだと、w (新規の送信メールの作成) や
a (引用なしの返信作成) はいいのですが、
A (引用ありの返信作成) の場合に、
本文に署名が書かれた後に引用 (citation) が行われてしまうので、
mew-signature-insert-last の設定に関わらず、
署名の下に引用部分がついてしまいます。
これを回避するために、3 行目以降の設定を行っています。
mew-befor-cite-hook は、引用のとりこみ前に実行されるもので、
そこで現在位置をメールの本文の先頭 (ヘッダの最終行の次の行)
へと移動しています。
そこに引用を取り込めば、ヘッダと署名の間にうまく入ってくれるわけです。
もちろん、引用を署名の後ろに書きたい
(商用メールはそういう形式が多いようですが) 場合には、
この 3 行目以降の設定は不要です。
- (03/09 2008)
(しおり用)
最近 Solaris (9) のマシンに PostgreSQL-8.3.0 をインストールしたのですが、
少し問題がありましたので、ここにまとめておきます。
-
まずは、OpenSSL サポートもあるようだったので、
それをつけて (configure --with-openssl)
普通にコンパイルしたら link エラーが大量に発生しました。
これは、OpenSSL のライブラリ libcrypto, libssl を
static ライブラリ (.a) しか作っていないためのものです。
OpenSSL のドキュメントを見るとわかりますが、
デフォルトでは OpenSSL は shared ライブラリは
作らないようになっているようです。
この問題を回避するには、例えば以下のような 3 通りの方法があります。
- PostgreSQL を configure --disable-sharedで
shared ライブラリをサポートしないようにする
- OpenSSL サポートをやめる (configure --without-openssl)
- OpenSSL の shared ライブラリ (.so) を作る
(OpenSSL の再インストール)
OpenSSL も新しいものが出ていたので、
ここでは最終的には最後のものを選択しましたが、
実は最初は --disable-shared を選択して
PostgreSQL をコンパイルしたのですが、
もう忘れてしまいましたが何か問題があったように思います
(make check だったかな ?)。
-
--with-python で Python サポートもしようとしたのですが、
やはり libpython が static ライブラリしかないのでだめでした。
-
私は /usr/local のライブラリを、
/usr/local 以下にさらにディレクトリを掘って分散して置いていて
そのために LDFLAGS に
"-L/usr/local/hoge/lib -R/usr/local/hoge/lib"
みたいなものを複数入れることが多いのですが、
コンパイル後にできたバイナリを ldd で調べてみたら、
いくつかの shared ライブラリが引けていないことに気がつきました。
それらは LDFLAGS にはちゃんと入れてあるのでなぜかと思ったのですが、
"configure --disable-rpath" としないと、
src/Makefile.global で LDFLAGS に "-Wl,R'$prefix/lib'"
のようなものを追加してつけてくれるようで、
それで $prefix/lib 以外にある
一部のライブラリが引けなくなっているようでした。
ということで、それは
"configure --disable-rpath" として
そのリンカオプションの追加をやめ、
LDFLAGS に "-L$prefix/lib -R$prefix/lib"
も追加することで対処しました。
-
コンパイル後に make check すると、
initdb でセマフォのリソースが足らん、といったようなメッセージが出ました。
以下 (PostgreSQL 8.1.4文書: 第 16 章オペレーティングシステムの環境)
の 16.3.1 節の最後のものとほぼ同じです:
そこに示されている通り、/etc/system に設定を追加しました:
set semsys:seminfo_semmni=100
set semsys:seminfo_semmns=100
set semsys:seminfo_semmsl=32
set semsys:seminfo_semopm=20
ただし、示されている推奨値よりも多少控え目な数値にしてあります。
OS を reboot すると、/usr/sbin/sysdef の結果は、
最初はうまく更新されませんでしたが、
しばらくして (後で make check した後だったか)
やってみたらうまく更新されていました。
ただ Solaris 10 では、System V IPC 関連のパラメータは、
/etc/system に設定して reboot するという方式ではなくなった、
という情報があります:
-
$prefix/lib/postgresql/ のファイル (shared ライブラリモジュール) を
調べて気がついたのですが、こちらのライブラリを作成するときは
LDFLAGS の設定が効かず -R... がつかないので、
やはりいくつかのライブラリが引けなくなっていました。
このライブラリの作成時は、LDFLAGS_SL なるものを参照するようなので、
LDFLAGS_SL に LDFLAGS と同じものを設定して configure,
make をやり直しました。
-
これで make check は通るようになったのですが、
ドキュメントにある通りインストール後に
initdb を実行してテストしてみるとうまく行かず、
以下のようなエラーが出ます:
creating conversions ... FATAL: could not access file
"$libdir/ascii_and_mic": No such file or directory
色々と調べてみたところ (initdb や postgres のソースなども)、
結局、これは $prefix/share/postgresql/ にある以下の 3 つのファイルに
そのように書かれているためだとわかりました:
conversion_create.sql, snowball_create.sql, postgres.bki
本来は、これらを作成するところを修正するとか、
別な設定で修正するのが筋なのかもしれませんが、
とりあえずこれらのファイルに書かれている "$libdir"
という文字列を、実際に ascii_nad_mic.so がある
"/usr/local/hoge/lib/postgresql" のような文字列に
sed を使って変換することで回避しました。
まだ問題が含まれている可能性は十分にありますが、
とりあえず以上のような対応で、なんとか make check,
およびインストール後の簡単なテストが通るものができました
(ここまでに何度 configure ; make ; make intall を繰り返したことか...)。
- (02/19 2008)
(しおり用)
最近 Solaris (9) のマシンに libsvg (0.1.4), libsvg-cairo (0.1.6)
svg2png (0.1.3), svg2pdf (0.1.3), xsvg (0.2.1) をインストールしたのですが、
少し問題がありましたので、ここにまとめておきます。
なおこれらは、以下にあります:
まず libsvg-0.1.4 ですが、stdint.h がないと言われます。
configure では stdint.h や inttypes.h のチェックはしているのですが、
実際にはそれが有効に使われていないようで、
以下のようなパッチを当てる必要があります:
次に libsvg-cairo はすんなりコンパイルできたのですが、
svg2png, svg2pdf, xsvg は Solaris にはない getopt_long() を使っているので、
GNU gentetopt (2.21) をインストールしてそれをカバーしました。
ただ、gengetopt の make check でこけるので、それを修正する必要があります:
gengetopt を使うには、例えば svg2png ディレクトリで
以下のようにすればいいです。
cd src
ln -s /usr/local/share/gengetopt/gnugengetopt.h getopt.h
gcc -I. -c -o getopt.o /usr/local/share/gengetopt/getopt.c
gcc -I. -c -o getopt1.o /usr/local/share/gengetopt/getopt1.c
cd ..
make 'AM_LDFLAGS=getopt.o getopt1.o'
なお xsvg のコンパイルでは、
-lXrender, -lX11 のライブラリフラグもつかなかったので、
make 'AM_LDFLAGS=getopt.o getopt1.o -lXrender -lX11'
とする必要がありました。
これで SVG ファイルを見てみたのですが、
なぜか緑色 (green) が出ません。
調べてみると、どうやら libsvg のバグのようです。
src/svg_color.c に色の表があるのですが、
それに対して色文字列から色データを引くときに bsearch() を使っていて、
bsearch() は元々の表がソートされていないといけませんが、
実際には 2 箇所程ソート順になっていないものがあって、
そのせいで green, greenyellow, mediumnightblue の 3 色が出なくなっています
(黒になります)。
これは以下のパッチで修正できます:
色名にも多少ミスプリントがあるようですが、それは直していません。
- (02/09 2008)
(しおり用)
Solaris のマシン (Solaris 9, Ultra 1, gcc-3.4.3) 上で
guile-1.8.2 のインストールをやったのですが、
多少てこずりましたので、ここにまとめておきます。
まず、普通に configure & make でコンパイルしたのですが、
で報告されている問題が起きました。これは、
でパッチが紹介されていました。
しかし、これには configure.in の修正も含まれていたので、
autoconf, automake も新しくし (autoconf-2.61, automake-1.10)、
そして autoreconf して configure & make したのですが、
今度は
で紹介される問題が起きます。
これに対しては、そこで紹介されている回避策の一部を使って回避しました。
しかし今度は make check がうまくいきません。
よく見ると、autoreconf した後で configure したものが
どうもうまく行っていませんでした。調べてみると、
サブディレクトリ guile-readline/ の中の configure に失敗しています。
見ると、この中にある configure.in で生成される configure に
. だけの行とか、" だけの行のようなゴミのようなものがあります。
オリジナルの configure スクリプトと比較してわかったのですが、
例えば「"1.8.2"」のような部分 (バージョン表記) が、
なぜか「"-n 1.8.2」と、
そこで改行された次の行の「"」単独行に分けられてしまっていました。
configure.in の対応する部分を見ると
「echo -n ${GUILE_VERSION}」のようになっていて、
つまり echo の -n オプション (改行文字を最後に出力しない)
が認識されていないために起こっている問題のように見えます。
実際、Solaris の /bin/echo は -n を認識しません。
path を変更してみたりしてもどうにもうまく行かなかったのですが、
guile の top ディレクトリの configure.in に
以下のようなヒントが書かれてありました:
dnl `patsubst' here deletes the newline which "echo" prints.
dnl We can't use "echo -n" since -n is not portable (see autoconf
dnl manual "Limitations of Builtins"), in particular on solaris
dnl it results in a literal "-n" in the output.
ということで、これに従って (そしてその configure.in での実際の
patsubst() の使用法に従って) guile-readline/configure.in
を修正してなんとかなりました。
どうも、top ディレクトリの configure.in では、
そういう (Solaris への) 配慮が取られているものの、
下のディレクトリ guile-readline/ でそれが抜けているような感じです。
make check では一箇所 FAIL を出すのですが、
とりあえず以上のような対処で一通りコンパイルが通るものができました。
以上の対処をパッチにしたものを以下に置きます。
- (01/04 2008)
(しおり用)
「Unix に関するメモ等 (12/21 2007)」
に書いた sh-mode の .emacs の設定の件ですが、
emacs-20.7 の場合、そこに書いた設定だと、
sh-mode で任意のファイルを開いたときに先頭行が書き換えられてしまいます。
emacs-19.34 の場合の sh-mode のデフォルトのように、
新規のファイルを開いたときにだけそれを有効にするには、
以下のようにする必要があります。
(add-hook 'sh-mode-hook
(lambda ()
(and (zerop (buffer-size))
(not buffer-read-only)
(sh-set-shell "/bin/csh" t t)))) ; OK
; (sh-set-shell sh-shell-file t t)))) ; OK
; (sh-set-shell (or (getenv "SHELL") "/bin/csh") t t)))) ; OK
emacs-19.34 では、デフォルトでそう設定されていますので、
そうする必要はありません。
- (12/21 2007)
(しおり用)
私は普段複数のマシンで emacs-19.34 (mule) と
emacs-20.7 (emcws) を使い分けているのですが、
hoge.csh のような名前のファイルを呼び出すと
sh-mode (Shell-script mode) になりますが、
emacs-19.34 では、そのファイルがまだない場合
(つまり新規に作成されるときには)、その先頭に
#! /bin/tcsh -f
のような行が自動的に挿入されていましたが、
emacs-20.7 ではそうはなっていませんでした。
sh-mode の emacs-lisp ファイル sh-script.el を調べてみると、
これは sh-set-shell という関数が行っているようで、
emacs-19.34 では sh-mode 内でデフォルトで
"(sh-set-shell sh-shell-file)"
が評価されているようなのですが、
emacs-20.7 ではそうなっていないために、
自動的な挿入が行われていないようです。
色々試したところ、.emacs に以下のように書けば、emacs-20.7 でも
自動的に上のような先頭行が挿入されるようになるようです。
(add-hook 'sh-mode-hook
(lambda ()
(sh-set-shell "/bin/csh" t t))) ; OK
; (sh-set-shell sh-shell-file t t))) ; OK
; (sh-set-shell (or (getenv "SHELL") "/bin/csh") t t))) ; OK
3 行目の行は、その下の 2 行のいずれかに変えてもいいようです。
逆に、emacs-19.34 では自動的に (sh-set-shell sh-shell-file)
が実行されてしまっているのですが、この sh-shell-file は
(or (getenv "SHELL") "/bin/sh")
のように定義されていますので、
(設定されていれば) 環境変数 SHELL の値が使われてしまいます。
これを、別のものに変えようと、
上のように add-hook を使って切り替えてみると、
実際には直接変わってはくれず、
一度 SHELL の値による先頭行が設定され、それを変更しますか、
という問い合わせが入ってしまうようです。
そこで y と入力すれば、一応設定した値による行に書き換えられます。
なお、emacs-19.34 の場合は、sh-set-shell の最後の
2 つの "t t" は不要なようです。
(cf. 「Unix に関するメモ等 (01/04 2008)」)
- (11/19 2007)
(しおり用)
Canon のデジタルカメラ IXY Digital 10 を買ったのですが、
Solaris 10 だと /usr/sfw/bin に gphoto2 が入っていて
USB からでもデジタルカメラのデータの吸い出しができるようなのですが、
Solaris 9 だと libusb もなく
(Solaris 9 に付属する USB 用の別のライブラリはある)、
USB 経由の gphoto2 が使えないみたいです。
Unix 用の USB 経由のカメラデータ (Canon) の吸い出し (PTP) ソフトとしては、
gphoto2, s10sh, ptpcanon などがあるようですが、
いずれも USB に関しては libusb に依存していて
残念ながら Solaris 9 ではだめみたいです。
このカメラを Blade 150 の USB ポートにつないだときの
認識具合は以下のような感じです:
# cfgadm
Ap_Id Type Receptacle Occupant Condition
...
usb0/2 usb-device connected configured ok
...
# cfgadm -vl
Ap_Id Receptacle Occupant Condition Information When Type
Busy Phys_Id
...
usb0/2 connected configured ok Mfg: Canon Inc.
Product: Canon Digital Camera NConfigs: 1 Config: 0
<no cfg str descr>
...
# cfgadm -c configure usb0/2
cfgadm: Configuration operation invalid: device already configured
for ap_id: /devices/pci@1f,0/usb@c,3:2
cfgadm -vl の方は、Information 以降の表示が桁と対応が
うまく取れていませんのでやや見にくいです。
prtconf で見ると、
# prtconf -v
device (driver not attached)
Hardware properties:
name='usb-product-name' type=string items=1
value='Canon Digital Camera'
name='usb-vendor-name' type=string items=1
value='Canon Inc.'
....
のように表示され、product-ID, vendor-ID なども表示されるのですが、
/var/adm/messages には
usba: [ID 812112 kern.warning]
WARNING: usba: no driver found for device Canon Inc. Canon
Digital Camera DDBFD73AC....
のように出ていて、確かにちゃんとは使え「なさそうな」雰囲気はあります。
FreeBSD ならば、gphoto2 でちゃんと使えるようです (FreeBSD-4.11, 5.4)。
s10sh, ptpcanon はうまくいきませんでした
(
FreeBSD のインストールに関するメモ (11/19 2007) 参照)。
- (09/10 2007)
(しおり用)
うちの Solaris 9 で使っている GNU 系のツールについて 2 点程書きます。
- GNU tar
gcc-4.2.1 のコンパイルをやりはじめたのですが、
libstdc++-v3/include/ext/pb_ds/detail/ の下の、
以下のファイルが見つからない、というエラーが出て止まってしまいました:
resize_policy/hash_load_check_resize_trigger_imp.hpp
bin_search_tree_/constructors_destructor_fn_imps.hpp
directory をよく見てみると、これらのファイルは、
ファイル名が以下のようになってインストールされていました。
resize_policy/hash_load_check_resize_trigger_imp.hp
bin_search_tree_/constructors_destructor_fn_imps.hp
つまり、最後の 1 文字が切れています。
他にも同様のファイルがいくつかあり、調べてみると、
元々の tar ファイルの中で、「100 文字長のパスのファイルが
99 文字のパスにカットされてしまっている」ことがわかりました。
これは古い GNU tar (1.12 位) のバグのようで、
gcc のインストールガイドにも GNU tar 1.14 以上が必要、
と書かれています。
/usr/bin/tar でも使っていれば問題なかったのかもしれませんが、
普段 GNU ツールの方を優先パスにしていて、
tar あたりは大丈夫だろうと
しばらくバージョンアップしてなかったのが失敗でした。
- 大きいファイル
GNU tar の make check では、
2GB を越えるようなかなり大きいファイルを作成します。
そのようなファイルは、
GNU fileutils (3.13) の ls や rm では処理できませんでした。
これも /usr/bin/ls や /usr/bin/rm ならばちゃんと処理できるようです。
詳しくは man largefile に書いてあります。
いずれも、/usr/bin 等よりも、
GNU 系のツールを優先した PATH 設定にしているための問題でした
(別に Solaris のツールを信用してないわけではないのですが...)。
- (07/30 2007; 08/01 2007 一部追加)
(しおり用)
「Unix に関するメモ等 (10/10 2006)」,
「Unix に関するメモ等 (10/12 2006)」
で Solaris 9 上での gtk+-2.8, wxGTK のインストールについて紹介しましたが、
CVS 版の gnuplot で cairopdf
(cf. 「gnuplot に関する情報やメモ
(07/30 2007),
(07/23 2007)」)
がサポートされましたので、cairo-pdf が使える cairo (cairo-1.2 以降)
にバージョンアップしてみました。
ただし、gtk-demo がちゃんと動くようにするには、
多少パッチを当てる必要がありましたので、報告します。
まず、パッチを当てずにそのままインストールすると、
実行時に以下のようなメッセージが出ることがあります:
Error: Cairo does not yet support the requested image format:
Depth: 8
Alpha mask: 0x00000000
Red mask: 0x00000000
Blue mask: 0x00000000
Green mask: 0x00000000
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
assert に失敗しました: NOT_REACHED , (cairo-image-surface.c ファイルの 199 行目)
これは、以下でも報告されていて、そのパッチを当てれば解消されます。
既に、cairo-1.4.X 用のパッチも置いてあるようですが、
私は以下を利用しました。
ただ、それだけではうちは少し足りなくて、
以下のパッチも必要でした。
これは cairo-1.2.4-pseudocolor.diff を当てた後で当てます。
cd src
patch -p0 < ../../cairo-1.2.4-pseudocolor.diff
patch -p2 < ../../cairo124-add.diff
cd ..
これで、一応 gtk-demo もちゃんと動くようになり、
gnuplot の cairopdf terminal も一応動作するようにはなりました。
(cf.
「gnuplot に関する情報やメモ (07/30 2007))
- (07/23 2007)
(しおり用)
中越沖地震で、うちの研究室もそれなりに被害はでましたが、
幸いサーバは無事で、データも無事なようでした。
本日ようやく復旧しました
ところで、うちの
富士通 S-7/300U (Sun Ultra 1)
ですが、3 年半くらい前に画面がおかしくなって、
グラフィックカードを中古のカード (X3651A: 501-4127)
に交換してあったのですが、
また画面がおかしくなりました。
ふと、試しにボードの抜き差し (と軽く中身の掃除) だけやってみたのですが、
なんと復帰してくれました。
けど、もうあまり寿命は長くないのかもしれませんね。
ただ、多分国内ではもうこんなカードは入手が困難なんでは、と思います。
- (04/02 2007)
(しおり用)
うちの Solaris 9 (sparc) に netpbm-10.34
(http://netpbm.sourceforge.net/)
をインストールしましたが、
ちょっと手間取りましたのでここにまとめておきます。
必要だった修正は以下の通りです:
- converter/other/cameratopam/camera.c
(_XOPEN_SOURCE が定義されると、
/usr/include/sys/resource.h の ru_utime, ru_stime に関するエラーがでる)
- other/pamx/image.h (strings.h を読み込むとエラーがでる)
- other/pamx/window.c (X11/Xdefs.h は Solaris にはない)
上記のパッチを以下におきます。
基本的には上に書いたものを削除しているだけです。
また、現在の netpbm は、対話型の configure になっていますが、
そこでヘッダーファイルの所在などを指定した場合、
そこにインストールされる以前の netpbm 用
(例えば netpbm-10.31) のヘッダーファイルがインクルードされて、
名前が変更されているマクロが効かないためのエラーも出ました。
なお、実際にはうちでは上の他に、jasper のインストールディレクトリを
Makefile.config.in に設定し直してコンパイルしています。
- (03/28 2007)
(しおり用)
うちの Solaris 9 (sparc) に
Anthy (8700b) と scim (1.4.5), scim-anthy (1.2.2) をインストールしましたが、
scim のコンパイルで少し手間どりましたので、
ここにまとめておきます。
大半は、以下に上げられている情報の通りですが、
多少バージョンが違うようで、現象が少し異なります。
なお、うちは Solaris 9 + gcc-3.4.3 でコンパイルを行いました。
コンパイル時に起こる不具合は、以下の通りです。
- src/scim_chartraits.cpp のコンパイル時に
scim_chartraits.cpp:45: error: no member function `assign' declared
in `std::char_traits<scim::ucs4_t>'
scim_chartraits.cpp:45: error: invalid function declaration
....
等が出る。
- src/scim_socket.cpp のコンパイル時に「SUN_LEN() の定義がない」と出る
- libscim-1.0 の作成時に、gethostbyname 等の symbol が未定義、と出る
- src/scim_socket.cpp のコンパイル時に以下のようなものが出る:
scim_socket.cpp: In function `in_addr scim::__gethostname(const char*)':
scim_socket.cpp:77: error: cannot convert `hostent**' to `int*'
for argument `5'
to `hostent* gethostbyname_r(const char*, hostent*, char*, int, int*)'
scim_socket.cpp: In function `in_addr scim::__gethostname(const char*)':
scim_socket.cpp:77: error: invalid conversion from `hostent*' to `int'
なお、これらは一度に表われたのではなく、
一つずつ直しながら順番に表われたものです
(最後の scim_socket.cpp のエラーも 2 つに分かれて出たものを
まとめて書いています)。
これらは、それぞれ上記の WWW ページに従って、
以下のようにすることで解消しました。
とすることで解消できました。
src/scim_chartraits.cpp, src/scim_socket.cpp へのパッチ
(上の 1,2,4 番目のもの) を以下に置きます。
なお、上記はコンパイルエラーの解消しか確認してはおらず、
これで正常に動作するかどうかは確認していません。
- (03/19 2007)
(しおり用)
うちの Solaris 9 に Recommended patch を当てたのですが、
そうしたら一部のマシンのキーマップがおかしくなりました。
Type 5c, Type 7 の日本語キーボードは問題ないのですが、
Type 6 の日本語キーボードのキーマップがおかしいようです。
コンソールログインでは問題なさそうで、
X のキーマップだけ変でした。
原因は 112785-58 あたりかと思います。
調べてみると、113764 というパッチで修正ができそうだったので
(Recommended patch には含まれていない)、
113764-05 をダウンロードして patchadd で当てたところ、
今度はちゃんとうまくいきました。
113764-05 に関する情報は以下にあります。
- (01/23 2007)
(しおり用)
groff-1.18 + 日本語化パッチのコンパイルを
Solaris 9 + gcc-3.4.3 (+ bison-1.875)
でやってみたときにいくつか問題がありましたので、
ここにまとめておきます。
コンパイルに使用したファイルは、FreeBSD の ports
(japanese/groff) を参考にして、以下のものを取得しました。
FreeBSD の ports パッチも多少 Solaris 用に修正して当てて
(src/roff/nroff/nroff.sh, tmac/troffrc, src/libs/libgroff/encoding.cc,
src/xditview/Imakefile.in;
cf. groff1181-sol9.diff (3662 Byte))
コンパイルしたのですが、src/preproc/eqn/eqn.cc のコンパイルで
以下のようなエラーが起きます:
y.tab.c: In function `int yyparse()':
y.tab.c:XXXX: error: error: expected primary-expression
before "__attribute__"
y.tab.c:XXXX: error: expected `;' before "__attribute__"
この eqn.cc は、bison によって eqn.y から作られるのですが、
実際にはオリジナルの配布物にも含まれています。
それが日本語化パッチを当てることによって、eqn.y が更新されるために
bison で eqn.y から eqn.cc を作り直しているのですが、
元々の eqn.cc は問題なくコンパイルできて、
新しく作った eqn.cc の方は上の問題が起きていました。
色々調べてみたところ、bison-1.875 では問題が起こるが、
bison-2.X なら大丈夫、という情報があったので、
bison を 2.3 にバージョンアップしたところ、
ちゃんとコンパイルできるようになりました。
その他に、以下の点に注意する必要があります。
- configure 時に "--enable-multibyte" を指定する。
- make は make 'LIBS=-L/hoge/lib -R/hoge/lib -liconv' が必要 (かも)。
(/hoge は libiconv のあるディレクトリ)
- Solaris 2.9 では Imake のマクロにも未定義のものがあって
gxditview の make に失敗するので、
X11R6 などに含まれる ProgramTargetHelperNoMan の定義を
src/xditview/Imakefile.in に追加する必要がある
(cf. groff1181-sol9.diff
(3662 Byte))。
groff (+ 日本語化パッチ) のインストールは、
日本語のオンラインマニュアル形式のファイル (.man) を
HTML に変換したかったためなのですが、これで、
groff -man-old -Thtml hoge.man > hoge.html
で、FreeBSD の場合の "groff -man -Thtml" と同様の出力が
得られるようになりました。
- (12/27 2006)
(しおり用)
先日、表計算ソフトの出力をそのまま PDF にしたようなファイルから、
データを取り出す作業をやりましたので、その話をまとめておきます。
PDF からテキストデータを取り出すソフトはいくつかあるようですが、
ここでは xpdf-3.01pl2 をインストールして、
それに付属する pdftotext を利用しました。
インストールはあまり苦労なくできました。
pdftotext は、-enc 指定 (例えば -enc EUC-JP)
で日本語の情報も取り出すことができます。
今回は表計算形式のデータから情報を取り出しましたが、
その場合は、例えば
-raw オプション (データ順を保存して出力)、あるいは
-layout (データの物理レイアウトをできるだけ保存して出力)
オプションでそれなりにうまく抜き出せるのですが、
以下のような問題がありました。
- データセルの高さがかなり狭かったためか、
-layout オプションでは 1 行のデータが
複数行に分かれてしまうことがあった
(-raw オプションではそれは起こらなかった)
- 空白のデータセルがあちこちバラバラな箇所にかなり存在したため、
-raw オプションの出力では取り出したデータが
何フィールド目のデータなのかがわからないので
(罫線の情報や何番目のセルといった情報は取り出せず、
空白部分は詰められて出力される)、
-layout オプションを利用したが、
-layout オプションはそれなりに上下位置が合うが完全ではなく、
ずれも多少見られた
よって、-raw オプションの出力を参考にしながら、
-layout オプションの出力の分離してしまった行を結合させ、
上下位置の補正も必要に応じて行う、といった作業が必要になりました。
できるだけ手動の処理をしないように (多少はしましたが)
awk, sed, grep, csh script などを使って、
なんとか .CSV 形式のファイルに復帰することができました。
なお、pdftotext は -nopgbrk オプションで改ページ (\f)
を出力しないようにできるのですが、
今回のファイルの場合、スペースだけの列があると、
そのせいでページ毎に -layout の出力のレイアウトが変ってしまうので、
あえて -nopgbrk を使わずに \f を見て改ページを判断しながら
処理をする必要もありました。
- (12/24 2006)
(しおり用)
Solaris 9 (SPARC; Ultra1) 上に chasen-2.3.3 (と Text::ChaSen)
をインストールしたのですが、多少苦労しましたので、
ここに記録しておきます。
インストールしたソフト、環境は以下の通りです。
- OS: Solaris 9
- gcc-3.4.3
- perl-5.8.8
- libiconv-1.9.2
- chasen-2.3.3
- darts-0.2
- ipadic-2.7.0
gcc, libiconv, perl は既に入れてあるものを使いましたので、
今回は darts-0.2, chasen-2.3.3, ipadic-2.7.0 をインストールしました。
darts-0.2 のインストールは、configure 前に libstdc++.so があるところを
setenv LDFAGS "-L$hoge/lib -R$hoge/lib"
のように指定した程度で、簡単にインストールできました。
次は chasen-2.3.3 ですが、まずコンパイルでこけましたが、
これは有名な問題らしくあちこちに情報がありますが、
例えば以下のページに書いてあるような対処
(lib/dartsdic.cpp の修正) をすればコンパイルは通るようになります。
なお、darts-0.2 を使う場合は、後者の setArray() の修正は不要です。
しかし、Solaris (Sparc) の場合はコンパイルは通るのですが、
その後 make check すると segmentation fault が起こります (makeda が落ちる)。
これは残念ながら致命的らしく、
このままだとその後の ipadic のインストールも失敗します。
これは以下に情報がありますが、lib/dartsdic.cpp の std::cerr の文
をコメントアウト (3 つありますが、その 1 つ目と 3 つ目でいいようです)
してコンパイルすると make check も通るようになります。
ipadic のインストールは、
上の修正が行われた chasen がインストールされていれば無事に終わります。
なお、ipadic のインストールをした後でないと chasen は利用できません。
その後、chasen-2.3.3 の perl/ ディレクトリに移動して、
README に従って Makefile.PL を修正した後
(libchasen.so のある場所への -L, -R を追加)、
perl Makefile.PL, make, make install したのですが、
perl で Text::ChaSen を使うサンプルを書いてみたらうまく動作せず、
libchasen.so の undefined symbol のようなエラーが出ました。
色々調べたのですが、どうやら Makefile.PL の LIBS の -lchasen の後ろに
-lstdc++ を追加 (必要なら libstdc++.so のある場所への -L, -R も追加) して
もう一度インストールしたら、ちゃんと使えるようになりました。
なお、上記の「質問箱」の Wiki ページの先頭にも
同様の質問が上がっているのですが、
回答がうまく登録できなかったので (permission denied)
そのままにしておきました。
- (12/14 2006)
(しおり用)
「Unix に関するメモ等 (12/11 2006; no.2)」
に書いた Debian GNU/Linux 上の mgp に関連して、
TeX (LaTeX) で作成した数式
(をコンパイルして dvips を経由して作った EPS 画像)
の色を変えることはできないか、と質問されました。
これについて私が考えた答えは、次の 3 つです。
- LaTeX の方で color パッケージを利用して、
カラーの DVI ファイルを生成するようにしておく
- できた EPS ファイルを、
Netpbm 等を使って XPM 形式に変換して、
その上で色を sed 等で変換する
例:
pstopnm -stdout -xsize 400 -portrait file.eps | ppmtoxpm \
| sed -e 's/black/#ff0000/' -e 's/white/gray/' \
| xpmtoppm | ppmtogif > file.gif
- できた EPS ファイルを、
Netpbm 等を使って PPM 形式に変換して、
その上で ppmchange (Netpbm 上のツール) を利用して色を変換する
例:
pstopnm -stdout -xsize 400 -portrait file.eps \
| ppmchange black '#ff0000' whilte gray file.ppm \
| ppmtogif > file.gif
以上の例で、文字 (数式) が赤で、背景が灰色の画像ができることになります。
- (12/11 2006; no.2)
(しおり用)
Debian GNU/Linux を使っている人から、
mgp (Magicpoint) で EPS 画像がでない、
と聞かれました。
探してみると、debian-users ML に以下のような情報がありました。
これと同じで、Netpbm が入ってないのが原因だったようです。
ただ、Netpbm が入ってなくても、mgp の -X オプションで
"mgp -X ppm" とすることでも出るようでした。
(cf. 「Unix に関するメモ等 (12/14 2006)」)
- (12/11 2006)
(しおり用)
以前、emacs で画面幅より長い行がある場合、その画面上でカーソルを
上下移動するにはどうしたらいいか、と聞かれました。
emacs のカーソルの上下移動は、画面の表示とは関係なく、
次の論理的な行の同じ位置への移動なので、
確かに画面幅より長い行がある場合の上下移動が画面とは異なってしまいます。
例えば極端な話、画面幅が 80 桁で、一行に 780 文字含まれる論理行があった場合、
その行だけで画面の 10 行を取ってしまうわけですが、
その画面 10 行の最初の行の先頭から 5 番目の位置にカーソルがいる場合、
カーソルを下に動かすと、それは画面のその下の位置、
すなわち同じ論理行の 85 番目の位置に移動するのではなく、
次の論理行の先頭から 5 番目の位置、
すなわち画面上の 10 行下にジャンプすることになります。
emacs の空白部分も含めて画面の上下移動を自由に行なうモードとして
picture モードがありますが (M-x picture-mode)、
これだと、画面行よりも長い行は画面から消えてしまうようです
(画面の右端に '$' がついて、右に継続していることが示される)。
しかし、ふと何かで見つけましたが、
小松さん作の physical-line-mode を使うと、
画面上での物理的なカーソルの移動が可能なようです
(私はまだ試していません)。詳しくは以下をご覧ください。
- (10/24 2006)
(しおり用)
w3m を使っているときに、その中の文字列を copy & paste したいんだけど、
と聞かれましたが、
これは最近の w3m ではマウス機能を持っていて、
それが有効になっていて、マウスアクションを特別視しているためです。
'm' によってマウス機能は有効と無効を切り替えられますから
(トグルスイッチ)、
それで無効にすれば通常の X でのマウス操作、
例えば copy & paste などが可能になります。
- (10/22 2006)
(しおり用)
Solaris 9 に gtk+-2.8 を入れたので
(cf. 「Unix に関するメモ等 (10/10 2006)」,
「Unix に関するメモ等 (10/12 2006)」)、
ついでに以前一度インストールしようとしてうまくいかなかった
inkscape をインストールしてみることにしました。
inkscape は SVG 形式の画像が出力できる画像エディタです。
詳しくは以下をご覧ください。
Inkscape のコンパイルには、gtk+-2.X の他、 glibmm, gtkmm,
libxml2, libxslt, libsigc++, Boehm-GC などが必要です。
inkscape-0.41 はあまりうまくいきませんでしたので、
今回は最新版の inkscape-0.44.1 を使用しました。
inkscape は C++ で書かれているのですが、
新しい C99 に沿って書かれているようで、
Solaris 9 には標準的には用意されていない関数がいくつかあるために
何箇所かコンパイルに失敗します。
そのためか、以下のようなコンパイルに関する
Wiki ページがあることに気がつきました
(インストールが終わってから (;_;))。
このページにも書かれていますが (もっと早くこのページに気づいていれば ...)、
Solaris 9 ではコンパイル時に以下のような問題が起こります。
- std::isfinite() がない
- round() がない
- log2() がない
- Boehm-GC の 6.6 以前だと GC_noop() がどうとか言われる
- make check でも INFINITY がない等がでる
よって、それぞれほぼ上のページに書かれているような対処を取って
コンパイルを通しました。
- std::isfinite() は src/isnan.h のコメントに従って
isnan() (これは include/math.h に書かれているんであるらしい)
を使って代用
- round(), log2() は自作
(けど上のページによれば round() は rint() で置きかえればいいらしい)
- Boehm-GC の 6.8 をインストール
- make check はあきらめる (^^;
まだちゃんとテストはしていませんが、
とりあえずはコンパイルできて、立ち上がるようにはなっています。
FreeBSD 4.X でも同様に C99 の問題で
inkscape のコンパイルに失敗するようですが、
FreeBSD 5.X 以降だとそれらの対処がとられていて
ちゃんとうまくいくようです。
- (10/12 2006)
(しおり用)
「Unix に関するメモ等 (10/10 2006)」
に書いた、Solaris 9 への gtk+-2.8.20 のインストールですが、
そこではシステムにインストールされる /usr/sfw/lib や /usr/lib にある
freetype や fontconfig などを使わないようなインストールを紹介しましたが、
それらを使うようにしても一応うまくいくようです
(wxGTK までは確認しておらず、gtk-demo の動作を確認しています)。
この場合、新たにインストールするのは以下のものだけで済みます。
- render-0.8.tar.gz, xrender-0.8.3.tar.gz
- cairo-1.0.4.tar.gz
- glib-2.8.6.tar.bz2
- pango-1.10.4.tar.bz2
- atk-1.10.3.tar.gz
- gtk+-2.8.20.tar.gz
この場合の注意を以下に書きます。
- /usr/sfw/bin にパスを通し、
逆に後でインストールした freetype-config などが置かれているところに
パスを通さないようにする必要があります。
- CPPFLAGS, LDFLAGS, PKG_CONFIG_PATH は、
setenv CPPFLAGS "-I$prefix/include -I/usr/sfw/include
-I/usr/openwin/include"
setenv LDFLAGS "-L$prefix/lib -L/usr/sfw/lib -L/usr/openwin/lib
-R$prefix/lib:/usr/sfw/lib:/usr/openwin/lib"
setenv PKG_CONFIG_PATH
"$prefix/lib/pkgconfig:/usr/lib/pkgconfig:/usr/sfw/lib/pkgconfig"
のようにしました (正確には LDFLAGS は、libiconv.so, libgcc_s.so
などがあるディレクトリへも設定しています)。
- libXrender も /usr/sfw にインストールされていますが、
cairo-1.0.4 が使用するマクロ (PictStandardA{1,8} 等) が定義されていなくて
エラーがでますので、
render-0.8.tar.gz, xrender-0.8.3.tar.gz を入れる必要はあります。
- しかし、pango が参照する /usr/openwin/lib/Xft.so が内部で
/usr/sfw/lib/libXrender.so を引いているので、
/usr/sfw/lib/libXrender.so を使うものと
$prefix/lib/libXrender.so が混在することになりますが、
とりあえず gtk-demo では問題はないようです。
pango のコンパイル時には、
/usr/openwin/include/X11/extensions/Xrender.h
を見ないように
make "DEFS=-DHAVE_CONFIG_H -I$prefix/include"
のようにする必要があります。
- 前回の cairo-1.0.4 へのパッチは必要。
これだと、fontconfig などは元々システムにあるものが使われますし、
インストールしなければいけないものも少なくて済みますので、
こちらの方がいいかもしれません。
(cf. 「Unix に関するメモ等 (10/22 2006)」,
「Unix に関するメモ等 (07/30 2006)」)
- (10/10 2006)
(しおり用)
Solaris 9 のマシンで、最新開発版の gnuplot (4.2rc1) の wxt terminal
を動かすために wxWidget をインストールしたのですが、
そのために gtk+-2.X もインストールする必要があり、
それらがちゃんと動くまでかなり苦労しましたので、
ここに書きとめておきます。
まず、gnuplot-4.2rc1 が必要とするのは、
cairo-0.9.0, pango-1.10.2, wxWidget-2.5.3
あたりのようですが、Solaris 9 についている gtk+ は 1.2.10 位のようなので、
gtk+-2.8 辺りをインストールすることにしました。
しかし、最初は /usr/sfw/lib や /usr/lib にあるライブラリ
(freetype, Xrender, fontconfig 等) を使ってインストールをしてみたのですが、
うまくいかなかったので、
その辺りも別なディレクトリにインストールして、
それらを使うようにしてみました。
インストールしたのは以下のものです
(ほぼインストール順ですが、あまりに大量でうんざりですね (^^))。
なおうちは、
- OS: Solaris 9 (SunOS 5.9 Generic_118558-02 sun4u sparc)
- Compiler: gcc (GCC) 3.4.3
- make: GNU Make version 3.79.1
を使っています。
大概は "configure --prefix=$hoge1 ; make ; make install"
なんですが、色々注意が必要です。
まず、全般的には以下のような注意が必要です。
- ヘッダファイルやライブラリの置き場所を、
適宜 configure 前に CPPFLAGS や LDFLAGS で
setenv CPPFLAGS "-I$hoge1/include -I$hoge2/include"
setenv LDFLAGS "-L$hoge1/lib -L$hoge2/lib
-R$hoge1/lib:$hoge2/lib"
(うちは tcsh なんで setenv)
のように設定する必要がある。
- pkg-config もインストールして、/usr/sfw/pkgconfig や
/usr/lib/pkgconfig を見ないようにするために PKG_CONFIG_PATH を
setenv PKG_CONFIG_PATH $hoge1/lib/pkgconfig:$hoge2/lib/pkgconfig
のように設定する必要がある。
- 実行ファイルも /usr/bin よりも今回インストールした
実行ファイルを優先して見るようにする必要があるので
set path = ( $hoge1/bin $path )
のようにする必要がある。
よって各々の configure は、
それらの設定をしてから configure するようなシェルスクリプトを作って
それを使いました。
個々のインストールでも色々注意が必要でしたので、
それらを順に上げていきます。
- expat:
make install する前に make check しようとしたら、
ヘッダが見つからなかったので
make 'CXXFLAGS=-I./lib' check
のようにする必要がありました。
- fontconfig:
最初は新しい fontconfig-2.4.1 をインストールして、
Solaris の元々の fontconfig の設定ファイル /etc/fonts/fonts.conf
を参考に設定をしたのですが、
fc-cache がいつになっても終わりませんでした (何日もかけたのですが)。
しかも、日本語フォントに対する fc-list の出力が化けていたので、
結局 fontconfig-2.2.3 に cjk パッチを合ててコンパイルしました。
cjk パッチのパッチ合ては 2 つほど失敗しますが、
いずれも 2.2.3 では意味がないものなので無視してやりました。
ところで、その前に freetype-2.2.1 をインストールしていたのですが、
freetype-2.2.1 では freetype/internal/ のヘッダファイルを
インストールしなくなったようで (2.1.9 はインストールしてくれます)、
fontconfig のコンパイル時に freetype-2.2.1 のソースも展開しておいて
make "DEFS=-DHAVE_CONFIG_H -DFT2_BUILD_LIBRARY
-I`pwd`/../freetype-2.2.1/include"
のようにしてコンパイルする必要がありました。
この版の fontconfig なら、/etc/fonts/ の設定ファイルを
そのまま $hoge1/etc/fonts/ にコピーして使用しても問題ないようでしたし、
fc-cache もちゃんとすぐに終わってくれました。
- cairo:
cairo-1.0.4 は、まず configure スクリプトと src/cairo-xlib-xrender.h
の
#include <X11/extensions/Xrender.h>
の前に
#include <X11/Xlib.h>
がないと configure, compile がうまくできません
(cairo-1.2.4 では configure の方のみ改善されています)。
また、gtk のインストールまでやった後で gtk-demo がうまく動かず、
調べてみるとどうも cairo で落ちてしまうようで、
新しい cairo-1.2.4 に変えてみたのですがそれでも改善しませんでした。
これに関しては以下で情報を見つけました。
タイトル通り、depth の浅いマシン (PseudoColor) では問題があるようで、
そこにあるパッチを当てれば解消される、とあったのですが、
上に紹介した patch-src_cairo-xlib-surface_c では少し足りなくて、
以下のパッチも必要でした。
これは patch-src_cairo-xlib-surface_c を当てた後で当てます。
cd src
patch -p0 < ../../patch-src_cairo-xlib-surface_c
patch -p2 < ../../cairo104-add.diff
cd ..
上記のサイトには cairo-1.2.4 用のパッチもありますが、
それもそれだけでは足りず、多分同様の対処が必要だろうと思います。
なお、これらのパッチを当てる前の make check では
"9 of 61 tests failed" で、パッチを当てた後はむしろ
"16 of 61 tests failed" と一見悪くなってしまったのですが、
とりあえず gtk-demo はちゃんと動くようになりました。
最初の configure 等へのパッチも入れると、cairo-1.0.4 では都合
3 つのパッチが必要になります。
- glib:
うちは GNU iconv がインストールされているので、
configure 時に --with-libiconv=gnu が必要で、
これがないと make がストップしてしまいます。
- atk, gtk+:
これらは
set path = ( $hoge1/bin $path )
($hoge1 は glib-2.8.6 のインストール先)
してないと、/usr/bin/glib-genmarshal が呼び出されてしまって
configure, make (make の方だったかな ?) に失敗します。
- wxGTK:
ドキュメント通り、build_gtk というディレクトリをソースツリー内に作って
そこで configure ; make しました。configure オプションは
"--prefix=$hoge1 --enabe-unicode --with-gtk=2"
としました。
以上で gtk-demo がちゃんと動くものが得られました。
多国語表示 (Text Widget ->Multiple Views) もちゃんとできます。
fontconfig を使用していない FreeBSD から remote login した
kterm 上でも、ちゃんと表示できました。
この環境の元で gnuplot-4.2rc1 をコンパイルしたら、
見事に wxt terminal が動作しました。
日本語もデフォルトで (フォント等を特に何も設定せずに) 表示されます。
(cf. 「Unix に関するメモ等 (10/12 2006)」,
「Unix に関するメモ等 (10/22 2006)」,
「Unix に関するメモ等 (07/30 2006)」)
「gnuplot に関する情報やメモ (01/22 2013)」)
- (09/04 2006; no.2)
(しおり用)
奥村＠三重大 さんの
TeX Q & A
からの情報ですが、44679 番の記事で xargs の挙動が OS によって違う、
とありましたので少し調べてみました。すると確かに、
cat /dev/null | xargs echo 'a'
のように、標準入力がない場合の挙動が違っているようで、
- FreeBSD 4.X, 5.X の /usr/bin/xargs : 何も実行しない
- Solaris (9) の /usr/bin/xargs : コマンド (上の場合 echo 'a') を
1 回実行する
- GNU findutils の xargs (多分 Linux の xargs もこれ) : コマンドを
1 回実行する
となるようです。
FreeBSD の xargs に挙動を合わせるには、Solaris の xargs では
-l や -L 1 を付ければいいようですが
(この場合標準入力があれば 1 行ずつ実行することになるので、
正確には同じ挙動とは言えませんが、
少なくとも標準入力がなければ実行しなくなるようです)、
GNU の xargs ではこれはうまくいかず、
逆に GNU の xargs には入力がない場合に実行しない専用のオプション -r
があるのですが、これは Solaris や FreeBSD の xargs にはありません。
よって、色んな OS 上で動作することを考えて、
標準入力がない場合も想定して挙動を合わせようと思うと、
xargs に直接データを流す前に
(ファイルに落すなりして)
そのデータが 0 行であるかどうかをチェックして、
0 行以外ならば xargs に流す
ということをしないといけないようです。
xargs は、find と組み合わせてその出力を pipe 経由で xargs に渡す、
というのがよく使われるやり方だと思いますが、
ポータビリティを考えた場合はなかなかそうもいかないようです。
- (09/04 2006)
(しおり用)
emacs で普通に既存のファイル (例えば file) を編集するときは、
バックアップファイルである file~ というものが作られますが、これは、
cp -p file file~
のようにして (と実質的に同等な方法で) 作られるのかと思ったら
どうもそうではなく、デフォルトでは
mv file file~
cp file~ file
のようにして (と実質同等な方法で) 作られるようで、
元のファイルと inode が代わってしまいます。
よって、ハードリンクされたファイルを emacs で編集すると、
他のハードリンクファイルは変更されないまま、という状況になってしまいます。
これを回避するには、~/.emacs に
(setq backup-by-copying t) ;; ==> mv ではなく常に cp する
(setq backup-by-copying-when-linked t)
;; ==> hard link があるときだけ cp
のいずれかを入れるといいようです (とマニュアルに書いてありました)。
- (08/19 2006; no.4)
(しおり用)
私は HTML ファイルを見るときは w3m を使うこともあるのですが、
w3m は拡張子が .html ではない HTML ファイルを読んだときや、
リダイレクションなど標準入力から HTML ファイルを読んだときなどは
HTML だと思った表示はせずに、
単なるページャとしてその HTML ソースを表示してしまいます。
そのような場合は、w3m に
w3m -T text/html < hoge.html
のように -T オプションを使って HTML であることを教えてやればいいのですが、
"text/html" の部分を覚えにくくて面倒だなと思っていました
(よく、"html/text" とか "plain/html" などと間違えます)。
それが、先日ふと気がついたのですが、今の w3m (少なくとも w3m 0.5.1) では
ページャとして立ち上がって HTML のソースを表示している状態で
'v' を打てば HTML と解釈した表示 (WWW ブラウザとしての表示) を
してくれるようです。
'v' は、元々は WWW ブラウザとしての表示から
ソースの表示に切りかえるトグルスイッチなのですが (多分)、
逆にこのようなこともできるようになっているんですね。
こちらの方が -T オプションよりもずっと楽です。
ちなみに、HTML ファイルでないファイルを
w3m でページャとして見ているときに 'v' とした場合も、
それを無理矢理 HTML だと解釈して表示しようとするので
妙な表示になってしまうようです。
- (08/19 2006; no.3)
(しおり用)
LaTeX の dvi ファイルを PDF に変換する dvipdfmx というソフトは、
hyperref パッケージ (\usepackage[dvipdm]{hyperref}) を使って
section 部分をしおりに出きるようなのですが、
その場合 LaTeX ファイルのプリアンブルに、
\AtBeginDvi{\special{pdf:tounicode EUC-UCS2}} % (EUC 環境の場合)
\AtBeginDvi{\special{pdf:tounicode 90ms-RKSJ-UCS2}} % (Shift_JIS 環境の場合)
のような行を入れる必要があります。
dvipdfmx-20050201 版ではこれでできましたが、
Acrobat Reader の 4.X や 5.X ではしおり部分の日本語は表示されず、
Acrobat Reader 7.0.8 でやっと確認できました
(Acrobat Reader 7.X は Java ベースで動作がやや重いので、
普段は Acrobat Reader 4.X などを今だに使っています)。
- (08/19 2006; no.2)
(しおり用)
Acrobat Reader の 7.0.8 の Solaris (8) 用の日本語版が出たので
先日うちの Solaris 9 にインストールしました。
コマンド名は acroread で、これ自体はスクリプトのようなのですが、
日本語環境を自動判別して、
日本語メニュー等のエンコーディングを決めているようです。
うちは Solaris 9 なので、普段は LANG=ja (=ja_JP.eucJP) を使っているのですが、
しかしその自動判別がうまくいかず、
UTF-8 モードで立ち上がろうとしているのか
メニュー等が文字化けしてしまいました。
そこで (うちは tcsh)、
setenv LANG C ; acroread
としてみるとうまく文字化けせずに立ち上がるので、
そういうラッパースクリプトを作ろうかと思ったのですが、
acroread は WWW ブラウザのプラグインとしても使われていて、
acroread スクリプトにさらにラッパースクリプトをかませると
今度はプラグインの方がうまく動作しないようでした。
ということで、あまりやりたくなかったのですが、
acroread スクリプト自体を編集して、
LANG=C; export LANG
なる行を "MYLANG=..." の前に追加して対処しました。
- (08/19 2006)
(しおり用)
ふと、日本語の文書を縦書きで表示するエディタやターミナルはないかなと
探して、mlterm と vtp22 を見つけました。
mlterm は、kterm 同様日本語が表示できるターミナル (正確には、
Multi Lingual Terminal) ですが、
mlterm -G cjk
のようにして起動すると、縦書き表示になります。
この場合の「縦書き」とは、フォントの方法は通常の横書きと同じ向きで、
縦方向に文字を書いていき、次の行は左に並ぶ、ということを意味しています
(下図参照)。
- mlterm の縦表示サンプル
この上で less を使えば、一応文書が縦書きで表示されますし、
この上なら emacs -nw で、縦書きワープロの気分も味わえます。
ただし、表示はそんなに安定しておらず、
特に半角文字と全角文字が同じ高さで表示されるので、
そのためにやや表示が崩れることがあります。
また、付属のドキュメント README.tate に書かれている
縦用のフォントの置き場所は、現在はアクセスできなくなっています。
sourceforge の方にもそのようなフォントは置いてありません。
一方、vtp は日本語文書を縦表示するだけのページャですが、
こちらは表示はかなり安定しています。
- vtp の縦表示サンプル
このサンプルは、
この WWW ページを w3m -dump でテキストファイル化したものの先頭部分です。
これも mlterm と同じ意味の縦書き表示になります。
なお、かっこや句読点などが縦書き用になっていないので
ちゃんとは表示されていませんが、
vtp には X のフォントを縦書き用のフォントに変換する
awk スクリプトが付属されていて、
それを使って vtp 用の X のフォントを使うようにした kterm 上で vtp を使えば
それは改善するそうです (まだやってません)。
ただし、文書サイズが大きいとき (?) なのか、
うまく全部を表示してくれないときがあるようです
(上のサンプルでも全部で 3 ページしか表示されませんでした) し、
かなり古いソフトなので、
環境によってはコンパイルも少し手直しが必要な場合があるようです。
Solaris 9 (+gcc-3.4.3) の場合、
vtp_sjis.c の "exit()" をすべて "exit(1)" に直して、
さらに gcc のオプションに "-DBSD_COMP" (for sys/ioctl.h)
を追加することでコンパイルできました。
- (07/28 2006)
(しおり用)
バイナリインストールした Solaris 9 上の Firefox-1.5.0.4 ですが
(cf. 「Unix に関するメモ等 (07/16 2006; no.2)」)、
日本語の WWW ページを印刷しようとすると、
日本語が表示されず豆腐 (□) になってしまうことがわかりました。
うちの Ghostscript 7.07 (CJK 化されています) で表示させてもそうなりますし、
PS プリンタに出力しても同じです。
色々対処法を探してみて、作成される PostScript ファイルをいじってみたところ、
その Unicode 出力されている PostScript ファイルの
フォント指定等があまりよくないようで、
とりあえず以下のようにすることで、
印刷できる PostScript ファイルに変換できることがわかりました。
- Firefox で直接印刷せず、ファイルに保存する (例えば file.ps とする)
- file.ps の /ja_ls の定義中の、
/UCS2Font が /Courier と設定されているところを
/Ryumin-Light-UniJIS-UCS2-H と変更し、
以下、default_ls が行頭に使われているところを ja_ls に変える
- それを ps2ps でラスタライズする
UniJIS-UCS2-H は、unicode エンコードだと思いますが、
その CMAP ファイルがインストールされている必要があります。
ps2ps によるラスタライズは、gs (gv) では書き変えだけで見れたのに、
PS プリンタでは印刷できなかったために行っています。
実際には、上の作業を行うシェルスクリプトを書いてそれを使うことにしました。
以下に置いておきます。必要ならば適当に書きかえて、
自己責任で使用してください。
本当は何らかの設定で対処できるのかもしれませんが、
とりあえず今のところそのような設定の仕方は見つかっていません。
- (07/27 2006)
(しおり用)
ftwalk なる awk の拡張があるようです。
おもしろそうなのでインストールしようと思ったのですが、
C++ で書かれていて、しかも少し古い (2000 年位で開発が止まっています)
ためか gcc-3.4.3 ではうまくコンパイルできませんでした。
ftwalk の仕様に関する文書もあまりないようだったので、
あきらめることにしました。
- (07/16 2006; no.3)
(しおり用)
奥村＠三重大 さんの
TeX Q & A
からの情報 (2 年半位前の情報) ですが、
DVI ファイルの連結には dvimerge, dvicat, dviconcat なるソフトがあり、
PostScript (PS) ファイルの連結には psmerge, pscat, psconcat なるものが
あるそうです (24355 番の記事)。
他に psjoin なる perl スクリプトも見つけました
(cf. 「Unix に関するメモ等 (04/18 2006)」)。
ただ、特に PS の連結は上記のものではあまりうまくいかないこともあるようですが、
gs を使った解法もあるようで (24358 番の記事)、
これを今回思いだしたので、csh スクリプト化してインストールしました。
- (07/16 2006; no.2)
(しおり用)
Firefox-1.5.0.4 を Solaris 2.9 (sparc) にインストールしました。
コンパイルしたのではなく、
にあるように Solaris 8 用のコンパイル済みバイナリをダウンロードして、
展開してそれを適当に移動して、その中にある firefox へのシンボリックリンクを
パスの通ったディレクトリに貼っただけです。
なお、その後上記のページに従って (各ユーザ毎に) 日本語化も行ったのですが、
"Locale Switcher Extension" (switch-locale-1.5.1.xpi) の方は
うまくダウンロード & インストールできたのですが、
もう一つの ja.xpi の方は Firefox 上でうまくダウンロードできませんでした。
よって、上記のページのリンク先
- http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5.0.4/win32/xpi/ja.xpi
を直接指定して、なんとかダウンロード & インストールすることができました。
Blade 150 上ではそれなりの速度で動きますし、それなりに快適そうです。
(cf. 「Unix に関するメモ等 (07/28 2006)」)
- (07/16 2006)
(しおり用)
Python-2.4.3 を Solaris 2.9 (sparc) にインストールしました。
ただ、Solairs の curses ライブラリに問題があるらしく、
なにやら
symbol mvwgetnstr: referenced symbol not found
のようなエラーがでるのですが、これは、
にあるように、Modules/_cursesmodule.c の mvwgetnstr() をすべて
mvwgetnwstr() に変えたらエラーなくコンパイルできました
(動作がうまく行っているのかどうかまでは確認していません)。
- (06/15 2006)
(しおり用)
最近の GNU awk (3.X) は、LANG でその挙動が変わります。
ただ、内部でどのような処理をしているのかわかりませんが、
それが不具合を招く場合があるようです。
Solaris 9 上の GNU awk 3.1.5 で、setenv LANG ja の場合、
echo "/* M0+* を */" | awk '{print match($0,/\*\//)}'
を実行すると (kterm 上; 日本語環境は EUC-JP)、
: (FILENAME=- FNR=1) fatal error: internal error
となります。setenv LANG C だと問題ありません。
- (05/12 2006)
(しおり用)
httpd はうちでは apache (httpd-2.X) を使っていますが、
今まではその更新作業は、
- httpd は動かしたまま、
新しい httpd を、
一般ユーザの権限で一般ユーザのホームディレクトリ上で
configure & make する
- 現在の httpd を止めて (apachectl stop)
- httpd をインストールしたディレクトリ ($prefix) の名前を変える
- root の権限で新しくコンパイルした httpd を make install ($prefix に)
のような手順で行っていました。
これまではこれで特に問題はなかったのですが、
最新版の httpd-2.2.2 ではこれで問題が起きました。
問題が起きたのは、最後のインストールの時で、
make install しようとすると
$prefix/include/ のヘッダファイルがない、
というエラーがでます。
どうも、configure で $prefix/include があるとそれを見ていて、
make のときにそれらがないとうまくいかないようです。
つまり、上のような手順だと、
- 一般ユーザでの make 時は $prefix/include があるのでコンパイルはできる
- root になってインストールする前に $prefix を移動するので、
そのときは $prefix/include がなく、
それがないと make install も失敗する
のようなことになってしまってインストールができません。
となると、
- make install のときに $prefix を動かさない (上書きインストール)
- configure & make の前に $prefix を動かしておく
のどちらかの形式にする必要があります。
今回は後者を選択してとりあえずそれでうまくいきましたが、
これだと、configure & make
の間は現在の httpd を止めないといけません。
httpd を止めるのは最小限にしたいのですが、
このような状況だとそうもいきません。
なんらかの解決策はないか、
またなぜこのように変わってしまったのか、
少し調べてみたいと思います。
- (04/18 2006)
(しおり用)
最近、手書きの文書をいくつかスキャナで画像化して
PDF 化していくつかの WWW ページに載せました。
画像化は、sane の scanimage コマンドで行えますが
(pnm, or tiff)、
そこから PDF 化するには、例えば次のような 2 通りが考えられます。
- その画像を tiff 形式に変換して tiff2pdf で PDF 化
- その画像を ps 形式に変換 (pnmtops) して ps2pdf で PDF 化
tiff 形式にするのは、scanimage のオプションで tiff にする、
あるいは Netpbm の pnmtotiff でできます。
複数の画像を一つずつ 1 ページとして、それをまとめて PDF 化する、
という場合は、以下のような方法が使えます。
- その画像を tiff 形式に変換して tiffcp で一つにして
tiff2pdf で PDF 化
- その画像を ps 形式に変換 (pnmtops) して
psjoin (Tom Sato さん作の perl script) で一つにして
ps2pdf で PDF 化
しかし、できた PDF ファイルを見ると、
いずれも ps 経由の方は tiff 経由のものに比べて少し汚なく見えます。
以下にサンプルを上げます。
なお、これらはそれぞれ以下のようにして生成しています
(原画像は 120dpi で A4 の紙を scan した PGM 画像)。
- tiff 経由:
pnmtotiff test1.pgm > test1.tiff
tiff2pdf -x120 -y120 -z -pA4 test1.tiff > test1-tiff.pdf
- ps 経由:
pnmtops test1.pgm > test1.ps
ps2pdf test1.ps
mv test1.pdf test1-ps.pdf
ps レベルではさほど汚なくは見えないようなので、
ps2pdf (Ghostscript) の処理に問題があるような気がします。
よって、現在は tiff 経由で変換を行っています。
なお、私が使用している Ghostscript は 7.07 ですから、
現在の 8.X ではその辺りは改善されているのかもしれません。
(cf. 「Unix に関するメモ等 (07/16 2006; no.3)」)
- (04/03 2006)
(しおり用)
「Unix に関するメモ等 (04/01 2006; no.3)」
に書いた、emacs-20.7 (と emcws-20.7) の gcc 3.4.X でのコンパイルの問題ですが、
emacs-21.4 (21.4a) の emcws 版をコンパイルしたときも同じ問題がでました。
インターネット上のブログには、21.4 の場合は問題なかった、
といった情報もあったようなのでだいじょうぶかと思ったのですが、
やはり gcc-2.95.3 でコンパイルしないとだめでした。
- (04/01 2006; no.3)
(しおり用)
Solaris だけに依存しない話かもしれませんが、
最近 Solaris 9 上で emacs-20.7 (と emcws-20.7)
を再インストールしたときのことですが
(「Unix に関するメモ等 (04/01 2006; no.2)」
に書いた Canna のバージョンアップに伴う再コンパイル)、
以前コンパイルしたときは問題なかったのですが、
今回コンパイルしたら、
終了時に core dump するバイナリができてしまいました。
今は皆さん emacs-21.X なのかあまり情報がありませんでしたが、
どうやら gcc-3.4.X でコンパイルするとそのようになるらしいです。
まだかろうじて残してあった gcc-2.95.3 でコンパイルしたら、
そのような問題の起こらないバイナリがコンパイルできました。
(cf. 「Unix に関するメモ等 (04/03 2006)」)
- (04/01 2006; no.2)
(しおり用)
最近 Solaris 9 上で Canna をバージョンアップ
(35b2 ==> 37p3) したときのことですが、
libcanna, libcann16 がうまくコンパイルできませんでした。
環境は以下の通りです。
- OS: Solaris 9 (32 bit; Sparc)
- CC: gcc-3.4.3
エラーのログを見ると、
gcc が吐いているアセンブラコードに問題があるようでしたが、
Canna37p3 の canna/ccompat.h に書かれているアセンブラコードを吐く部分
(79 行目辺りから始まる部分) を使わないようにするといけるようです。
Solaris 上の gcc では __sun__ が定義されていますので、
79 行目の
#ifdef __GNUC__
を
#if defined(__GNUC__) && !defined(__sun__)
と変えることでうまくいきました。差分を以下に置きます。
多分 GNU as (GNU アセンブラ) を仮定して書いているのだと思いますが、
Solaris 上の GCC では通常 GNU as ではなく、
/usr/ccs/bin/as を使うので、
Solaris でコンパイルするときは必要な対処かもしれません。
なお、上記のパッチにはもうひとつ Solaris でコンパイルするときには
ほぼ必須のような "-R" オプションの追加 (Canna.conf) も
書いてあります。
(cf. 「Unix に関するメモ等 (04/01 2006; no.3)」)
- (04/01 2006)
(しおり用)
ここに、Unix に関するメモなどを書いていくことにしました。
以前、学内限定でフリーソフトのインストールメモを書いていたのですが、
更新が面倒なことと、
色々あちこちのサイトから情報を得て助けられていましたので、
こちらからもそういった情報を提供できれば思い、
このような形にしました。
「Unix に関する QandA」
のページも以前は学内限定だったのですが、現在は外部にも公開しています。
私は普段は MS-Windows や Mac などはほとんど使用しておらず
(それぞれ 1 台ずつあることはあるのですが)、
Unix マシンを常に使用していて、
そのための情報をコンピュータ上にメモとして残しています。
コンピュータ上にテキストファイルとして残せば、
grep などで簡単に検索できますし、
メールやチャット (okphone を使っています) 等で
学生に情報を渡すときも容易にコピー & ペーストで行えて、
便利なのでそうしています。
そうやって残しているようなデータもかなりたまっていますので、
そういった話のうち、公開できるものを
ここに書き残して公開していこうかと思っています。
うちの研究室には Unix OS は、
FreeBSD, Solaris, HP-UX, EWS-UX (NEC), IRIX などがありますが、
普段使用しているのはほぼ Solaris と FreeBSD で、
FreeBSD 特有の情報は
FreeBSD のページ
に書いていきますので、このページには、
- Solaris に関する情報
- 特定の OS には依存しないソフトウェアに関する情報
などを載せていく予定です。
- (03/28 2006)
(しおり用)
うちには Sun のマシンが何台かあるので、
そのうちの一つのマシンをプリントサーバにして、
その他のマシンからはプリントサーバに lp の要求をとばしています。
しかし、Solaris 2.6 から Solaris 9 にバージョンアップしたら、
クライアントでプリント要求を cancel したときに
プリントサーバから送られていたメールが来なくなりました。
lpstat の出力を見ると、
0.0.0.0 というマシンからのプリント要求であるようになっていて、
プリントサーバは user@0.0.0.0 にメールを送ろうとして
失敗していることがわかりました。
色々と設定を試したところ、
プリントサーバの inetd.conf の socket_type を
tcp6 (デフォルト) から tcp に書き変えてしまうとそうなってしまうようです。
tcp6 に戻すと要求元のホストが正しく認識されました。
しかし、うちは inetd は tcp_wrappers をかませてあって
(inetd に元々リンクされてあるものではないもの)、
それでアクセス制限を行っているのですが、
inetd.conf の socket_type を tcp6 にするとそれが効かなくなります。
tcp_wrappers を IPv6 に対応させるパッチも 2 種類位見つけましたが、
いずれもうまく動作してくれませんでした
(設定の仕方が悪いだけかもしれませんが、
一つの方はコアダンプします)。
よって、0.0.0.0 の方は、
プリントサーバからのメールは送られないものの、
それ以外の実害は今のところはないので、
現在はアクセス制限が有効に働く tcp の設定で運用しています。
OpenSolaris の in.lpd 回りの設定を見れば何か分かるかと思ったのですが、
今一つ分かりませんでした。
- (03/26 2006)
(しおり用)
以前は、Microsoft が Solaris 用の Windows Media Player も
出していたようでしたが、
最近はないようです。
代わりに wmf を再生するフリーのツールとしては、
MPlayer や xine, VLC などがあるようです。
ただ、まだインストールはしていません。
- (03/10 2006)
(しおり用)
PDFLib (PDFlib-Lite-6.0.3) を Solaris 9 にインストールしたのですが
(gcc-3.4.3)、make test で __moddi3 とかいうものの relocation error
が出ました。-lgcc を明示的に付ける必要があるようですが、
libgcc は、$prefix/lib ($prefix は configure 時に指定する prefix)
ではなくて、$prefix/lib/gcc/sparc-sun-solaris2.9/3.4.3/ 以下にあります。
よって、LDFLAGS に
-L$prefix/lib/gcc/sparc-sun-solaris2.9/3.4.3 -lgcc
を追加してから configure して make、make test したらうまくいきました。
- (03/03 2006)
(しおり用)
現在の Solaris 9 では、truss というコマンドで、
コマンドの使用するシステムコールを追跡できるようです。
Solaris 8 くらいの頃からのツールでしょうか。
- (02/26 2006)
(しおり用)
Sun の Blade150 のキーボードやマウスは USB 接続なのですが、
普通の PC 用の USB キーボードは使えず、
つないでも OPB が認識してくれないので OS が立ち上がりません。
実は購入した中古の Blade150 についていたのが英語キーボードだったので、
この機会に、それに慣れてもらおうかとも思ったのですが、
結局ぷらっとホームから Blade 用の日本語配列のキーボードを購入しました。
Happy Hacking Keyboard も、
Blade150 につながる USB キーボードはないようですね。
- (02/16 2006)
(しおり用)
奥村＠三重大 さんの
TeX Q & A
の 41326 番の記事にも書きましたが、Perl/Tk は、
perl-5.8.X + Tk 804.X の版ならば日本語もちゃんと扱え、表示もできます。
ただし、"use encoding" を使う場合は、
Tk.pm で Encode モジュールを使っていて
"use encoding" とするとぶつかってしまうのかうまくいきませんので、
"use PerlIO::encoding" としないといけないようです。
これで、通常の「binmode FILE, ":encoding(euc-jp)";」などが
使えるようになるようです。
- (01/27 2006)
(しおり用)
ふと見つけたのですが /bin/ta って何かよくわかりません。
man ta もないし、
string で見てもヘルプメッセージのようなものはありません。
調べると、man troff に何か書いてあるのですが、
man troff にも「最近はほとんど使用されない
/usr/bin/ta コマンドを使うと」などと書かれていますので、
少なくとも roff に関連した古いコマンドなんでしょうかね。
- (01/20 2006)
(しおり用)
私は普段 PDF ファイルは Solaris 上で acroread で PostScript ファイルにして
印刷することが多いのですが
(acroread -toPostScript のようにコマンドラインツールとしても使います)、
Solaris 用の acroroad 7 (Adobe Reader 7.0.1) だと
なぜか 2 ページ目以降が字が抜けることがあります。
これは acroread 5 で、かつ PostScript level 1 で出して、
Koji Nakamaru さん作の acrolpr にかけるとうまくいくようです。
しかし、acroread 7 は、既に PostScript level 1 の出力をサポートしていない
(少なくとも Solaris 用のものは) ようなので、
acroread 7 ではうまく対処できていません。