[redhat] netcdf installed & making RPM package by myself

Let's install NetCDF.

making RPM by myself

Unfortunately, netcdf is not included in RedHat Linux distribution unlike Vine Linux. Although we can just install the package from the tarball, I'll try to build RPM package from Source RPM (SRPM) package. That will make later maintenance far easier, since all

Though we can search RPM package on the Net, the benefit of making RPM package by myself is that we can tune some features, such as subtle difference between directory structures.


The process of building binary package consists of

  1. getting and installing SRPM package

  2. modify it to work on the target environment

  3. building RPM package

Most of those work is done at a directory called %_topdir by rpm. In the RedHat environment, it seems to be /usr/src/redhat and root privilage is needed to do rebuild packages. But it is bad idea to perform "trial and error" in root user.Thus I believe we must do it by normal user account.

The only two things to do so is to make %_topdir and to tell rpm the location.

$ cat > ~/.rpmmacros
%_topdir                /home/yourname/rpm
$ mkdir /home/yourname/rpm /home/yourname/rpm/{BUILD,RPMS}

source of netcdf

I used SRPM by GFD-Dennou Club.

$ wget http://ruby.gfd-dennou.org/products/rpm/SRPMS/netcdf-3.6.0p1-1dc.src.rpm
$ rpm -i netcdf-3.6.0p1-1dc.src.rpm

After that, you will find source tarball at ~/rpm/SOURCE and a file called spec file at ~/rpm/SPECS/netcdf.spec.


As is often the case, I had to change some. All changes should be done tothe spec file, and if anything is changed, it is courtesy to change Release:code to avoid confusion to original package. Today I changed

Release: 1dc


Release: 1et

that means the first packaging by E.T.


$ cd ~/rpm
$ rpmbuild -ba SPECS/netcdf.spec

If your spec file has no error, that will end with "exit 0" and you willfind binary and source packages.(Of course, it is usually a result of long trial and error.)

$ find RPMS/

When you feel okay, it is better to remove temporary files.

$ rpmbuild --clean SPECS/netcdf.spec
$ rm /var/tmp/rpm-tmp.*


$ sudo rpm -ivh netcdf-3.6.0p1-1et.i386.rpm

[redhat] rd2html.cgi

I made a CGI that translates RD (a text markup language) to HTML.The reason why I made this is because I want to write blog easier.I like simpleness of blog, but it doesn't support well texts containing many blockquotes from computers.When writing log of system administration work, we often write quotes like

$ cp Makefile Makefile.bak
$ vi Makefile
$ diff Makefile.bak Makefile
< foo
>   bar

in such case, all linebreaks and space must be exactly conserved.The easiest way to do so is to turn off auto-linebreak and insert <pre> tags.But it is tedious to insert <p> into all paragraphs outside of the quote.

GTOOL3 worked

GTOOL3 worked.

The problems were:

  • some source code had obsolete syntax.
  • DCL uses GTK+ if it is installed, but GTOOL3 (more correctly SYSMAKE) doesn't support this feature.
    Hence I had to add some -l options to Makedef files.

I ought to include modifications. I'll do it later.






[Linux] ハイバネーション後も ssh 接続が使えた件


ラップトップから ssh で隣のホストにログインして作業中だということをすっかり忘れてハイバネーションをかけたわけです。で、持ち歩いて床屋に行ったり電器屋を冷やかしたりして2時間くらいして帰って来て、つないでから kterm (古い...) にエンターぱこぱこ入れて、ふと見るとプロンプトの形が違う。えーって思うと接続が生きているのですな。

これは便利だ。もとい、危険なので (telnet だったら侵入者はいりほうだい) きちんとログアウトしましょう。

[redhat] install DCL

I need DCL before GTOOL3. In short, it is a graphic library written in FORTRAN 77.

download source and extract

$ tar xvfz dcl-5.3.tar.gz

try 1st

$ cd dcl*
$ FC=/usr/local/bin/g95 sh configure --prefix=/usr/local
$ make
Many error occurs. The reason is one old-style statement.
$ g95 -c sztnsv.f 
In file sztnsv.original.f:68

Error: Loop variable at (1) must be a scalar INTEGER
Thus I rewrote it like this:
$ cd src/grph1/szpack
$ cp sztnsv.f sztnsv.original.f
$ vi sztnsv.f
$ diff -c sztnsv.original.f sztnsv.f
*** sztnsv.original.f   2005-03-27 18:50:44.000000000 -0600
--- sztnsv.f    2005-03-27 18:53:05.000000000 -0600
*** 65,71 ****
--- 65,72 ----
That's all.
$ make
# make install

[redhat] installation of gtool3

= purpose

gtool3 is name of a file format for meteorological grid data and its access library. It is used in AGCM of GFD-Dennou Club.

= source

