tale@rpi.edu (David C Lawrence) (03/01/91)
This is more a piece of advice than anything else, but I thought
others might appreciate it since I wasted a lot more time than I
should have discovering the basic source of a problem I was having.
You see, it started like this. Many months ago I wrote a perl
replacement for man because I was extremely dissatisfied with "man" on
our DS3100s and Sequent Balances. (read as: "They blew chunks,
especially that /usr/bin/man crap in Ultrix.") Then about a month ago
I put in Tom's, because it was more fully featured than mine. All was
fine in Mudville, until people had problems with man dumping core on
those DEC machines.
Seems that only for certain manual pages, perl would crap out and drop
core. I wasted much more time than I should have zeroing in on the
area of the problem, and the result was finding out that dbmfetch from
the Ultrix library was what was tossing its cookies. At this point,
assuming that the problem was in the ndbm library and not in perl's
interfacing to it, I just gave up trying to debug the problem from the
Ultrix end and instead got gdbm. I installed it and told perl to link
-lgdbm instead. Then the Ultrix platform man was working fine.
Next, after some directory reorganising and then catman'ing, the Dynix
platform was whining about old dbm not being able to handle opening
multiple dbm files. So I rebuilt that perl also using gdbm and that
problem was resolved. It is still slow on the Balance 8000 and I
should probably investigate undumping it somehow for there.
Moral of the story: if you are on Ultrix (4.1 in my case) or still
only have old dbm, compile with gdbm if you can. In the long run
you'll probably be happier for it.
--
(setq mail '("tale@rpi.edu" "uupsi!rpi!tale" "tale@rpitsmts.bitnet"))