1999/10/07    I am back

学会や論文の〆切などで忙しくて、気がついたら1月以上経っていた。これでは日記ではなく月記である。実はまだ仕上げなくてはならない書き物があるし、来月の初めには国際会議もあってちっとも暇はないのであるが、書いておかないと忘れてしまいそうなので(現実逃避をかねて)簡単にまとめておく。

[1] Security Patches and Some New RPMs

まずは、ftp://ftp.linuxppc.org/linuxppc-1999/security/RPMS より、
libtermcap-2.0.8-15.ppc.rpm
libtermcap-devel-2.0.8-15.ppc.rpm
pam-0.68-2.ppc.rpm
また、以下のツール群のアップデート
tar-1.13.11-1a.ppc.rpm
which-2.9-1a.ppc.rpm
patch-2.5.4-8a.ppc.rpm
make-3.78.1-1a.ppc.rpm
bzip2-0.9.5d-1a.ppc.rpm
libtool-1.3.3-1a.noarch.rpm
を行った。対応する SRPM は
tar-1.13.11-1a.src.rpm
which-2.9-1a.src.rpm
patch-2.5.4-8a.src.rpm
make-3.78.1-1a.src.rpm
bzip2-0.9.5d-1a.src.rpm
libtool-1.3.3-1a.src.rpm
である。テストのあるものについては、一応全てのテストにパスしたが、使う場合はいつものように自己責任で
 

[2] Glibc, Binutils, and GCC

以前報告した linuxppc-1999 標準の glibc-2.1.1-6c の libm の問題であるが、Franz Sirl に尋ねたところ、彼の最新版(glibc-2.1.2-7b)を試してくれと言われた。しばらくは、学会の準備のため、開発環境が壊れては大変なので glibc-2.1.2 への移行はためらっていたが、学会も終わったことなので試してみた。
彼の最新版は、ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/ppc より入手可能。
glibc-2.1.2-7b.ppc.rpm
glibc-devel-2.1.2-7b.ppc.rpm
glibc-profile-2.1.2-7b.ppc.rpm
を "rpm -Uvh" で放り込む。結果は、少なくとも libm の問題については解決している。大変めでたい。また、JAVA も green_thread では動いている。

ついでに libg2c の問題について、同じ所にある新しい開発環境(binutils-2.9.5.0.6-0a、gcc*-2.95.1-0a)を試してみた。結果は敗退。-fPIC はたっていない。しかたなく、ftp://devel.linuxppc.org/users/fsirl/R5/SRPMS/ より gcc-2.95.1-0a.src.rpm をとりよせ、例によって -fPIC をつけるパッチ を使い、RPM を作りなおす。使った SPEC はこれ。出来た RPM は

cpp-2.95.1-0am.ppc.rpm
gcc-2.95.1-0am.ppc.rpm
gcc-c++-2.95.1-0am.ppc.rpm
gcc-g77-2.95.1-0am.ppc.rpm
gcc-objc-2.95.1-0am.ppc.rpm
libstdc++-2.10.0-0am.ppc.rpm
で、対応する SRPM は
gcc-2.95.1-0am.src.rpm
である。導入には、事前に
binutils-2.9.5.0.6-0a.ppc.rpm
を入れておくこと。

使用上の注意

makedepend が gcc 関連のヘッダーが見つからないと文句を言うので、

# (cd /usr/lib/gcc-lib/ppc-redhat-linux; ln -s 2.95.1 egcs-2.91.66)
とリンクを張る(正しくは、XFree86 を作りなおすべきだが面倒)。

また、-D__linux はデフォールトでなくなった。-D__linux__ を使うこと。これは、気づかずにいると意図しないコードを使ってしまうので危険である。私は、面倒なので

# vi /usr/lib/gcc-lib/ppc-redhat-linux/2.95.1/spec
....
*cpp_os_linux:
..... -D__linux ....
としてしのいでいるが、あまり推奨できない。

その他、g++ を使っていて、-O0 でないと正常なコードが出来ない例があったので、最適化レベルを変えて結果チェックをすべき。Netscape-4.7 なども新しい libstdc++ で今の所問題なく動いているが、使う場合はいつものように自己責任で

[3] 解析プログラムの開発の現状

以前報告した ROOT を使った部分でのメモリーリークの問題(Heap オブジェクトが IsOnHeap() メソッドで kTRUE を返さない場合があることに依る)は、ROOT のカスタム new/delete 関連の問題であることが判明した。以下の例を実行すると、どちらも同じ new で作られたヒープオブジェクトであるのにも関わらず、
LVector:...... is NOT on heap.
TVector:...... is on heap.
となる。

---<example starts here>-------
#include "TROOT.h"
#include "TVector.h"
#include <iostream.h>

class LVector : public TVector {
public:
   LVector() : TVector(4) {}
   LVector(const TVector & q) : TVector(q) {}
   ~LVector() {}
};

class Track : public TObject {
public:
   Track(Double_t e = 0., Double_t px = 0., Double_t py = 0., Double_t pz = 0.) {
    f[0] = e; f[1] = px; f[2] = py; f[3] = pz;
   }
   ~Track() {};
   TVector GetPV() {
    TVector a(4);
    for (Int_t i = 0; i < 4; i++) a(i) = f[i];
    return a;
   }
private:
   Float_t f[4];
};

//_____________________________________________________________________

TROOT UserAnalysisTest("UserAnalysis", "Test UserAnalysis classes");

int main ()
{
   Track t;
   LVector *qp = new LVector(t.GetPV());
   if (qp->IsOnHeap()) cerr << "LVector:" << (ULong_t)qp << " is on heap." << endl;
   else cerr << "LVector:" << (ULong_t)qp << " is NOT on heap." << endl;

   TVector *tp = new TVector(t.GetPV());
   if (tp->IsOnHeap()) cerr << "TVector:" << (ULong_t)tp << " is on heap." << endl;
   else cerr << "TVector:" << (ULong_t)tp << " is NOT on heap." << endl;
 
   return 0;
}
-----<example ends here>------------

ROOT 開発チームに連絡したところ、

thanks for the detailed bug report. I've located and fixed the bug.
In the soon to be released 2.23 this bug is fixed.

The problem only occurs when the ctor is called with as argument a
function (GetPV()) that allocates and de-allocates a heap object.

との回答をえた。2.23 はもうじき出るようである。当面は、

   TVector q(t.GetPV());
   LVector *qp = new LVector(q);

などとしてしのいでいる。


Back to Keisuke Fujii's MkLinux/LinuxPPC Life