Xref: utzoo comp.lang.perl:3344 comp.unix.ultrix:5596 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!zaphod.mps.ohio-state.edu!rpi!usenet.rpi.edu!tale From: tale@rpi.edu (David C Lawrence) Newsgroups: comp.lang.perl,comp.unix.ultrix Subject: Re: perl on DECstation, Ultrix 4.1 Message-ID: <9^G^FK#@rpi.edu> Date: 14 Dec 90 01:21:12 GMT References: Organization: Rensselaer Polytechnic Institute Computer Science, Troy NY Lines: 33 In-Reply-To: meissner@osf.org's message of 10 Dec 90 16:47:09 GMT Nntp-Posting-Host: turing.cs.rpi.edu Well, I find this all very curious. I am wondering right now what might be secretly broken in my the perl I had installed on the DECstations several days ago. I compiled on the 5600, running Ultrix 3.1C, with gcc first (well, second, after the native compile didn't do the trick and also had problems with void). Then I saw someone who followed up to Rusty's request saying to undefine volatile. So I did, and recompiled. Then perl passed all of its tests. So I installed it, somewhat trusting that it would be fine. In short, how I compiled with cc: o -DLANGUAGE_C -O -Olimit 3000[*] options o undef waitpid o undef volatile In particular, the various things I did not do which Rusty and Michael say to do: o -DJMPCLOBBER o Use "1" as voidflags (I used the 3 Configure decided on) o Don't use optimisation Are these simple differences in the version of the OS? (Yes, I saw that Michael said you could leave waitpid defined for Ultrix 4.) [*] I am expecting that Rusty's suggesting the use of -Olimit 30000 to optimise eval.c was a typo. I had upped it to 3000 to optimise both t?eval.c and t?toke.c though. My machine wasn't as severely hosed by it as his was. However they did take much longer to compile, but it was still completely done, from Configure to {,taint,suid}perl, in all under an hour. -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))