* http://www.gfd-dennou.org/arch/sysmake/sysmake_20000105-3.tar.gz
* http://www.gfd-dennou.org/arch/gtool/gt3-dcl5_20000124-4.tar.gz

= procedure

== sysmake

I am trying to install minimal components of sysmake.

$ tar xvfz sysmake_20000105-3.tar.gz
$ cd sysmake*
$ cp Makedef.Linux Makedef.Linux.bak
$ vi Makedef.Linux
$ diff -c Makedef.Linux.bak Makedef.Linux
< FC = g77
> FC = /usr/local/bin/g95
< FPP = /usr/lib/sysmake/bin/fpp # For Debian
> FPP = /usr/local/bin/fpp
$ sudo mkdir /usr/local/lib/sysmake
$ sudo cp Makedef.Linux /usr/local/lib/sysmake
$ sudo make -f Makedef.Linux fpp

That procedure will create
* /usr/local/lib/sysmake
* /usr/local/lib/sysmake/Makedef.Linux
* /usr/local/bin/fpp

=== addendum

This fpp is later found not to work for lines including Japanese letters. That's because the default locale is en_US.UTF8 and these codes are treated as broken UTF8.

To get lid of this problem, the script fpp should be modified like this:

export LANG
sed -e 's/\(.*\)!\"\(.*\)/\1/'

== gtool3

$ tar xvfz gt3-dcl5_20000124-4.tar.gz
$ cd gt3-dcl5-20000124
$ cp Mkinclude Mkinclude.bak

Then I realized that gtool3 requires dcl. This work must be pending until DCL has been installed.

g95 のバグ

g95 のバグをみつけた。しかし対応済だった。

DCL をコンパイルした。FORTRAN 77 の古い文法 (倍精度実数による DO ループ) によるところを直してやれば、一見うまく動くように見えた。しかし、デモプログラム (dclfont とか) を動かすと "parameter TITLEMAXMSGLOC undefined" とか意味不明のことをいってあぼーん。

PRINT デバッグでねちねち追求すると、どうやら SWCSTX から SWCQID に文字列の長さが正しく渡っていない模様。コンパイラのバグじゃん。

さあて Andy に報告してやるか、現症を再現する最小コードつくるの面倒だなあと重い腰をあげる前に、ふと気がついて g95 をアップデートしたら、なあんだ動いてしまったではないか。読者諸兄も同じ問題を抱えていたら 1 月 22 日以上のバージョンにアップデートされた い。

[redhat] g95 is better

I'm sorry I have to correct my info so soon.

There have long been another compiler g95 and it's far better than gfortran at this point of time.

[redhat] gfortran

Redhat already has g77, a free FORTRAN 77 compier. But I want to use Fortran 95. gfortran is a free Fortran 95 compiler.

  1. $ wget http://quatramaran.ens.fr/~coudert/gfortran/gfortran-linux.tar.gz
  2. # mkdir /usr/local/gfortran
  3. # tar xvfz gfortran-linux.tar.gz

Download page suggests that we always use -static and -Wall options. Thus wrapper like this would work well instead of setting $PATH to /usr/local/gfortran/irun/bin.

exec /usr/local/gfortran/irun/bin/gfortran -static -Wall "$@"

[redhat] ssh settings

The next thing is setup of ssh.

* Key has to be generated.
* authorized_keys file is usually copied from existing host.
* Usually other host's authorized_keys file should be edited.
* We don't have to care about known_host file since it is automatically edited.

[redhat] sudo activation

Installer prompts to create one non-root user account. It will be the account of daily use, since remote login for root is not allowed by default.
The installer suggests using su, but I can't do without sudo. Fortunately it was installed.

In order to use sudo, configuration file should be edited.

$ su
Password: ###############
# /usr/sbin/visudo

I uncommented a suggestion:

%wheel ALL=(ALL) ALL

that means all users in wheel group can use sudo. So I have to add myself to the group:

# /usr/sbin/vigr

[redhat] Installation Tips

I (and my colleague) started to be an admin of a Linux box with RedHat Enterprise Linux AS 3. Although I have much experience with rpm-based Linuxes (Vine and Kondara), it is the first time to touch real redhat, and I hope I can learn much.

Yesterday was the first trial. The installation itself took about half an hour. But update took more than twice of installation. And after the update, I found that the system has no development packages, such as gcc, libXXX.a, and all headers.

I found that there is a package management program "redhat-config-packages" to add/remove packages (also accessible from red hat menu of GNOME), but it doesn't work: it claims that libraries such as krb5-libs or Xlib is not intalled (actually updated and existent according to rpm output) for some packages, and even after I limited the package set not to raise the error, it doesn't recognize the CD-ROM.

A suggested method was to download all required software from the Internet and install manually. But it is undesirable because too tedious and dangerous to confuse the package management system. Therefore I decided to reinstall whole system.

