Hi, First, I'ld like to point out that yesterday we have unleashed CLN-1.1.1 onto the world. No big changes, but a couple of important bugs were fixed that do affect GiNaC on non-Intel hardware and on the upcoming GCC-3.0. Oh, thank you very much for the applause! ;-) Second, I would like to move the ./cint subdirectory out of GiNaC. The reason is that Cint is too disappointing right now for GiNaC-cint to be really useful. I have here a nice list of open bugs that won't go away in the near future and that make using it a pain in the neck. The main problem is, however, Cint's portability: it wants to eat your harddisk on Linux/m68k, it has weird linking bugs on Linux/arm and despite my efforts to point out to the ROOT folks at Cern that they will be in a hell of a trouble soon if they don't work on the GCC-3.0 port nothing really happens on this front. (Try compiling Cint on GCC-3.0: it fails in a very spectacular way but doesn't even seem to notice so!) The real problem is of course less the new compiler bug the up-to-date STL. Cint's approach to STL based on ancient sources by HP definitely won't work much longer. Bottom line: the intersection of the set of platforms supported by CLN and GiNaC on the one side and of Cint on the other seems to be quite small. This makes the current situation a headache for distribution packagers: if you configure --with-cint you must exactly know your platform, specifying "Architecture: any" would otherwise work fine for both GiNaC and CLN. Instead, starting with GiNaC-0.9.0 we'll have a separate package GiNaC-cint that will be kicked along and updated when need should arise. Packagers can then throw this at their build-daemons and whatever comes out will probably `work', but that won't have any side-effects on the building of the GiNaC library. Sex, drugs and Unix -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>