Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ames!sun-barr!lll-winken!isg.llnl.gov!mike
From: mike@isg.llnl.gov (Michael E. Hummell)
Newsgroups: comp.lang.perl
Subject: perl4.0: installed ok, but errors with -d, and h2ph on SUN 490 sparc
Message-ID: <93657@lll-winken.LLNL.GOV>
Date: 21 Mar 91 22:19:16 GMT
Sender: usenet@lll-winken.LLNL.GOV
Distribution: usa
Organization: Lawrence Laboratory ;  Livermore, CA.
Lines: 32
Nntp-Posting-Host: isg.llnl.gov
Originator: mike@isg.llnl.gov

On a SUN Sparcserver 470 , perl4.0 installed okay, but I had problems
running "h2ph" on some of the include files.  And a perl user ran his
perl script (that works under perl3.044) with -d (debug) flag, and 
got "segmentation fault - core dumped".

That last error went away when I changed compiler options from -O (optimize)
to -g (debug).  However, the problem running "h2ph" remains.  That problem is:
cd /usr/include
h2ph * /sys/*     dies with  "segmentation fault - core dumped"

It died on "h2ph math.h"   with "sementation fault - core dumped"
But doing  "h2ph math.h" by itself    was okay.

Then, continuing on with a shell loop, h2ph failed on
memory.h,  sys/mbuf.h  , sys/msg.h  ,  sys/vfs.ph
with either "segmentation fault", or "out of memory" errors.
Running "h2ph" directly on each would sometimes run error free.  But there was
one that never ran (I forget which, sorry).

I Configured several times, using all defaults except: 
	1) with -O optimization flag
	2) with -g debug flag
	3) with none (compiler options),  and not using perl's malloc

But none would allow h2ph * /sys/* to run error free using perl4.000
(downloaded directly from jpl-devvax.jpl.nasa.gov  ).

However, re-running Configure on the perl3.044 DID do the h2ph ... ok (as 
expected ). 

Just FYI.
MIKE HUMMELL   mike@isg.llnl.gov