Repeating installation sometimes make people learn more. Two findings:

  • Language other than English mush be added in the first installation. After that I could not find any method to do that.
  • Package selection menu has "everything" checkbox at the bottom. In my opinion this should come first and be strongly recommended.

[fortran-stdio] レコードからブロックへの分解

= fread(仮称) の内部ロジック

fread はブロック(直接探査のレコードを以下こう呼ぶ。レコードはお客様のレコードにとっておく)と対応しないかもしれないファイルオフセット範囲を読み書きしろといわれるわけで、読めといわれた範囲をブロックに分割してそれぞれに READ 文にかける、そしてブロック全体を読めと言われていない場合はバッファに読んで抽出する。

ここでブロック中にファイル終端があって全部読めない場合は、自動的に Fortran 記録長を変更して部分的に読み込みを試みる。しかし、ブロックでループしているのにブロック長が変わるとやりにくいので、指定されたブロックの途中までが読めた、という整数値が帰るだけでよいだろう。この整数値は語単位の INTEGER(4) で十分。

fread() 任意範囲
blockread() 固定長ブロック(メガバイトくらいでかい)
READ 可変長ブロック

= fwrite と fread の関係

fwrite も似たようなもので、fwrite/blockwrite/WRITE の3階層になる。しかし、fwrite がブロックの一部だけを書き込む場合(ブロック先頭からEOF位置以遠までを書き込む場合を除く)、一端ブロックを読み取ってから書き込まなければならない。その読み込みは blockread に似ているが、fwrite が書き込まない最後のワードオフセット(ブロック内)までを読み込めば十分であるため、ちょっと fread に似た性格となる。これは、blockread にオプション引数を設けることでいいのだろう。

= バッファのプロパティ


