Entries

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

-件のコメント

コメントの投稿

新規

投稿した内容は管理者にだけ閲覧出来ます

VINE3.1 で octave

以前別のdistributionのlinuxでoctaveを使った計算プログラムを書いた。それを久しぶりにVine3.1のマシンで実行する必要が出てきたので、コンパイルをしてみた。トラブった。
どうも非常に初歩的なところでコンパイルが通らない。
typedef complex Complex;
というところでエラーメッセージ。 これはきっと僕の知らないテンプレート周りの変更があるに違いない。 お手上げ状態になって「昔を懐かしんで」いたところ、 古いバージョンのg++もインストール可能だったことを思い出した。 そこで、gcc295-c++というパッケージをインストールした。 ついでに gcc295-g77 もインストールしておく。 そして、g++-2.95.3 を用いてコンパイル。 すると急にコンパイルが通るようになった。 どうしてこうなるのか、わかる人がいたら教えてください。

あとは必要なライブラリを慎重に探してリンクすればよさそう。 ライブラリのうち libcurses, libreadline は入っていなかったので、それぞれ synaptic でパッケージを探してインストール。 要りそうなライブラリは、このサイトの情報が参考になる。 民間伝承が頼りだ。

追記[2005/05/22]
とりあえず用いているオプションは、

-I/usr/include/octave-2.0.17 -L/usr/lib/octave-2.0.17 -loctave -lcruft -lreadline -ldl -llapack -lblas -lkpathsea -lg2c -lcurses
ところがどうしてもscreenheightとscreenwidthという変数がないと言われてしまうので、いろいろと探してみる。 すると、古いバージョンのreadline(readline4.1)でpublicなsymbolを参照している可能性があることをこの記事で気づいた。 そこで、synapticをのぞいてみたら、あるある。 readline41というパッケージがあるではないか。 これをインストールしておいて、 -lreadline のところで、 使いたい方のライブラリ /usr/lib/libreadline.so.4.1 を直に指定。 これで2つエラーメッセージが減る。 この時点でコンパイルオプションは、
-I/usr/include/octave-2.0.17 -L/usr/lib/octave-2.0.17 -loctave -lcruft /usr/lib/libreadline.so.4.1 -ldl -llapack -lblas -lkpathsea -lg2c -lcurses
となっている。

最後に残ったのは、kpse_clear_dir_cacheというシンボル。 is_symmetric__FRC6Matrixというルーチンから呼ばれているようすだ。 同じ名前のルーチンはほかのライブラリには見あたらない。 kpse_clear_dir_cacheに関しては、いろいろと探してみるのだがどうにも見つからない。 似たような名前のkpse_hogehogeと言うルーチンは、 libkpathsea.so 中にたくさん見られる。 これはもしかするとこのライブラリの別バージョンには含まれている機能なのかもしれない。 ということは、libkpathsea.soを含むパッケージの別バージョンがある可能性を追求してみる価値がある。 /usr/lib/libkpathsea.soを含むパッケージを探すには、

rpm -qf /usr/lib/libkpathsea.so
とすればよいことが man rpm を読んでわかった。 探してみた結果、 libkpathsea.so は、 tetex-2.0.2-0vl14 に含まれていることがわかった。 しかし結局 tetex 関係のパッケージでは、 tetex-extra くらいしか関連しそうなものは見あたらず、このパッケージも特にライブラリを含まないことがわかった。 では別のものかな。

少し整理してみる。liboctave から呼ばれている kpse_ 関係のシンボルを調べてみると以下の通り。

         U kpse_all_path_search
         U kpse_clear_dir_cache
         U kpse_element_dirs
         U kpse_expand_default
         U kpse_path_element
         U kpse_path_expand
         U kpse_path_search
         U kpse_set_program_name
これらのうち、 libkpathsea に見あたらないものは、 kpse_clear_dir_cache のみ。 この関数がどこかのバージョンで削除されたのだろうか? 結局これについては打開できず、あきらめることにして、 邪道の「解決」に向かう。

仕方ないので、kpse_clear_dir_cacheという何もせずエラーメッセージを出していきなり abort する関数を muriyari.c というソースファイル中に定義。 これをコンパイルオプションの最後に加えてリンク。 とうとううまくいった! この関数は結局呼ばれてはいないようで、 無事動作した。 このことについてはいちおう vine-ML に報告しておこう。

スポンサーサイト

0件のコメント

コメントの投稿

新規

投稿した内容は管理者にだけ閲覧出来ます

Extra

プロフィール

象(Zoo)

  • Author:象(Zoo)
  • 理系研究者です。科学好き、やや社会派、体を動かすのも好きです。

最近の記事

最近のトラックバック

ブログ内検索

バナーエリア

ブロとも申請フォーム

この人とブロともになる

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。