・有効長(blockread が一部しか読めなかった場合、
・活性長(fflush するときに書き込みが必要な最後のワードオフセット)

[fortran-stdio] つづき


= でっかい数の管理

ファイルの長さは 60 ビットもとってあげれば十分だろう。1エクサバイ
トだ。あの8mmテープみたいなやつ... ではない。ま、あと30年は大丈夫

号付き整数(Fortran には、Fortran 2003に至るまで符号無し整数という
ものはない)で MSB を立てると負の数になってしまって激しく具合が悪い
、というわけで INTEGER(4) が1個あたり 30 ビットを任せるのがいいで


2^30 のビットが立ったら繰り上がり・繰り下がりとすればよい。


簡単だろう。だが、うっかりすると REAL(8) に換算して除算したほうが

= 換算の種類

RECL の単位は多処理系間で一定しないので、RECL 値は隠蔽する。
上位層には RECL の代わりに物理レコード毎の語数として見せることにな

fread/fwrite の下にブロック(物理レコード)毎の入出力層が作られるだ


GEMPAK のコンパイルは難関

GEMPAK は米国の気象系の大学が IDD を通じて取ってきたデータを解析可視化するのに使っているソフトウェアである。単機能コマンド集でどっかの GTOOL3 みたいにとってもダサいのではあるが、コマンドの全パラメタをカレントディレクトリのファイルに書き出して、次回起動時はそれがデフォルトになるというインターフェイスはなかなか秀逸だし、何よりとっても高機能なので、これで色々やったらいいんじゃないのという感じがしてきた。ちなみに netCDF, GRIB (限定あるだろうけど), METAR のデコーダがついている。

そういうわけで、早速ソースコードをダウンロードしてコンパイルを試みた。ところが tar.gz 開いて口あんぐり。世間で configure に相当する部分が Gemenviron とかいう名前の csh スクリプトで書かれているし、NetCDF や zlib など有象無象のソースコードがてんこもりだし。

めげずにコンパイルしてみたが、何やらボロボロエラーが出まくる。よーく観察する必要がありそうだ。人様の仕事の成果 (なんかソースコード 120 万行くらいあるんですけど....) を只で頂いて来ているのだから文句を言っちゃいけないのはわかるが、いややっぱりこまるだよ。

それにしても、csh がないとコンパイルできないのだけはなんとかしてほしい。

[fortran-stdio] 構想かきなおし


Fortran でバイナリファイルの入出力をしようと思うと、入出力文の機能不足で 悲しい思いをすることになる。標準が用意してくれている機能は順番探査なら RECL-REC-RECL の連鎖というフォーマットが決まってしまっているし、直接探査 ならばレコード長の倍数のオフセットで読み書きをしなければならない。したが って、任意のオフセットで任意のフォーマットの読み書きをするライブラリを作 りたいわけである。

= 想定


(1) 入出力長や位置はワード (32ビット) の倍数単位とする。 (2) 32 ビットより大きな整数型はあてにしない。 (3) Fortran 処理系が許せば 4 ギガバイトより大きなファイルを アクセスできるようにする。 (4) プログラムうざいので Fortran 90 を前提にする。

= 実現方法

任意のフォーマットを読むには直接探査書式無しファイルとして開く必要がある 。ファイル長がレコード長で割り切れない場合、ファイル末尾の半端な部分は

(1) 後ろにゼロを埋めたレコードとして読める (g77 など) (2) 条件付きで上に同じ (?) (3) 読めない (g95, HP)

といろいろであるが、いずれにしても RECL を小さく変更して OPEN しなおして やれば(処理時間はさておくとすれば) アクセスできる。したがって、ファイル 長が「最小のレコード長(小さいファイルについては RECL=1)」で割り切れるな らば、ファイルの全体を読むことができる。

RECL=1 のレコード長は処理系依存であるが、知っている限りでは DEC 由来のコ ンパイラ (Windows, VMS) で 4 オクテットなのが最大である。

なお、Fortran 標準を読むだけだと、開いたファイルに対して

OPEN(10, RECL=1)

などとしてレコード長を変更することができるかもしれない、という淡い期待を 持ってしまうが、少なくとも g95 でエラーになるのでダメである。

= バイトオーダーの話

一般にデータ型表現の機種依存性というストーリーになるんだと思うが、XDR を 持ち出してどうのというのは牛刀で避けたい。

入出力を 4 オクテット境界に限定して、入出力で起こることは INTEGER(4) の 読み書きだということにする、というのが一つの整理法と考えられる。

(a) 下層では INTEGER(4) の読み書きに専念して、必要な場合に SWAB4 する。 (b) 上層では INTEGER(4) 列から利用者型の切出しを行う。 (c) INTEGER(4) 列上の利用者型の表現はバイト列ではなく、ワード中のビット 順位を用いて定義する。


---- 時間切れとりあえず送信。



メタデータは「データに関するデータ data about data」と定義されるという点では誰もが一致する。で、これではあまりに抽象的に過ぎる。そこで具体的にどんな場合に使うものかを考えることになる。

GIS 業界では、FGDC 標準 (CSDGM, http://www.fgdc.gov/metadata/contstan.html) が NSDI クリアリングハウスのために開発されたという経緯があるらしい。前文にいう:

The standard was developed from the perspective of defining the information required by a prospective user to determine the availability of a set of geospatial data, to determine the fitness the set of geospatial data for an intended use, to determine the means of accessing the set of geospatial data, and to successfully transfer the set of geospatial data.

(私訳: 本規格は、データの潜在的な利用者がデータの有無の調査、地理データが利用目的に適合するかの調査、データへのアクセス手段の調査、そして実際のデータ転送を行うに際して必要となるような情報を定義する、という観点で開発された。)

この考え方はメタデータという言葉をデータの取得前だけに使うもの、と解釈するもので、要は商品カタログのエントリに必要なものだけ載せるというような感じになる。したがって、FGDC 規格は実際のデータ形式がどんなものであるかについてほとんど興味が無く、それと独立したファイル (規格自体は規定しないけれど XML 化する標準が別にあり、これが標準といえるだろう) に格納されることを想定している。

で、私の故郷 NetCDF 業界では、メタデータっていうと NetCDF ファイル中に含まれている属性のことであり、データを使う際に使うものという色彩が濃い。たとえば CF Metadata Conventions (http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html) のアブストにいう:

The conventions define metadata that provide a definitive description of what the data in each variable represents, and of the spatial and temporal properties of the data. This enables users of data from different sources to decide which quantities are comparable, and facilitates building applications with powerful extraction, regridding, and display capabilities.

(私訳: 本規約は、データセット中の各変数の中のデータが何を表しているかや、データの時空間的特性について明確に記述することができるメタデータを定義する。これによって異なるソースからのデータの利用者がどの量が比較可能かを決められるようになったり、データに対して抽出・格子変換・表示などを行う強力なソフトウェアを作ることが容易になったりする。)


ではどちらが正しいのか? これはやっぱり GIS が正しいのだろう。

メタデータという言葉の発祥の地はどこだかわからないのだが、metadata で google してトップに出てくるダブリンコア・イニシアチブ (http://dublincore.org/) は図書館情報学とつながっている気配があるし、W3C (http://www.w3.org/Metadata/) も resource description に使うんだといっているから取得前だ。それでこれら全部ひっくるめて http://www.metadata.net/ から (CSDGM も含めて) リンクされている。


データの自動処理可能性の向上のため、データに付随するデータの標準化を行おうと言う発想は大変結構である。が、そういうデータは metadata ではない何か違う名前がいいのではないか。それとも、気象側でクリアリングハウスへの理解が深まって自然に意味が統合されるのだろうか。


が大きくなって 50MB になったらしい。そりゃ結構。
だが、どうして現在の使用量がゼロになる? よくわからん。